Live data from Hacker News

Google is killing the open web, part 2

wok.oblomov.eu

31–40 of 362 posts

Re: Google is killing the open web, part 2

#31
In part 1 of this article, the author wrote, "XSLT is an essential companion to RSS, as it allows the feed itself to be perused in the browser"

Actually, you can make an RSS feed user-browsable by using JavaScript instead. You can even run XSLT in JavaScript, which is what Google's polyfill does.

I've written thousands of lines of XSLT. JavaScript is better than XSLT in every way, which is why JavaScript has thrived and XSLT has dwindled.

This is why XSLT has got to go: https://www.offensivecon.org/speakers/2025/ivan-fratric.html

Re: Google is killing the open web, part 2

#32
post #15

Earlier quoted context omitted.

> It's a dead format that no one uses[1], This has to be proven by Google (and other browser vendors), not by people coming up with examples. The guy pushing "intent to deprecate" didn't even know about the most popular current usage (displaying podcast RSS feeds) until after posting the issue and until after people started posting examples: https://github.com/whatwg/html/issues/11523#issuecomment-315... Meanwhile Go…

> Also, "no one uses it" is rich considering that XSLT's usage is 10x the usage of features Google has no trouble shoving into the browser and maintaining. Compare XSLT https://chromestatus.com/metrics/feature/timeline/popularity ... with … Comparing absolute usage of an old standard to newer niche features isn’t useful. The USB feature is niche, but very useful and helpful for pages setting up a device. I wouldn’t e…

> Comparing absolute usage of an old standard to newer niche features isn’t useful. The USB feature is niche, but very useful and helpful for pages

So, if XSLT sees 10x usage of USB we can consider it a "niche technology that is 10x useful tan USB"

> The fact that those two features are used similarly

You mean USB is used on 10x fewer pages than XSLT despite HN telling me every time that it is an absolutely essential technology for PWAs or something.

Re: Google is killing the open web, part 2

#34
post #25

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.

It’s interesting to see the casual slide of Google towards almost internet explorer 5.1 style behavior, where standards can just be ignored “because market share”. Having flashbacks of “ ”

The standards body is deprecating XSLT with support from Mozilla and Safari (Mozilla first proposed the removal).

Not sure how you got from that to “Google is ignoring standards”.

Re: Google is killing the open web, part 2

#35

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.

I used it. It's an (ugly) functional programming language that can transform one XML into another - think of it as Lisp for XML processing but even less readable.

It can work great when you have XML you want to present nicely in a browser by transforming it into XHTML while still serving the browser the original XML. One use I had was to show the contents of RSS/Atom feeds as a nice page in a browser.

Re: Google is killing the open web, part 2

#36
post #25

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.

It’s interesting to see the casual slide of Google towards almost internet explorer 5.1 style behavior, where standards can just be ignored “because market share”. Having flashbacks of “ ”

I don’t get the comparison. The XSLT deprecation has support beyond Google.

Re: Google is killing the open web, part 2

#37
post #8

I don’t know. The author makes some arguments I could get entertain and get behind, but they also enumerate the immense complexity that they want web browsers to support (incl. Gopher). Whether or not Google deprecating XSLT is a “political” decision (in authors words), I don’t know that I know for sure, but I can imagine running the Chrome project and steering for more simplicity.

"Steering for more simplicity" would be a political decision. Keeping it is also a political decision. Removing a feature that is used, while possibly making chrome more "simple", also forces all the users of that feature to react to it, lest their efforts are lost to incompatibility. There is no way this can not be a political decision, given that either way one side will have to cope with the downsides of whatever…

I would argue that FTP and Gopher were far more broadly used in browsers than XSLT ever was... but they still removed them. They also likely didn't present nearly the burden of support for XSLT either.

Re: Google is killing the open web, part 2

#38
post #7

I don’t know. The author makes some arguments I could get entertain and get behind, but they also enumerate the immense complexity that they want web browsers to support (incl. Gopher). Whether or not Google deprecating XSLT is a “political” decision (in authors words), I don’t know that I know for sure, but I can imagine running the Chrome project and steering for more simplicity.

The drama around the XSLT stuff is ridiculous. It's a dead format that no one uses[1], no one will miss, no one wants to maintain, and that provides significant complexity and attack surface. It's unambiguously the right thing to do to remove it. No one who actually works in the web space disagrees. Yes, it's a problem that Chrome has too much market share, but XSLT's removal isn't a good demonstration of that. [1] Y…

The fact that people didn't realize that a site used XSLT before the recent drama is meaningless. Even as a developer, I don't know how most of the sites I visit work under the hood. Unless I have a reason to go poking around, I would probably never know whether a site used react, solid, svelte, or jquery.

But it ultimately doesn't matter either way. A major selling point/part of the "contract" the web platform has with web developers is backwards compatibility. If you make a web site which only relies on web standards (i.e. not vendor specific features or 3rd party plugins), you can/could expect it to keep working forever. Browser makers choosing to break that "contract" is bad for the internet regardless of how popular XSLT is.

Oh, and as the linked article points out, the attack surface concerns are obviously bad faith. The polyfil means browser makers could choose to sandbox it in a way that would be no less robust than their existing JS runtime.

Re: Google is killing the open web, part 2

#39
post #35

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.

I used it. It's an (ugly) functional programming language that can transform one XML into another - think of it as Lisp for XML processing but even less readable. It can work great when you have XML you want to present nicely in a browser by transforming it into XHTML while still serving the browser the original XML. One use I had was to show the contents of RSS/Atom feeds as a nice page in a browser.

I have done same thing with sitemap.xml.

Re: Google is killing the open web, part 2

#40
post #19
post #9

Do you remember that chrome lost FTP support recently? The protocol was widely used and simple enough.

Widely used? By whom? Devs who don't understand rsync or scp? Give me a practical scenario where a box is running FTP but not SSH. Edit: then account for the fact that this rare breed of content uploader doesn't use an FTP client... there's absolutely no reason to have FTP client code in a browser. It's an attack surface that is utterly unnecessary.

Linking to an FTP file from a web page.
Post reply on HN