There is a fascinating alternative universe where XML standards actually took hold. I've seen it in bits and pieces. It would have been beautiful.
But that universe did not happen.
Lots of "modern" tooling works around the need. For example, in a world of Docker and Kubernetes, are those standards really that important?
I would blame the adoption of containerization for the lack of interest in XML standards, but by the time containerization happened, XML had been all but abandoned.
Maybe it was the adoption of Python, whose JSON libraries are much nicer than XML. Maybe it was the fact that so few XML specs every became mainstream.
In terms of effort, there is a huge tail in XML, where you're trying to get things working, but getting little in return for that effort. XLST is supposed to be the glue that keeps it all together, but there is no "it" to keep together.
XML also does not play very nice with streaming technologies.
I suspect that eventually XML will make a comeback. Or maybe another SGML dialect. But that time is not now.
> I would blame the adoption of containerization for the lack of interest in XML standards, but by the time containerization happened, XML had been all but abandoned.
Whoa, that doesn't have anything to do with the dislike for XML. We dislike XML because its use is heavily correlated with IBM java tech stack, and that is a complete disaster in usability and project management.
IBM WebSphere with all its fragile XML configuration files, which can't be edited by hand because everything breaks if you try, are my reason to avoid XML since, and if I ever have to choose, I will choose against XML.
Containerisation became a normal practice about a decade after I and the other developers I know, started to avoid XML.
Oh, that would be something! All I want is to be able to make a website with some reusable elements and simple styling and keep adding content for decades, without having to think about keeping up with upgrades, dependencies and shifting framework paradigms.
I have made a couple of simple websites using PHP to bolt on reusable elements (header, footer, navigation), just because it is the solution that probably will work for ~decades without much churn. But XSLT would be even better!
If the P in SPA exists to load your app, then why care? If you’ve noticed the herd thin as SSE and hypermedia trim split ends, then you may see the utility in open web tooling.
That would really be a surprising turn of events, and what a turn it would be! Imagine if the next generation of browsers supported XSLT 3.0—entire cabinets full of blog engines, static page generators, and much more could be rewritten. I support this. XSLT is one of those technologies that is too good to disappear. On the contrary, while some JavaScript frameworks have already turned to dust, I can still rely on my XML toolchains to work in 40 years' time.
I read the Wikipedia on xslt, and as a long time web developer i do not understand at all how this would be useful. Plenty of people here are saying if this tech had taken hold we'd have a better world. Is there a clear example somewhere of why and how?
Ancient history for me but once upon a time my company was developing a web application with C++ that used XSLT to render HTML (with our "API" exposing data via XML). It was fast even then, and gave us a great deal of flexibility. We were certainly fans of XSLT.
It's a mistake to assume that the utility of a tool has anything to do with its adoption.
The real barrier to adoption for any tool are the network effects of other existing tools which create attention barriers and cultural barriers which may hinder adoption of superior alternatives.
A tool has to adhere and build on top of existing conceptual baggage in order to be appealing to the masses of developers.
This is partly because developers believe that the tools they're using now are cutting-edge and optimal... So a radical conceptual reinvention of their current favorite tools will look to them like a step backwards, regardless of how much further it can take them forward.
XSLT is merely a glorified compression/decompression mechanism.
XSLT used as a "stylesheet" in browsers isn't dynamic, so it's like browsing static HTML pages, but expanding of on-the-wire data representation into repetitive HTML is done with XSLT's rules instead of just gzip/brotli (and it doesn't make much difference, because regular compression is really good at compressing the same things that XSLT is good at generating).
For XHTML the effect is almost identical to preprocessing the data server-side, except minor quibbles about whose CPU time is spent on it, how many bytes can be saved.
The only remaining use-case for XSLT is stopping browsers from displaying RSS like garbage, but that's using one browser feature to fix another browser regression. It'd be easier and more helpful to bring back integrated RSS readers, instead giving you very sophisticated technology for apologising how useless the RSS URL is.
XSLT currently provides a lot of value, as the browser can use it to transform documents directly, and it is exposed to JavaScript for scripting. Exploring it recently, including creating a PWA with XML sources reminded me why I like developing on the web. It made me think--RSS feeds can be PWA's now--right?
It seems like XSLT 3.0 would open up a lot of new opportunities and patterns, especially if it continues to work with existing standards, as the current version does. The Web Platform is so cool.
Things like XML and XSLT were useful and nice when I used them in 2004. But that's more than 20 years ago now. It's not something I encounter regularly in modern tech stacks. How widely used is this stuff in browsers at this point? I don't think browsers should be burdened with a lot of complex solutions to serve a few minority/niche use cases.
And even then, using this stuff server side was more common than relying on browsers. XHTML was still being actively pushed and Whatwg kind of made that go away in favor of HTML5. Whatwg was a breadth of fresh air in the whole captial S and lower case s semantic web debates between XML purists on one hand and people just trying to create browsers that worked on the other hand. The latter camp won by virtue of eventually producing browsers that implemented Whatwg standards and then world+dog voting with their feet and making use of those browsers and standards. The whole debate just fizzled out after that.
XSL support in browsers is part of some of the reasons WhatWG was created: a lot of poorly thought through and half specified features being proposed by and rushed through the W3C. Which was putting browser makers on the spot having to support all that in a way that worked well across browsers. The job of "lets just sit down and specify this stuff properly" is why Whatwg was created. That's a job that took many years and it created the modern web and finally enabled high levels of interoperability between browsers.
And there are other mechanisms available to developers that are well endorsed by browser makers and standards. Including using whatever libraries you want in WASM form and running them in a sandboxed environment in a browser. Which is also complex of course but at least is being widely used and well specified at this point. I don't see many compelling reasons for this stuff to live outside of that sandbox.
In the 90s I created a site with XSLT that rendered to HTML. I was tempted by its promises, but in practice I found it hard to use, hard to debug, complicated and extremely verbose. I was glad when I gave it up.
Yes. That's the right solution for the even playground regarding the situation:
Gecko currently has much deeper integration of the XSLT engine with the browser internals: The XSLT engine operates on the browser DOM implementation. WebKit and Chromium integrate with libxslt in a way that's inherently bad for performance ( https://github.com/whatwg/html/issues/11578#issuecomment-321... )
Just Firefox XSLT is faster, better, cheaper than Google's (and JS), same, old Firefox extensions were to powerful Google could compete with Firefox (or block adblocks).
JS is very needed for ads, tracking and other strings attaching - and XSLT is not for that - but would make JS mostly obsolete in many cases.. (only "cross-browser functionality for XSLT is incomplete with certain features like <xsl:text disable-output-escaping="yes"> having open issues" ).
Google pay Mozilla to criple Firefox. It's money from ads, to not let the web be free. Right now, how much $ and CPU power a JS engine could cost, for that, is irrelevant - except for the final user !
Isn't XSLT basically another programming language? Sure it's more limited than JavaScript and has some better built-in support for simple HTML templating, but it's still another full blown programming language. I wonder if we would see all the JS downsides in it if it became more widespread...
Every mention of XSLT should mention XQuery. XQuery has roughly the same features as XSLT. They share the functions and data model. The syntax of XQuery is much nicer though.
XSLT/XQuery 3.0 versus 1.0 is a big upgrade. It includes JSON support and static type checking. At work, our webpage with thousands of pages is statically generated with XQuery 3.
24 comments
[ 3.5 ms ] story [ 46.2 ms ] threadBut that universe did not happen.
Lots of "modern" tooling works around the need. For example, in a world of Docker and Kubernetes, are those standards really that important?
I would blame the adoption of containerization for the lack of interest in XML standards, but by the time containerization happened, XML had been all but abandoned.
Maybe it was the adoption of Python, whose JSON libraries are much nicer than XML. Maybe it was the fact that so few XML specs every became mainstream.
In terms of effort, there is a huge tail in XML, where you're trying to get things working, but getting little in return for that effort. XLST is supposed to be the glue that keeps it all together, but there is no "it" to keep together.
XML also does not play very nice with streaming technologies.
I suspect that eventually XML will make a comeback. Or maybe another SGML dialect. But that time is not now.
Whoa, that doesn't have anything to do with the dislike for XML. We dislike XML because its use is heavily correlated with IBM java tech stack, and that is a complete disaster in usability and project management.
IBM WebSphere with all its fragile XML configuration files, which can't be edited by hand because everything breaks if you try, are my reason to avoid XML since, and if I ever have to choose, I will choose against XML.
Containerisation became a normal practice about a decade after I and the other developers I know, started to avoid XML.
I have made a couple of simple websites using PHP to bolt on reusable elements (header, footer, navigation), just because it is the solution that probably will work for ~decades without much churn. But XSLT would be even better!
https://news.ycombinator.com/item?id=44909599
Google did not unilaterally decide to kill XSLT - https://news.ycombinator.com/item?id=44987239
Recent and also related:
XSLT removal will break multiple government and regulatory sites - https://news.ycombinator.com/item?id=44987346 - Aug 2025 (99 comments)
"Remove mentions of XSLT from the html spec" - https://news.ycombinator.com/item?id=44952185 - Aug 2025 (523 comments)
Should we remove XSLT from the web platform? - https://news.ycombinator.com/item?id=44909599 - Aug 2025 (96 comments)
Unless 3.0 fixes the reasons why 2.0 doesn't exist in the wide world, it'll just lead to more problems.
The real barrier to adoption for any tool are the network effects of other existing tools which create attention barriers and cultural barriers which may hinder adoption of superior alternatives.
A tool has to adhere and build on top of existing conceptual baggage in order to be appealing to the masses of developers.
This is partly because developers believe that the tools they're using now are cutting-edge and optimal... So a radical conceptual reinvention of their current favorite tools will look to them like a step backwards, regardless of how much further it can take them forward.
XSLT used as a "stylesheet" in browsers isn't dynamic, so it's like browsing static HTML pages, but expanding of on-the-wire data representation into repetitive HTML is done with XSLT's rules instead of just gzip/brotli (and it doesn't make much difference, because regular compression is really good at compressing the same things that XSLT is good at generating).
For XHTML the effect is almost identical to preprocessing the data server-side, except minor quibbles about whose CPU time is spent on it, how many bytes can be saved.
The only remaining use-case for XSLT is stopping browsers from displaying RSS like garbage, but that's using one browser feature to fix another browser regression. It'd be easier and more helpful to bring back integrated RSS readers, instead giving you very sophisticated technology for apologising how useless the RSS URL is.
XML/XSLT/CSS/JS: https://kherrick.github.io/x-ml-data/2025/01/exercising-xslt...
XHTML/CSS/JS: https://kherrick.github.io/x-app/2025/01/exercising-xslt/
It seems like XSLT 3.0 would open up a lot of new opportunities and patterns, especially if it continues to work with existing standards, as the current version does. The Web Platform is so cool.
And even then, using this stuff server side was more common than relying on browsers. XHTML was still being actively pushed and Whatwg kind of made that go away in favor of HTML5. Whatwg was a breadth of fresh air in the whole captial S and lower case s semantic web debates between XML purists on one hand and people just trying to create browsers that worked on the other hand. The latter camp won by virtue of eventually producing browsers that implemented Whatwg standards and then world+dog voting with their feet and making use of those browsers and standards. The whole debate just fizzled out after that.
XSL support in browsers is part of some of the reasons WhatWG was created: a lot of poorly thought through and half specified features being proposed by and rushed through the W3C. Which was putting browser makers on the spot having to support all that in a way that worked well across browsers. The job of "lets just sit down and specify this stuff properly" is why Whatwg was created. That's a job that took many years and it created the modern web and finally enabled high levels of interoperability between browsers.
And there are other mechanisms available to developers that are well endorsed by browser makers and standards. Including using whatever libraries you want in WASM form and running them in a sandboxed environment in a browser. Which is also complex of course but at least is being widely used and well specified at this point. I don't see many compelling reasons for this stuff to live outside of that sandbox.
Gecko currently has much deeper integration of the XSLT engine with the browser internals: The XSLT engine operates on the browser DOM implementation. WebKit and Chromium integrate with libxslt in a way that's inherently bad for performance ( https://github.com/whatwg/html/issues/11578#issuecomment-321... )
Just Firefox XSLT is faster, better, cheaper than Google's (and JS), same, old Firefox extensions were to powerful Google could compete with Firefox (or block adblocks).
JS is very needed for ads, tracking and other strings attaching - and XSLT is not for that - but would make JS mostly obsolete in many cases.. (only "cross-browser functionality for XSLT is incomplete with certain features like <xsl:text disable-output-escaping="yes"> having open issues" ).
Google pay Mozilla to criple Firefox. It's money from ads, to not let the web be free. Right now, how much $ and CPU power a JS engine could cost, for that, is irrelevant - except for the final user !
XSLT/XQuery 3.0 versus 1.0 is a big upgrade. It includes JSON support and static type checking. At work, our webpage with thousands of pages is statically generated with XQuery 3.