A Look at Xslt 3.0 (2017)
Key topics
The nostalgia-fueled debate around XSLT 3.0 has sparked a lively discussion about the frustrations and benefits of using XML and XSLT. Some commenters, like roadside_picnic and greggman65, lament the complexity and awkwardness of XSLT, while others, like _heimdall and jact, point out that the pain points are largely associated with older versions and specific use cases. Interestingly, a few commenters, such as vgr-land, suggest that modern tools like LLMs (Large Language Models) can mitigate some of the frustrations, while others, like wrs and hackrmn, argue that the real issue lies in the tendency to turn data serialization languages into programming languages. The discussion highlights the nuanced trade-offs between XML, XSLT, and other technologies, with some defending XSLT as "just code" that's good at what it does, while others advocate for alternatives like JSON or XQuery.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
3d
Peak period
20
84-96h
Avg / period
6.4
Based on 45 loaded comments
Key moments
- 01Story posted
Aug 26, 2025 at 9:07 AM EDT
4 months ago
Step 01 - 02First comment
Aug 29, 2025 at 6:27 PM EDT
3d after posting
Step 02 - 03Peak activity
20 comments in 84-96h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 2, 2025 at 12:41 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
JSON is just a homogeneous unnamed bunch of braces and key-val pairs that you loose yourself in once you are several MB in and deeply nested. Need to resort to CLI tools like jq or hunt for the schema or docs.
Massive blobs of YAML, well - they should be simply categorized as a war-crime.
Although for my purposes, I find myself reaching for xquery a lot more often which is a very good and elegant programming language and template language although it was billed as “SQL for XML.”
There just seems to be some misguided human impulse to take every data serialization language and force it to be a programming language, instead of just using a programming language.
Each time so far, there’s been movement for a while, significant pushback, and the one who was championing removal realises it’s hard, and quietly drops it. Smaug from Mozilla bringing it up at a WHATNOT meeting a few months ago looked like it was heading the same way, a “yeah, we’d kinda like to do this, but… meh, see what happens”. Then a few months later Mason Freed of Google decided to try championing it. We’ll see where things go.
Of course, I could be making the same mistake in reading your comment as expressing disagreement with the one you're responding to! If that's not the case, then I'll happily accept my mistake so the chain can hopefully stop here.
(edit: I'm realizing now that this definitely is my own mistake, as I misread which comment this one was replying to. I might need to invest time in finding a new app for reading HN on mobile, since the indentation levels on the one I've been using clearly aren't large enough for my terrible eyesight...)
Maybe they should stop wasting money on pointless, proprietary side tangents before they set out to break standards.
Around the same time, Google tried to deprecate SMIL (SVG animation tech), which would probably have led to its removal after some time. This also failed, and it’s used more than it was then (though CSS animations are probably quite a bit more popular, and have over time become more capable), probably because now all engines support it robustly (MSHTML and EdgeHTML never did).
I hope that we’ll get a more formal commitment to XML and XSLT, and XSLT 3 in browsers, out of this.
This open source Rust implementation needs more help of integrating the full XSLT 3.0 standard into their engine
https://github.com/Paligo/xee
The JSON transformation example is quite simple, and you can accomplish it with one or two lines of JS. But the XLST is unreadable, starting with tons of namespace imports.
The usual argument is that a good UI can fix that, but that’s false. So using XSLT for general data transforms is very problematic: it's hard to read, with no debugging tools, and it’s also hard to build a UI tool that simplifies that for the “citizen integrator” (the segment of people who have technical knowledge and take care of doing integrations but are not experienced with programming).
(Around 2017, I worked for a company that created its own data transformation tool, so I designed the UI editor and did user research of people using transformation languages in different scenarios.)
I wonder if react would be popular today if it started out with the UX/DX we have today. It started out as a comparatively simple component-based library for rendering templates in the browser. It got popular and built a huge community before becoming the complete DX mess that it is today.
I would never go back.
XSLT's "coding UX" is atrocious. Simple things "look complex" and complex things "look obfuscated".
As mentioned in the parent post, there's also this consistent "low leverage" to the code so you feel as if you're typing a lot for little impact.
The XML turned out extremely well, and it's still being used today, such as for bindings in several other languages.
Someone rewrote my XSLT in Python, and I cheered them on, because the result was much more readable, not least of which because the fundamentally procedural steps could be written in a procedural language with a good syntax, rather than XSLT's pure-functional language that suffered from being embedded in XML.
- Variable scoping https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...
- Function definition and application https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...
- Flow control https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...
- Loops https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...
- Module system https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...
Yep, it's a programming language. And not a great one!
edit: zomg mcswell I see you're the person I was replying to in the first place, to this absurd comment:
"First, who decided that XML was a good format to write a programming language in? Punch cards would have been better"
I mean come on.
At any rate, there's absolutely no reason for a command in any programming language to require open and close XML tags: it's a waste of space, and just gets in the way of understanding the program,. If you need to close a command, there are things like {}, semicolons, parens (LISP), exdenting (Python), or even--yes--the 80th column in a punch card.
I remember that in the past Visual Studio had a pretty decent debugger for XSLT.
However, XSLT would be useful with command-line programs too, and not only in a web browser, anyways. (A standalone implementation might also be made to have the ability to load extensions written in C.)
There are problems with XML and with JSON, as well as with XSLT, but when dealing with XML and JSON formats anyways, XSLT can be helpful. (One problem is that XML does not deal very well with types other than Unicode text (JSON has a few additional types but still not very good). XSLT does add some types, though.)
They also mention RDF, but the standard XML format for RDF is not very good in my opinion (although I think someone did make up a better XML format for RDF, for the help of being used with XSLT better).
You give the employee IntelliJ or some IDE of your choice and a way of uploading the transforms into your application and they'll work away. All the complaints about namespaces and the like that your hear online? Never hear from them, they dont think about it, just stick the declarations up in the top of the file and work away.
Abandoning XML has been one of softwares biggest mistakes.