Live data from Hacker News

Google is killing the open web, part 2

wok.oblomov.eu

181–190 of 362 posts

Re: Google is killing the open web, part 2

#181

Earlier quoted context omitted.

I want to start out by noting that despite both the linked article the very comment you're replying to pointing out that the security excuse is transparently bad faith, you still trotted it out, again . And no, it really isn't a cost benefit question. Or if you'd prefer, the _indirect_ costs of breaking backwards compatibility are much higher than the _direct_ cost. As it stood, as a web developer you only needed to…

> security excuse is transparently bad faith, you still trotted it out I don't see any evidence supporting your assertion of them acting in bad faith, so I didn't reply to the point. Sandboxes are not perfect, they don't transform insecure code into perfectly secure code. And as I've said, it's not only a security risk, it's also a maintenance cost: maintaining the integration, building the software, and testing it,…

> It's fine to disagree on the costs/benefits and where you draw the line on supporting the removal, but fundamentally it's just a cost-benefit question

If browser makers had simply said that maintaining all the web standards was too much work and they were opting to depreciate parts of it, I'd likely still object but I wouldn't be calling it bad faith. As it stands however, they and their defenders continue to cite alleged security problems as one of if not the primary reason to remove XSLT. This alleged security justification is a lie. We know it's a lie because there exists a trivial way to virtually completely remove the security burden presented by XSLT to browser maintainers without depreciating it, and the chrome team is well aware of this option. There is no significant difference in security between "shipping an existing polyfil which implements XSLT from inside the browser's sandbox instead of outside it" and "removing all support for XSLT", so security isn't the reason they're very deliberately choosing the former over the latter.

> This seems overly dramatic. It's a small streamlining of an important software, by removing an expensive feature with almost zero usage

This isn't a counter argument, you've just repeated your point that XSLT (allegedly) isn't sufficiently well used to justify maintaining it, ignoring the fact that said tradeoff being made by browser maintainers in the first place is a problem.

Re: Google is killing the open web, part 2

#182

I have yet to read an article complaining about XSLT deprecation from someone who can explain why they actually used it and why it’s important to them. > I will keep using XSLT, and in fact will look for new opportunities to rely on it. This is the closest I’ve seen, but it’s not an explanation of why it was important before the deprecation. It’s a declaration that they’re using it as an act of rebellion.

Imagine you have users that want to view an XML document as a report of some kind. You can easily do this right now by having them upload a document and attaching a stylesheet to it. I do this to let people view after-game reports for a video game (Nebulous: Fleet Command). They come in as XML and I transform them to HTML. Now I do this all client-side using the browser support for XSLT and about 10 lines of javascript because I don't want to pay for and run a server for file uploads. But if I did the XSLT support in the browser would make it truly trivial to do.

Now this obviously isn't critical infrastructure, but it sucks getting stepped on and I'm getting stepped on by the removal of XSLT.

Re: Google is killing the open web, part 2

#183

Removing XSLT from browsers was long overdue and I'm saying that as ex-maintainer of libxslt who probably triggered (not caused) this removal. What's more interesting is that Chromium plans to switch to a Rust-based XML parser. Currently, they seem to favor xml-rs which only implements a subset of XML. So apparently, Google is willing to remove standards-compliant XML support as well. This is a lot more concerning.

I think it might make more sense to use WebAssembly and make them as extensions which are included by default (many other things possibly should also be made as extensions rather than built-in functions). The same can be done for picture formats, etc. This would improve security while also improving the versatility (since you can replace parts of things), if the extension mechanism would have these capabilities.

(However, I also think that generally you should not require too many features, if it can be avoided, whether those features are JavaScripts, TLS, WebAssembly, CSS, and XSLT. However, they can be useful in many circumstances despite that.)

Re: Google is killing the open web, part 2

#184
post #152
post #58

Earlier quoted context omitted.

