XSLT – Native, zero-config build system for the Web

I have worked for a company that (probably still is) heavily invested in XSLT for XML templating. It's not good, and they would probably migrate from it if they could.

  1. Even though there are newer XSLT standards, XSLT 1.0 is still dominant. It is quite limited and weird compared to the newer standards.

  2. Resolving performance problems of XSLT templates is hell. XSLT is a Turing-complete functional-style language, with performance very much abstracted away. There are XSLT templates that worked fine for most documents, but then one document came in with a ~100 row table and it blew up. Turns out that the template that processed the table is O(N^2) or worse, without any obvious way to optimize it (it might even have an XPath on each row that itself is O(N) or worse). I don't exactly know how it manifested, but as I recall the document was processed by XSLT for more than 7 minutes.

JS might have other problems, but not being able to resolve algorithmic complexity issues is not one of them.

XSLt is not easy. It’s prologue on shrooms so to speak and it has a steep learning curve. Once mastered gives sudoku level satisfaction, but can hardly ever be a standard approach to built or templating as normally people need much less to achieve goals.

Besides XML is not universally loved.

Universal love is one factor, best tool for a job may leave only a few choices including XML.

It's not my first choice, but I won't rule it out because I know how relatively flexible and capable it can be.

XSLT might just need a higher abstraction level on top of it?

Perhaps it rather needs a facelift and support for JSON. I would imagine one day something regex or jq-level concise emerges, something reasonably short and descriptive, to allow transforming arbitrary tree into another arbitrary tree.

The idea behind XSLT is genial, but the real essence of it is XPath which makes it possible. And we've seen XPath evolve into CSS Selectors, and being useful on its own.

So in essence there are two sides of the transformation:

  - selection - when you designate which parts of the tree match
  - transformation - when building the new three

And while there are established approaches to the first part, perhaps XSLT is the only one which fits the definition of 'generally accepted' when it comes to the transformation.

But one can argue the transformation is possible with jq, it is just that I definitely don't like its overly-engineered syntax. IMHO the champion of the transformation syntax is yet undecided, even though in 2025 XSLT is still more or less king. Which is fascinating as XML is long not a usual choice of preference.