←back to thread

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

(github.com)
392 points _kush | 5 comments | 27 Jun 25 05:00 UTC | HN request time: 0s | source
Show context
badmintonbaseba ◴[27 Jun 25 08:37 UTC] No.44394985[source]▶
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.
replies(9): >>44395187 #>>44395285 #>>44395306 #>>44395323 #>>44395430 #>>44395839 #>>44396146 #>>44397330 #>>44398324 #
1. larodi ◴[27 Jun 25 16:54 UTC] No.44398324[source]▶
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.

replies(1): >>44399938 #
2. j45 ◴[27 Jun 25 20:25 UTC] No.44399938[source]▶
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?

replies(1): >>44402576 #
3. larodi ◴[28 Jun 25 06:01 UTC] No.44402576[source]▶
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.

replies(2): >>44402811 #>>44410827 #
4. masklinn ◴[28 Jun 25 07:04 UTC] No.44402811{3}[source]▶
If XPath was the core nobody would need xslt, because pretty much every xml library can do XPath.

Don’t get me wrong, XPath is by far the best thing to come out of the xml ecosystem, but the actual idea at the core of xslt is the match/patch during traversal, and talking about it in terms of selection misses that boat entirely. Select / update is how you manipulate a tree with jQuery, or really the average xml library.

5. j45 ◴[29 Jun 25 06:49 UTC] No.44410827{3}[source]▶
I recall seeing some libraries on github that convert back and forth between xslt and json... and another short hand version that was much clearer from Juniper I believe.