4 ms·
Honestly, your chance to impact this decision was when you decided what technologies to use on your website, and then statistically speaking [1], chose not to u
by jerf 1y ago
Honestly, your chance to impact this decision was when you decided what technologies to use on your website, and then statistically speaking [1], chose not to use XSLT in the browser. If the web used it like crazy we would not be having this conversation.
Your other opportunity is to put together a credible plan to resource the XSLT implementations in the various browsers. I underline, highlight, bold, and italicize the word "credible" here. You are facing an extremely uphill battle from the visible lack of support for the development; any truly credible offer should have come many years ago. Big projects are well aware of the utility of last-minute, emotionally-driven offers of support in the midst of a burst of publicity, viz, effectively zero.
I don't know that the power is as imbalanced as people think here so much as a very long and drawn out conversation has been had by the web as a whole, on the whole the web has agreed this is not a terribly useful technology by vast bulk of implementation work, and this is the final closing chapter where the browsers are basically implementing the will of the web. The standard for removal isn't "literally 0 usage in the entire world", and whatever the standard is, if XSLT isn't on the "remove" side of it, that would just be a sign it needs to be tuned up because XSLT is a complete non-entity on the web. If you are not feeling like your voice is being respected it's because it's one of literally millions upon millions; what do you expect?
[1]: I know exceptions are reading this post, but you are exceptions. And not terribly common ones.
- xg15 1y agoThat's not completely wrong, but also misses some nuance. E.g. the thread mentions the fact that web support is still stuck at XSLT 1.0 as a reason for removal. But as far as I know, there were absolutely zero efforts by browser vendors before to support newer versions of the language, while there was enormous energy to improve JavaScript. I don't want to imply that if they had just added support for XSLT 3.0 then everyone would be using XSLT instead of JavaScript today and the latest SIMD optimizations of Chrome's XPath pipeline would make the HN front-page. The language is just too bad for that. But I think it's true that there exists a feedback loop: Browsers can and do influence how much a technology is adopted, by making the tech less or more painful to use. Then turning around and saying no one is using the tech, so we'll remove it, is a bit dishonest.
- jerf 1y agoJavascript was instantly a hit from the day it was released, and it grew from there. XSLT never took off. Ever. It has never been a major force on the web, not even for five minutes. Even during the "XML all the things!" phase of the software engineering world, with every tailwind it would ever had, it was never a serious player. There was, at no point, any reason to invest in it any farther. Moreover, even if you push a button and rewrite history so that even so it was heavily invested in anyhow, I see no reason to believe it would have ever been a major force in that alternate history either. I would personally contend that it has always been a bad idea, and if anything, it has been unduly propped up by the browsers and overinvested in as it is. But perhaps less inflammatorily and more objectively, it has always been a foreign paradigm that most programmers have no experience in, and this was even more true in the "XML all the things!" era which predates the initial Haskell burst that pushed FP forward by a good solid decade, and the prospects of it ever being popular were never all that great.
- em-bee 1y agoi also don't see XSLT solving any problem that javascript could not solve. heck, if you rally need XSLT in the browser, using javascript you could even call some library like saxonjs, or you could run it webassembly.
- o11c 1y agoCounterpoint: most websites are not useful. If we only count useful websites a much higher percentage of them are using XSLT. But useful websites are much less likely to be infested by the all consuming Goo admalware.
- bawolff 1y ago[Citation needed] Seriously, i doubt this.
- cyanydeez 1y agoI secondly doubt this. Would love a succinct list of "important" websites.
- troupo 1y agoDo Library of Congress and Congress count? https://news.ycombinator.com/item?id=44958929 https://news.ycombinator.com/item?id=44958929 It's not for the public to identify these sites. It's for the arrogant Googlers to do a modicum of research
- bawolff 1y agoAt first glance the library of congress link appears to be using server side XSLT, which would not be affected by this proposal. The congress one appears to be the first legit example i have seen. At first glance the congress use case does seem like it would be fully covered by CSS [you can attach CSS stylesheets to generic xml documents in a similar fashion to xslt]. Of course someone would have to make that change.
- troupo 1y ago> Of course someone would have to make that change. Of course. And yet none of the people from Google even seem to be aware of > The congress one appears to be the first legit example i have seen. There are more. E.g. podcast RSS feeds are often presented on the web with XSLT: https://feeds.buzzsprout.com/231452.rss https://feeds.buzzsprout.com/231452.rss Again, none of the people from Google even seem to be aware of these use cases, and just power through regardless of any concerns.
- ndriscoll 1y agoStatistically, how many websites are using webusb? I'm guessing fewer than xslt, which is used by e.g. the US Congress website. I have a hard time buying the idea that document templating is some niche use-case compared to pretty much every modern javascript api. More realistically, lots of younger people don't know it's there. People constantly bemoan html's "lack" of client side includes or extensible component systems.
- em-bee 1y agoi just built a website in XSLT and implementing some form of client side include in XSLT is not easier than doing the same in javascript. while i agree with you that client side include is sorely missing in HTML, XSLT is not the answer to that problem. anyone who doesn't want to use javascript to implement client-side include, won't want to use XSLT either.
- otterley 1y agoWhere is the US Congress's website identified as a potentially impacted site? https://chromestatus.com/metrics/feature/timeline/popularity/78 https://chromestatus.com/metrics/feature/timeline/popularity... edit: I see Simon mentioned it - https://simonwillison.net/2025/Aug/19/xslt/ https://simonwillison.net/2025/Aug/19/xslt/ - e.g., https://www.congress.gov/119/bills/hr3617/BILLS-119hr3617ih.xml https://www.congress.gov/119/bills/hr3617/BILLS-119hr3617ih.... - the site seems to be even less popular than Longhorn Steakhouse in Germany. My guess is that they'll shuffle people to PDF or move rendering to the server side, which is a common (and, with today's computing power, extremely cheap) way to generate HTML from XML.
- phatskat 1y agoIs it cheaper than sending XML and a stylesheet though? Further, PDF and server-side are fine for achieving the same display, but it removes the XML of it all - that is to say, someone might be using the raw XML to lower tools, feeds, etc. if XSLT goes away and congress drops the XML links in favor of PDFs etc, that breaks more than just the pretty formatting
- cxr 1y ago> If the web used it like crazy we would not be having this conversation. It's been a standard part of the Web platform for years. The only question should be, "Is _anyone_ using it?", not whether it's being "used like crazy" or not. Don't break the Web.