Should we remove XSLT from the web platform?
1–10 of 99 posts
Re: Should we remove XSLT from the web platform?
#2Some recent discussion on XSLT here:
XSLT – Native, zero-config build system for the Web – 27th June 2025 (328 comments):
https://news.ycombinator.com/item?id=44393817
The only useful thing I have seen it do in the past couple of decades has been to style Atom/RSS feeds. I haven’t personally used it in 25 years. The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for keeping it.
Re: Should we remove XSLT from the web platform?
#3Some recent discussion on XSLT here: XSLT – Native, zero-config build system for the Web – 27th June 2025 (328 comments): https://news.ycombinator.com/item?id=44393817 The only useful thing I have seen it do in the past couple of decades has been to style Atom/RSS feeds. I haven’t personally used it in 25 years. The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for k…
> so it’s hard to make the case for keeping it.
How about “not breaking stuff” which can not be upgraded? Like old sites/services without active maintainers but still useful. Or hardware appliances that still work, but will not get firmware update ever. Let alone rss feeds, brought up multiple times in the linked thread.
Looks like builtin polyfill (similar to pdfjs in FF) would do. But google seems to be reluctant doing it.
Re: Should we remove XSLT from the web platform?
#4Some recent discussion on XSLT here: XSLT – Native, zero-config build system for the Web – 27th June 2025 (328 comments): https://news.ycombinator.com/item?id=44393817 The only useful thing I have seen it do in the past couple of decades has been to style Atom/RSS feeds. I haven’t personally used it in 25 years. The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for k…
> so it’s hard to make the case for keeping it. How about “not breaking stuff” which can not be upgraded? Like old sites/services without active maintainers but still useful. Or hardware appliances that still work, but will not get firmware update ever. Let alone rss feeds, brought up multiple times in the linked thread. Looks like builtin polyfill (similar to pdfjs in FF) would do. But google seems to be reluctant d…
When’s a reasonable time to pull the plug on out of fashion legacy stuff? Things can’t always remain backwards compatible forever. I think the places this is still in use can build contingencies where required
Re: Should we remove XSLT from the web platform?
#5The quality of the github comments: accusing developers of being dictators, being overly emotionally, the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…), the "why not just…" or "hire more people" remarks...
For a browser developer, this is depressing. I've worked on Gecko for 10+ years, and we were constantly called names for absolutely any change we would do. Insulted and accused of the worst intentions.
I see it hasn't changed.
Re: Should we remove XSLT from the web platform?
#6The problem with browsers is that they rely on other standards. If a browser needs to maintain backward compatibility and requires an evolving standard that ALSO requires backward compatibility, this acts like a multiplier on implementation complexity. This also means it becomes increasingly difficult to spin up a new browser engine, and the fewer of those there are, the easier it is for the big ones to just add what they want and have it become a standard, reinforcing the issue.
Re: Should we remove XSLT from the web platform?
#7Some recent discussion on XSLT here: XSLT – Native, zero-config build system for the Web – 27th June 2025 (328 comments): https://news.ycombinator.com/item?id=44393817 The only useful thing I have seen it do in the past couple of decades has been to style Atom/RSS feeds. I haven’t personally used it in 25 years. The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for k…
> so it’s hard to make the case for keeping it. How about “not breaking stuff” which can not be upgraded? Like old sites/services without active maintainers but still useful. Or hardware appliances that still work, but will not get firmware update ever. Let alone rss feeds, brought up multiple times in the linked thread. Looks like builtin polyfill (similar to pdfjs in FF) would do. But google seems to be reluctant d…
Lets remind ourselves that thanks to Google we also did not got WebGL 2.0 Compute, it was too much for Chrome team to spend their resources between WebGL 2.0 Compute and WebGPU.
How great that five years later WebGPU is something we can rely on in portable way. /s
Re: Should we remove XSLT from the web platform?
#8I always kind of liked XSLT but it clearly has not caught on.
Re: Should we remove XSLT from the web platform?
#9[deleted]
Re: Should we remove XSLT from the web platform?
#10Some recent discussion on XSLT here: XSLT – Native, zero-config build system for the Web – 27th June 2025 (328 comments): https://news.ycombinator.com/item?id=44393817 The only useful thing I have seen it do in the past couple of decades has been to style Atom/RSS feeds. I haven’t personally used it in 25 years. The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for k…
The wikipedia api has an option where you can add an xslt stylesheet to its output.
When i was young and stupid and learning to program i made an xslt stylesheet to extract dictionary definitions from the api.
It was meant to be combined with a bookmarklet that when you double clicked a word opened it in an iframe.
It was terrible, but i was so proud of it at the time.
It seems like it stopped working at some point, i guess browsers are probably more strict with mime types now. https://en.wiktionary.org/w/api.php?action=parse&format=xml&...
Sorry if this is too off topic, it just triggered some memories