XML/XSLT/XPath are great, but XSLT ecosystem has been effectively "frozen" for over a decade in terms of innovation and tooling. The last major step was XSLT 3.0 (2017), which introduced streaming and function integration. However, in practice, no new engines or radically different approaches have emerged since then.
And there is only one free XSLT 3.0 processor available, SAXON-HE (it lacks schema-aware & streaming though)
Oh what filun it was when Internet Explorer supported XSLT natively ... have your webpage content in an RSS file or similar, add XSLT Stylesheet reference and the browser would render it as nice web page. Nice way to have a single page blog without server side code, no generator step or anything.
But well, Firefox didn't do it that way, thus no proper use.
One thing I really appreciated during the peak years of working with XSLT was how much I learned about XPath. Once it clicks, it’s surprisingly intuitive and powerful. I don’t use XSLT much these days, but I still find myself using XPath occasionally. It’s one of those tools—once you understand it, it sticks with you.
Abandoning XML is and continues to be the webs biggest mistake.
Client side templating, custom elements, validation against schemas, native databinding for forms, we could have had it all and threw it away; instead preferring to rebuild it over and over again in React until the end of time.
My impression of XSLT is that there were representatives from every different programming language paradigm on the XSLT standard committee, and each one of them was able to get just enough of what was special about their own paradigm into the standard to showcase it while sabotaging the others and making them all look foolish, but not enough to actually get any work done or lord forbid synergistically dovetail together into a unified whole.
The only way I was ever able to get anything done with XLST was to use Microsoft's script extensions to drop down into JavaScript and just solve the problem with a few lines of code. And that begs the question of why am I not just solving this problem with a few lines of JavaScript code instead of inviting XSLT to the party?
More on XML, XSLT, SGML, DSSSL, and the DDJ interview "A Triumph of Simplicity: James Clark on Markup Languages and XML":
I haven't used XSLT since 2007 but I used it as an alternative to ASP.NET for building some dynamic but not too advanced websites and it had a very impressive performance when cached properly (I believe it was over an order of magnitude faster than just default ASP.NET). I went sleuthing for the framework but I think it's lost. Also the Google Code archive is barely functional anymore, but I did find the XSLT cache function I built for it: https://github.com/blixt/old-google-code-svn/blob/main/trunk...
XSLT is basically regular expressions on steroids: you can do incredibly powerful things with it, fairly quickly ... but good luck understanding the code you wrote when you read it the next day.
XSLT is part of the strange story of why production rules, the basis of many "expert systems" and once thought to have a bright future, never became a mainstream technique in computing.
If somebody were really interested in bring XSLT into the 2020 the best bet may be to drop the XML bit and ask questions like: how do I use production rules to transform a POJO (plain ordinary Java object) into another object, how do I use production rules to transform JSON documents, transform XML/JSON/HTML bidirectionally to and from platform objects, etc. Based on XML it is just too easy to get into the weeds like "should this be represented as an attribute or an child element", namespaces, entities and so many details that get in the way of seeing XSLT for what it is.
I did a lot of XSLT 20 years ago. I worked for a company making an open source CMS that did everything in XML. Content was XML, obviously, pipelines (using Apache Cocoon) were defined in XML, and used XSLT to transform XML into different XML. We got quite proficient in it. We even used XSLT to generate XSLT. A Coworker figured out how to calculate a square root in XSLT (not for production obviously).
It's fun to work in such a declarative way, although all the XML gets tiring. I learned a ton there, though. XSLT is great for its intended purpose, but maybe the fact that you can also use it for other things is a risk.
> It excels in: Modular publishing workflows (DITA
Stopped reading here because the XSLT story with DITA-OT is so godawful that it's been the primary driver to move off DITA altogether at nearly every place I've worked at or with that used it. The one exception spent nearly $1M/year on third-party tooling to get away from having to deal with it, and that tooling under the hood was a Mechanical Turk support engineer writing the XSLTs for their weird-ass custom req.
It's amusing - I still have a visceral negative reaction to XSLT. I can't help it. I spent a couple years down that rabbit hole before realizing what a dead end it all was. I wrote and used my own publishing system using a custom pipeline of transforms, and started down the path of making a UI using XML and dynamic XSLT templates and more. All with a backend of Java and Enterprise Java Beans.
The regret I feel about all this is palpable. I desperately want those hours and hours of coding back.
18 comments
[ 8.7 ms ] story [ 39.8 ms ] threadBut well, Firefox didn't do it that way, thus no proper use.
https://svn.apache.org/repos/asf/commons/sandbox/gsoc/2010/s...
Written as a pipeline of XSLT transformations. Ran natively in the browser to execute SCXML documents to control UI logic. Good times.
> — when written well
LMAO
Client side templating, custom elements, validation against schemas, native databinding for forms, we could have had it all and threw it away; instead preferring to rebuild it over and over again in React until the end of time.
The only way I was ever able to get anything done with XLST was to use Microsoft's script extensions to drop down into JavaScript and just solve the problem with a few lines of code. And that begs the question of why am I not just solving this problem with a few lines of JavaScript code instead of inviting XSLT to the party?
More on XML, XSLT, SGML, DSSSL, and the DDJ interview "A Triumph of Simplicity: James Clark on Markup Languages and XML":
https://news.ycombinator.com/item?id=33728303
Pretty cool to see XSLT mentioned in 2025!
If somebody were really interested in bring XSLT into the 2020 the best bet may be to drop the XML bit and ask questions like: how do I use production rules to transform a POJO (plain ordinary Java object) into another object, how do I use production rules to transform JSON documents, transform XML/JSON/HTML bidirectionally to and from platform objects, etc. Based on XML it is just too easy to get into the weeds like "should this be represented as an attribute or an child element", namespaces, entities and so many details that get in the way of seeing XSLT for what it is.
It's fun to work in such a declarative way, although all the XML gets tiring. I learned a ton there, though. XSLT is great for its intended purpose, but maybe the fact that you can also use it for other things is a risk.
XPath is probably the most useful part of it.
Stopped reading here because the XSLT story with DITA-OT is so godawful that it's been the primary driver to move off DITA altogether at nearly every place I've worked at or with that used it. The one exception spent nearly $1M/year on third-party tooling to get away from having to deal with it, and that tooling under the hood was a Mechanical Turk support engineer writing the XSLTs for their weird-ass custom req.
--
XMLUI
https://news.ycombinator.com/item?id=44625292#44625559 (~30/317 comments; yesterday)
> No mention of XSLT?
(interesting mention of a better way, vintage "kiselyov's SXML/SSAX" for scheme - https://ssax.sourceforge.net/ ?)
--
XSLT – Native, zero-config build system for the Web
https://news.ycombinator.com/item?id=44393817 (328 comments; ~month ago)
The regret I feel about all this is palpable. I desperately want those hours and hours of coding back.
Virtual Machine Management CLI insulated the end-user of any XML.
Virtual Machine Manager GUI (virt-manager) too but also allows end-user to tweak XML directly as well as its GUI ease of use.
Only time that I direct-edit libvirt XML configuration file is to do a DMA passthru setting for NVIDIA CUDA for direct access by VMs.
https://wiki.gentoo.org/wiki/Libvirt
https://wiki.gentoo.org/wiki/Virsh
https://wiki.gentoo.org/wiki/Virt-manager