JavaScript is ever evolving and it means you need to stick to one of the two browsers (WebKit or Firefox) and keep upgrading. XSLT hasn't changed in years. It's an actual standard instead of an evolving one. I know that other independent browsers that I used to use back in the day just gave up because the pace of divergence pushed by the major implementations meant that it wasn't feasible to keep up independently. I…

JavaScript is backwards compatible. You can use an older standard supported by everything if you wish.

Really? Because I have an old iPad (4th gen?) that no longer works on many sites. If it was backwards compatible they'd still function.

Re: Google is killing the open web, part 2

#185
post #127

This has nothing to do with the “open web”. I don’t know if the people saying this just don’t have a meaningful definition of what open means or what. “Open” doesn’t mean “supports everything anyone has ever shipped in a browser”. (Chrome should support Gopher, really? Gopher was literally never part of the World Wide Web.) What’s happening is that Google (along with Mozilla and Safari) are changing the html spec to…

> Google Reader deprecation probably hurt RSS more than anything else And, indeed, if the protocol was one killer app deprecation and removal away from being obsolete, the problem was the use case, not the protocol. (Personally, I don't think RSS is dead; it's very much alive in podcasting. What's dead is people consuming content from specific sites as a subscription model instead of getting most of their input slop-…

It wasn't just one killer app deprecation/removal away. RSS was also integrated into browsers at one point, and then removed. You wouldn't need a social media feed if your browser home page already gave you your timeline, and if it were trivial for any web page to add a "subscribe" button. But instead of known, proven use-cases that have clear demand, we get Javascript APIs for niche stuff like flashing firmware onto USB devices.

Re: Google is killing the open web, part 2

#186

Earlier quoted context omitted.

> JavaScript is better than XSLT in every way Obviously not in every way. XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages. It gives a very low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natu…

> XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages. Have you ever met a single non-programmer who successfully picked up XSLT of their own volition and used it productively? I'd be willing to bet good money that the Venn diagram of users that fit the intersection of "authoring content for the web", "care about separating content from HTML", "comfortabl…

I did after reading about it. I immediately moved my personal site to it and got rid of the crap JS site I had.

Re: Google is killing the open web, part 2

#187

Earlier quoted context omitted.

Safari yes Mozilla…are they actually competing? Like really and truly.

Mozilla has proven they can exist in a free market; really and truly, they do compete. Safari is what I'm concerned about. Without Apple's monopoly control, Safari is guaranteed to be a dead engine. WebKit isn't well-enough supported on Linux and Windows to compete against Blink and Gecko, which suggests that Safari is the most expendable engine of the three.

If your main competitor is giving you 90% of your revenue they aren't a competitor.

Re: Google is killing the open web, part 2

#188
post #159

Earlier quoted context omitted.

Both of those are strategies aimed at capturing a niche market segment in hopes of attracting them away from the big browsers.

I guess? I don't get the sense that when the Opera devs added torrents a couple decades ago, they were necessarily doing it to steal users so much as because the developers thought it was a useful feature. But it doesn't really make a difference to my broader point that browser devs have never had "servant-mindset"

I agree. They've never had that mindset.

Re: Google is killing the open web, part 2

#189

Removing XSLT from browsers was long overdue and I'm saying that as ex-maintainer of libxslt who probably triggered (not caused) this removal. What's more interesting is that Chromium plans to switch to a Rust-based XML parser. Currently, they seem to favor xml-rs which only implements a subset of XML. So apparently, Google is willing to remove standards-compliant XML support as well. This is a lot more concerning.

I was somewhat confused and irritated by the lack of a clear frontrunner crate for XML support in rust. I get that xml isn't sexy, but still.

Re: Google is killing the open web, part 2

#190
Google is just one of the companies killing the open web. None of them will say it outright, but they'll just scrounge up enough "security" reasons for their decisions to seem palatable, even to the HN crowd.

They're just turning up the heat, even more so since AI became a thing.

Post reply on HN