More than ten years ago a coworker wrote a tool to generate Swift from iOS storyboards, to pass data through segues and give us typed access to identifiers. First version of it used XSLT to transform the storyboard XML. A powerful, if niche technology.
When I first learned that XSLT was going away, I got curious how to achieve the same thing in JS (client-side templating that happens during page load, without any "flash of content"). It turns out there's a very nice way to do it, by using inline scripts that append elements next to document.currentScript. Lean Rada wrote about it here: https://leanrada.com/notes/inline-rendering-currentscript/ and I wrote about it as well: https://vladimirslepnev.me/write
I am still using XSLT. I have been using it for 26 years. I generate XML documents on the backend and turn them into HTML for various reports. XSLT has a lot of features and power that newer templating languages lack.
Are any of these newer templating languages worth me switching?
Their comment isn’t clear if they’re doing the transform on the server before piping it down as HTML, which some implementations have done over the years as it provided access to newer XSLT features that browsers stagnated on.
Shame back in the XHTML days XSLT was a spec that could have made website modularity so much cleaner. I once created an early website creation tool that merged separate components using XSLT it was really powerful in the days before javascript was usable without jQuery. However XHTML was dropped in favor of HTML5 and XSLT was pretty much useless after that. Its done well to survive this long I presume it was mainly kept to style XML files.
HTML5 could have taken the extra step of defining a canonical XML or XML-compatible DOM encoding, or at least encouraged it. But the anti-XML sentiment was explicit and spiteful. Still, popular XSLT processors are built to consume and even produce HTML5, I'm just not sure how thorough those capabilities are or whether they're based on any formal or informal standards. (Maybe the W3C has/had something like that, as part of it's attempts to rollup HTML5 snapshots into versioned standards?)
I lost any enthusiasm for XML after my experience with WDDX and XML-RPC, but as a foundation for HTML it was the best thing going. And maybe still is, given the absence of cross-toolchain contenders? Ditto for XSLT, at least if disregarding the choice to make the syntax homoiconic. In fact I circled back to XSLT long after it was clear it was a dead end. A good tool is a good tool, and the fact it remains so despite the wanton neglect only proves it.
> Well an XHTML parser (and serializer) is a lot simpler
Perhaps, but a combined html and xhtml parser is more complex than just a html parser. Since html already is entrenched, xhtml would be in addition to html, not instead of.
With the benefit of hindsight, if the web had been that way from the beginning, I think we would have been better off. The moment you tested your content in any browser, you'd immediately see if it was broken.
But it wasn't something that could get introduced later, after all the broken content that already existed.
With all respect - the opposite is true. The web succeeded because HTML and HTTP are easy standards easily writable by humans with text editors. HTML was writable by non-programmers.
That's not obviously so. The adoption of JS wasn't particularly hindered by the fact that users have to match their brackets and generally avoid syntax errors.
i think xhtml happened before the wider world of web devs were ready for it. Component based architectures took longer to be adopted than I certainly expected.
It might actually work if reintroduced these days as long as we can consider many components to be valid documents.
Yeah, XSLT 1.0 has some really obvious missteps, so much so that to my knowledge basically nobody just implements XSLT 1.0. What they actually support is (most of) XSLT 1.0 plus a handful of EXSLT extensions (which are completely unofficial and not part of any XSLT spec, by the way). In my opinion the EXSLT stuff is the bare minimum needed to make XSLT 1.0 at least a passable language. Meanwhile, the XSLT spec evolved into 2.0 and 3.0, which as far as I'm aware, even to this day, has no complete open-source implementation.
i just got flashbacks to a past life where i handcrafted XSLT to pre-render output from a service as HTML server side. Of course the front end was running some asp.net version and Microsoft flavored XSLT had lots of quirks.
Good riddance. XSLT and EJB marked the dark ages of software development. For a half decade nothing made sense and programmers and management were going along with the charade until everyone collectively realized it was complete garbage and just stopped using it. I remember replacing an XSLT/EJB system that processed one order per minute with a C++ system written in a week that processed 10,000/minute. A team of a dozen programmers had been working on that XSLT disaster for years.
In the age of LLMs I would expect that legacy code bet carried indefinitely. The LLMs will have it indefinitely in their training data, and with code "cheap" to produce now, what are the good reasons for dropping legacy code?
Your presumption is that code is "cheap" because of LLMs. I am challenging the premise. Maintaining code in production for a product used by billions of people is not cheap, with or without LLMs. Perhaps your shitty disposable code that you write for yourself and never subject anyone else to is cheap now, but if your code is in a large, complex codebase and has to actually work for everyone who uses it, not so much.
LLMs are only getting better and more competent, especially for code well-covered by tests. On such codebases it's definitely cheaper to maintain code with a LLM than by humans alone. I presume then that the XSLT implementation in Chrome is not well-tested.
The breakage that sticks out to me is that IIS in Windows Server outputs some reports as XML+XSLT and these have become nigh unusable for years now.
I ignore every official statement about “support” and simply look at the horse's mouth: Microsoft hasn’t bothered to fix this in IIS, and likely never will.
It’s a dead product, “supported” only in a contractual sense, not a practical one.
(If you called support right now demanding fix for this, they’d tell you that it’s broken by design, have you tried moving to a recurring revenue service offering?)
It is wild to look back at XHTML and see that the W3C were entirely correct about XML. They envisaged a world of schemas, client side templating, custom elements, dynamic forms, the works.
Alas, for laughably bad reasons we had to scrap all that for HTML5, Javascript and CSS; a stack so awful that most devs doing anything on the frontend immediately scramble to React, TypeScript, Tailwind, whatever it takes to avoid the underlying garbage.
A horrid state of affairs that will only get worse as time goes on.
The XHTML/XML/XSLT tooling was bad, and XSLT was hard to reason about. That meant that amateurs had no way to learn it, and those amateurs went to school and became the workforce.
The web became a winner because it was easy to get something working. And then Google made it a mission to make great developer tools in everyone's hands for free.
I think in 2026 we could build the tooling around a better experience, but it would require thinking about the developer experience first.
You could do some awesome things with XML/XSL. My favorite was RSS feeds or OPML collections of RSS feeds (both flavors of XML) calling an XSL transformation when viewed in a web browser instead of mined by computers for data; same with TEI files, although that was a bit more arcane. The idea was that you'd have one data file for machine use and a way to present that data to humans as a web page.
But, as a stack, the XML/XSL/XPath/etc combination was weak because XSLT was hard to comprehend and never updated. No browser supports XSLT 2 or 3; they froze support with 1. XSLT 2 was 2007, a year before HTML 5 was a thing, yet it never got picked up by browsers. Javascript was just easier to understand than XSLT. Development of XHTML was also glacial, and people wanted new tags, especially for video.
> XSLT 2 was 2007, a year before HTML 5 was a thing, yet it never got picked up by browsers. Javascript was just easier to understand than XSLT.
Turns out that tasks easily done by programming languages are best done by programming languages. Who knew?
JSON allowing frontends and backends to communicate in a way analogous to the "smart endpoints, dumb pipes" model for networking saved the Web. The XML adherents wanted the inverted model, which was always insanely difficult to reason about and led to entirely XML-specific security threats.
I can't help but agree, and sometimes I think about the alternate version of the web where XML realized its full potential as the dominant technology. The obvious problem with XML is that the syntax is so verbose and redundant that it's only barely human-writable, but this is 100% a solvable problem.
The article says as much in the opening. It also includes a statement from Microsoft noting they do not intend to carry this forward separately, with a salient comment in one of the Microsoft page citations:
> For functionality and compatibility reasons, Microsoft Edge adopts nearly all of the Chromium project's changes to the web platform. However, Microsoft retains full control of the Microsoft Edge browser and may defer or reject changes.
Removed features don't always follow the same timelines either (and not just because of a lag in syncing to upstream Chromium).
More than ten years ago a coworker wrote a tool to generate Swift from iOS storyboards, to pass data through segues and give us typed access to identifiers. First version of it used XSLT to transform the storyboard XML. A powerful, if niche technology.
When I first learned that XSLT was going away, I got curious how to achieve the same thing in JS (client-side templating that happens during page load, without any "flash of content"). It turns out there's a very nice way to do it, by using inline scripts that append elements next to document.currentScript. Lean Rada wrote about it here: https://leanrada.com/notes/inline-rendering-currentscript/ and I wrote about it as well: https://vladimirslepnev.me/write
That Lean Rada article is really fun!
I am still using XSLT. I have been using it for 26 years. I generate XML documents on the backend and turn them into HTML for various reports. XSLT has a lot of features and power that newer templating languages lack.
Are any of these newer templating languages worth me switching?
Yes, because XSLT won't work in Chrome and Edge anymore.
Their comment isn’t clear if they’re doing the transform on the server before piping it down as HTML, which some implementations have done over the years as it provided access to newer XSLT features that browsers stagnated on.
You can still run JS or WebAssembly based XSLT transformer
A great way to convince you you've always been wrong:
Step 1: Gain browser monopoly
Step 2: Generate fake security scare
Step 3: Gaslight everyone that only way to mitigate is to get rid of it completely like Flash.
Step 3a (corollary): There isn't anyone available that can fix the bugs because we spent all resources on UI/UX experimentation
Thank you for reminding me that we don't have Flash anymore. I'm counting blessings I forgot I had.
Shame back in the XHTML days XSLT was a spec that could have made website modularity so much cleaner. I once created an early website creation tool that merged separate components using XSLT it was really powerful in the days before javascript was usable without jQuery. However XHTML was dropped in favor of HTML5 and XSLT was pretty much useless after that. Its done well to survive this long I presume it was mainly kept to style XML files.
HTML5 could have taken the extra step of defining a canonical XML or XML-compatible DOM encoding, or at least encouraged it. But the anti-XML sentiment was explicit and spiteful. Still, popular XSLT processors are built to consume and even produce HTML5, I'm just not sure how thorough those capabilities are or whether they're based on any formal or informal standards. (Maybe the W3C has/had something like that, as part of it's attempts to rollup HTML5 snapshots into versioned standards?)
I lost any enthusiasm for XML after my experience with WDDX and XML-RPC, but as a foundation for HTML it was the best thing going. And maybe still is, given the absence of cross-toolchain contenders? Ditto for XSLT, at least if disregarding the choice to make the syntax homoiconic. In fact I circled back to XSLT long after it was clear it was a dead end. A good tool is a good tool, and the fact it remains so despite the wanton neglect only proves it.
> HTML5 could have taken the extra step of defining a canonical XML or XML-compatible DOM encoding, or at least encouraged it.
Yeah and then we could have called it xhtml5. Too bad that does not exist. Oh wait https://html.spec.whatwg.org/multipage/xhtml.html
> But the anti-XML sentiment was explicit and spiteful.
No, xhtml was just a bad idea creating tons of problems and solving none.
> xhtml was just a bad idea creating tons of problems and solving none.
Well an XHTML parser (and serializer) is a lot simpler, which is a pretty meaningful problem to solve.
What problems does xhtml create?
> Well an XHTML parser (and serializer) is a lot simpler
Perhaps, but a combined html and xhtml parser is more complex than just a html parser. Since html already is entrenched, xhtml would be in addition to html, not instead of.
The main one is that even a slightly broken XHTML document will fail to render. HTML is much more forgiving.
With the benefit of hindsight, if the web had been that way from the beginning, I think we would have been better off. The moment you tested your content in any browser, you'd immediately see if it was broken.
But it wasn't something that could get introduced later, after all the broken content that already existed.
Yeah, I think SGML HTML as the first pass was a mistake. All my early websites were XHTML until people called them "bad"...
With all respect - the opposite is true. The web succeeded because HTML and HTTP are easy standards easily writable by humans with text editors. HTML was writable by non-programmers.
I don't think "parsed strictly" makes something hard; on the contrary, I think it's helpful to make something easy. Clear feedback, easy to test.
But then, I've always preferred strongly typed over stringly typed.
This imagines HTML as code and not markup.
The reason HTML and markdown are more widely adopted than latex is because the former are more forgiving.
I am thinking of it as markup. I stand by the point: I think "forgiving" is not a feature in parsing; it's a bug.
That's not obviously so. The adoption of JS wasn't particularly hindered by the fact that users have to match their brackets and generally avoid syntax errors.
I'm curious, what exactly in the DOM is not XML-compatible?
From long-lost memory, I think it's implicitly closed tags (e.g. img).
XML can handle implicitly closed tags, they call them "empty" in the spec here:
https://www.w3.org/TR/xml/#sec-starttags
i think xhtml happened before the wider world of web devs were ready for it. Component based architectures took longer to be adopted than I certainly expected.
It might actually work if reintroduced these days as long as we can consider many components to be valid documents.
There is nothing component-based about xhtml compared to html. It is just html with xml syntax.
And the rendering was very slow back at the day.
The XSLT 1.0 spec specifically was written pretty badly, though, to my recollection; I had a hard time at making sense of it
Yeah, XSLT 1.0 has some really obvious missteps, so much so that to my knowledge basically nobody just implements XSLT 1.0. What they actually support is (most of) XSLT 1.0 plus a handful of EXSLT extensions (which are completely unofficial and not part of any XSLT spec, by the way). In my opinion the EXSLT stuff is the bare minimum needed to make XSLT 1.0 at least a passable language. Meanwhile, the XSLT spec evolved into 2.0 and 3.0, which as far as I'm aware, even to this day, has no complete open-source implementation.
i just got flashbacks to a past life where i handcrafted XSLT to pre-render output from a service as HTML server side. Of course the front end was running some asp.net version and Microsoft flavored XSLT had lots of quirks.
Good riddance. XSLT and EJB marked the dark ages of software development. For a half decade nothing made sense and programmers and management were going along with the charade until everyone collectively realized it was complete garbage and just stopped using it. I remember replacing an XSLT/EJB system that processed one order per minute with a C++ system written in a week that processed 10,000/minute. A team of a dozen programmers had been working on that XSLT disaster for years.
XSLT is glorious, too bad.
In the age of LLMs I would expect that legacy code bet carried indefinitely. The LLMs will have it indefinitely in their training data, and with code "cheap" to produce now, what are the good reasons for dropping legacy code?
The obvious answer is that LLMs are not quite the machine gods they're marketed as, innit.
I don't understand what you're saying.
Your presumption is that code is "cheap" because of LLMs. I am challenging the premise. Maintaining code in production for a product used by billions of people is not cheap, with or without LLMs. Perhaps your shitty disposable code that you write for yourself and never subject anyone else to is cheap now, but if your code is in a large, complex codebase and has to actually work for everyone who uses it, not so much.
LLMs are only getting better and more competent, especially for code well-covered by tests. On such codebases it's definitely cheaper to maintain code with a LLM than by humans alone. I presume then that the XSLT implementation in Chrome is not well-tested.
> what are the good reasons for dropping legacy code?
Reducing attack surface.
That is a good reason. Is XSLT known for security problems the same way that CGI was?
What will we do for RSS/Atom feeds?
Style them with CSS. https://danfabulich.medium.com/beautify-your-rss-atom-feeds-...
Not style them?
Use css to style them instead?
There's a long discussion about XSLT removal here: https://github.com/whatwg/html/issues/11578#issuecomment-595... (the link is to the comment with this proposal https://github.com/doriantaylor/swet which already is much better than any templating proposal "the platform" is trying to push)
https://web.archive.org/web/20261017201132/https://doctor-se... while it gives 503
The breakage that sticks out to me is that IIS in Windows Server outputs some reports as XML+XSLT and these have become nigh unusable for years now.
I ignore every official statement about “support” and simply look at the horse's mouth: Microsoft hasn’t bothered to fix this in IIS, and likely never will.
It’s a dead product, “supported” only in a contractual sense, not a practical one.
(If you called support right now demanding fix for this, they’d tell you that it’s broken by design, have you tried moving to a recurring revenue service offering?)
It is wild to look back at XHTML and see that the W3C were entirely correct about XML. They envisaged a world of schemas, client side templating, custom elements, dynamic forms, the works.
Alas, for laughably bad reasons we had to scrap all that for HTML5, Javascript and CSS; a stack so awful that most devs doing anything on the frontend immediately scramble to React, TypeScript, Tailwind, whatever it takes to avoid the underlying garbage.
A horrid state of affairs that will only get worse as time goes on.
They were wrong about one thing: tooling matters.
The XHTML/XML/XSLT tooling was bad, and XSLT was hard to reason about. That meant that amateurs had no way to learn it, and those amateurs went to school and became the workforce.
The web became a winner because it was easy to get something working. And then Google made it a mission to make great developer tools in everyone's hands for free.
I think in 2026 we could build the tooling around a better experience, but it would require thinking about the developer experience first.
You could do some awesome things with XML/XSL. My favorite was RSS feeds or OPML collections of RSS feeds (both flavors of XML) calling an XSL transformation when viewed in a web browser instead of mined by computers for data; same with TEI files, although that was a bit more arcane. The idea was that you'd have one data file for machine use and a way to present that data to humans as a web page.
But, as a stack, the XML/XSL/XPath/etc combination was weak because XSLT was hard to comprehend and never updated. No browser supports XSLT 2 or 3; they froze support with 1. XSLT 2 was 2007, a year before HTML 5 was a thing, yet it never got picked up by browsers. Javascript was just easier to understand than XSLT. Development of XHTML was also glacial, and people wanted new tags, especially for video.
> XSLT 2 was 2007, a year before HTML 5 was a thing, yet it never got picked up by browsers. Javascript was just easier to understand than XSLT.
Turns out that tasks easily done by programming languages are best done by programming languages. Who knew?
JSON allowing frontends and backends to communicate in a way analogous to the "smart endpoints, dumb pipes" model for networking saved the Web. The XML adherents wanted the inverted model, which was always insanely difficult to reason about and led to entirely XML-specific security threats.
I can't help but agree, and sometimes I think about the alternate version of the web where XML realized its full potential as the dominant technology. The obvious problem with XML is that the syntax is so verbose and redundant that it's only barely human-writable, but this is 100% a solvable problem.
yet people will say that HTML5 is all you need or something
503
So, this site breaks, we know that much
doctor-seo dot net has failed us. What is this world coming to?
Edge is Chrome.
The article says as much in the opening. It also includes a statement from Microsoft noting they do not intend to carry this forward separately, with a salient comment in one of the Microsoft page citations:
> For functionality and compatibility reasons, Microsoft Edge adopts nearly all of the Chromium project's changes to the web platform. However, Microsoft retains full control of the Microsoft Edge browser and may defer or reject changes.
Removed features don't always follow the same timelines either (and not just because of a lag in syncing to upstream Chromium).
Looks like the site broke