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!
The <template> element combined with the `cloneNode` works quite well for this. I've got a simple function which can take templates, clone them, fill in nodes with data from a structure, then prepare it to be added to the page.
Works a treat and makes most frameworks for the same seem completely pointless.
Includes are the feature of PHP that made it catch my eye many years ago. Suddenly not having to duplicate shared headers, footers, etc and keep it all up to date across my sites was magical. I could only barely write code at all back then but mixing PHP includes into otherwise plain HTML felt natural and intuitive.
I realize JS might not be to everyone's taste, but I think I've found the absolute minimal JS solution to reuse headers and footers: https://vladimirslepnev.me/write It's almost exactly like PHP but client side, there's no "flash of content" at all.
that's neat. i don't like inline js though. i'd like to be able to load it from a separate file so that i can reuse it on multiple pages.
i am thinking of something like
index.html
<div><navigation/></div>
index.js
function navigation() {
document.querySelector('navigation').replaceWith('<a href="...">...')
}
or maybe
let customnodes = {
navigation: '<a href="...">...',
...
}
then add a function that iterates over customnodes and makes the replacements. even better if i could just iterate over all defined functions. (there is a way, i just didn't take the time to look it up) then the functions could be:
function navigation() {
return '<a href="...">...'
}
and the iterator would wrap that function with the appropriate document.querySelector('navigation').replaceWith call.
PHP is a bit more fragile than it used to be. It is probably a bit for the best but I've had to fix a lot of my 2010-era PHP code to work on PHP 8.x. Though... like, it wasn't super hard. The days you could just start using a variable passed in a URL without setting a default if it wasn't...
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.
3.0 adds JSON support, maps, arrays, to 2.0 - and many other other changes, including streaming and optimizable recursion with the oddly-named xsl:iterate, but the JSON support is biggest for the in-browser uses.
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.
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.
XQuery has a different focus from XSLT. XQuery doesn’t have apply-templates, the document-based implicit dispatch that is so central to XSLT, and it doesn’t have the multiple inheritance possible with overloading templates, but it is stronger in the area of modules, and it assumes (in design) an index, a database.
Programmers tend to prefer XQuery syntax, but note that XPath 3 moves XSLT in that direction too, and XSLT 4 will take it further.
The main strength of XSLT for me is that, together with XML, it enables people who do not consider themselves programmers to do advanced text processing.
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?
I think if you're of the belief that JavaScript is bad and should be avoided when possible this type of thing is seen as an alternative to that. But we've seemingly moved on to server side templating, or dynamic JavaScript apps which solve the problems that XSLT does in a more ergonomic and performant way. Compiling XML templates on the server or at build time is perfectly fine and doesn't require browser support. Doing it on the client leads to performance issues that we saw first hand with older SPA architectures, and if that isn't an issue, client side templating with JavaScript is more capable and ergonomic (imo).
It's a language that describes how to render a document.
For example, you could describe how to render your own domain specific markup language as HTML. Which is then happily viewed by the browser as a regular webpage, that can of course also be styled with CSS as usual.
This is only scratching the surface, really. But it does powerful transformations from one markup language to another.
This can of course be very useful as you get the browser able to present any markup without actually supporting said markup; without scripting or server side components.
It is just a special nostalgia for technologies which never became sucessful. They are percieved as more pure and perfect than the messy real world.
Client side XSLT transforms are very rarely useful. It was intended for a vision of the web as a multiude of different XML formats served to end users. Since this didnt happen (for good reasons), XSLT becase less useful. In reality it is only ever used to tranform into XHTML.
It was also touted as a more powerful style sheet since it could rearrange elements and transform semantic elements into tables for presentation. But CSS supports that now in a much better way, and most significantly CSS can react to dynamic updates.
Serving XML to end users only makes sense if someone actully understands the XML format. But only very few XML formats beside XHTML and SVG have any broad support. RSS is one of the few examples, and seem to be the main use case for XSLT.
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.
No, I don't think that's the right way to characterize it - it's not compression, it's separation of concerns. The original concept for XSLT was to separate the data from the presentation - and many successful systems were built using that technology. Some rendered server-side, some rendered in the browser.
A lot of publishers use XML formats like JATS [1] for articles and other documents. Those are rendered to HTML server-side using XSLT 2/3 and shown to users.
Readit News
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)
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!
Works a treat and makes most frameworks for the same seem completely pointless.
i am thinking of something like
index.html
index.js or maybe then add a function that iterates over customnodes and makes the replacements. even better if i could just iterate over all defined functions. (there is a way, i just didn't take the time to look it up) then the functions could be: and the iterator would wrap that function with the appropriate document.querySelector('navigation').replaceWith call.Edit: I see; you use it as a template further down. My bad for not reading through.
Unless 3.0 fixes the reasons why 2.0 doesn't exist in the wide world, it'll just lead to more problems.
4.0 will add parse-html() too.
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.
Programmers tend to prefer XQuery syntax, but note that XPath 3 moves XSLT in that direction too, and XSLT 4 will take it further.
The main strength of XSLT for me is that, together with XML, it enables people who do not consider themselves programmers to do advanced text processing.
For example, you could describe how to render your own domain specific markup language as HTML. Which is then happily viewed by the browser as a regular webpage, that can of course also be styled with CSS as usual.
Or how to render Markdown as HTML without a Markdown generator (might require rarely implemented XSLT 2.0 with XPath 2.0). See: https://stackoverflow.com/questions/3549827/converting-simpl...
Or render HTML as some other markup language.
This is only scratching the surface, really. But it does powerful transformations from one markup language to another.
This can of course be very useful as you get the browser able to present any markup without actually supporting said markup; without scripting or server side components.
Client side XSLT transforms are very rarely useful. It was intended for a vision of the web as a multiude of different XML formats served to end users. Since this didnt happen (for good reasons), XSLT becase less useful. In reality it is only ever used to tranform into XHTML.
It was also touted as a more powerful style sheet since it could rearrange elements and transform semantic elements into tables for presentation. But CSS supports that now in a much better way, and most significantly CSS can react to dynamic updates.
Serving XML to end users only makes sense if someone actully understands the XML format. But only very few XML formats beside XHTML and SVG have any broad support. RSS is one of the few examples, and seem to be the main use case for XSLT.
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.
[1] https://jats.nlm.nih.gov/ ("Journal Article Tag Suite")
A very simple one - https://wendellpiez.github.io/XMLjellysandwich/IChing/
You might as well say JavaScript is just a compression format for Web assembly language.