Should the Web Platform Adopt Xslt 3.0?
Posted4 months agoActive4 months ago
github.comTechstoryHigh profile
calmmixed
Debate
70/100
XsltWeb DevelopmentXMLBrowser Technology
Key topics
Xslt
Web Development
XML
Browser Technology
The discussion revolves around whether the web platform should adopt XSLT 3.0, with some users nostalgic for its potential and others questioning its relevance and usefulness in modern web development.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
2h
Peak period
87
Day 1
Avg / period
21.6
Comment distribution108 data points
Loading chart...
Based on 108 loaded comments
Key moments
- 01Story posted
Aug 22, 2025 at 1:56 PM EDT
4 months ago
Step 01 - 02First comment
Aug 22, 2025 at 4:21 PM EDT
2h after posting
Step 02 - 03Peak activity
87 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 1, 2025 at 8:46 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 44987552Type: storyLast synced: 11/20/2025, 4:47:35 PM
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.
But that universe did not happen.
Lots of "modern" tooling works around the need. For example, in a world of Docker and Kubernetes, are those standards really that important?
I would blame the adoption of containerization for the lack of interest in XML standards, but by the time containerization happened, XML had been all but abandoned.
Maybe it was the adoption of Python, whose JSON libraries are much nicer than XML. Maybe it was the fact that so few XML specs every became mainstream.
In terms of effort, there is a huge tail in XML, where you're trying to get things working, but getting little in return for that effort. XLST is supposed to be the glue that keeps it all together, but there is no "it" to keep together.
XML also does not play very nice with streaming technologies.
I suspect that eventually XML will make a comeback. Or maybe another SGML dialect. But that time is not now.
XHTML being based on XML tried to be a strict standard in a world where a non-strict standard existed and everybody became just very much aware on a daily that a non-strict standard is much easier to work with.
I think it's very hard to compete with that.
Know what? Life's too short to lose time to remembering to close a self-closing tag.
About the time XHTML 1.1 came along, we collectively bailed and went to HTML5, and it was a breath of fresh air.
Then React introduced faux-XML as JSX except with this huge machinery of a runtime javascript virtual DOM instead of basic template expansion and everyone loves it? And if this react playground I've opened up reflects reality, JSX seems to literally require you to balance opening/closing your tags. The punch-line of the whole joke.
What was the point of this exercise? Why do people use JSX for e.g. blogs when HTML templating is built into the browser and they do nothing dynamic? For many years it's been hard to shake the feeling that it isn't some trick to justify 6 figure salaries for people making web pages that are simple enough that an 8 year old should be up to the task.
That same nagging feeling reassures me about our AI future though. Easy ways to do things have been here the whole time, yet here we are. I don't think companies are as focused on efficiency as they pretend. Clearly social aspects like empire building dominate.
It was pretty evident when it happened, particularly because XHTML in some browsers was parsed with a sloppy HTML parser, and in some with an XML parser which was strict. Guess what happened. Tons of invalid XHTML was out there and it made it impossible to parse as XML.
Combined with Firefox and MSIE having different combinations of HTTP headers and doctype declarations to specify XHTML mode, it was way too hard to emit one single doc that was viewable on all common browsers. For a while my life involved regularly chasing down random issues that suddenly made our customers' browsers show an error page instead of the content, even when it was actually valid and passed all validators.
I don't miss this.
...but real HTML templating isn't built-in to HTML[1]. Its absence for these 30 years is as huge a mystery as why there's no combobox input element (combination textbox+drop-down) or <select>'s limitations.
[1] What I mean by this is that JS+DOM still has no simple way of escaping HTML in a string. It's insane.
To elaborate: if you have a some arbitrary strings (unsanitized user input): `headerText` and `firstParagraph` that you want to render to a HTML fragment like `<h2>{headerText}</h2><p>{firstParagraph}</p>` then the only real way of doing this safely is by using the (archaic and verbose) DOM Level 1 methods (document.createElement, textContent = 'text', etc) which somehow always turn what-should-be a 1-liner pure-function in any sane language to a 10-line function with side-effects (...and as it's 2025 then it will probably be async too).
When JS added support for template-literals, I was excited that this might mean an end to the embarrassing problem, but because it didn't ship with HTML-escaping it means it's useless for that purpose - unless you're going to go through the effort to implement a full "tagged template" with a parser function, which I assume would handle the DOM parts.
Asterisk: except namespaces, I loathe those, you are skipping happily along chewing through your XML, xpathing left and right, and then find out some psychopath has decided to use namespaces, and now every thing has become super awkward and formal.
Well, I guess we could do it like libraries in C-land and have every schema add its own informal identifier prefix to avoid name collisions. But there’s a reason why programming languages moved to namespaces as an explicit notion.
XHTML would have made the Semantic Web (capital letters) possible. Someone else could have done search better. We might have had a proper P2P web.
They wanted sloppy, because only Google scale could deal with that.
Hopefully the AI era might erode that.
XHTML's failure had nothing to do with it, and is basically unrelated. Even if xhtml won i fail to see how that would have helped semantic web in any way shape or form.
Not sure why just as good as JSON, if you are going to stream and parse you need a low level push or pull parser not a DOM just like JSON. See SAX for Java or XmlReader / XmlWriter in .Net.
XSLT 3 even had a streaming mode I believe which was badly needed but had constraints due to not having the whole document in memory at once.
I liked XSLT but there is no need for it, javascript is good enough if not better, many times you needed to do a xslt script tag to get some thing done it couldn't do on its own anyway, might as well use a full language with good libraries for handling XML instead. See Linq to XML etc.
Again don't really agree, its just most developers don't seem to understand the difference between a DOM or parsing JSON into a full object vs using a streaming reader or writer so they need to be hand fed a format that forces it on them such as line based CSV.
Maybe if JSON and XML allowed top level multiple documents / objects it would have helped like JSON lines.
The pro-XML narrative always sounded like what you wrote, as far back as I can remember: The XML people would tell you it was beautiful and perfect and better than everything as long as everyone would just do everything perfectly right at every step. Then you got into the real world and it was frustrating to deal with on every level. The realities of real-world development meant that the picture-perfect XML universe we were promised wasn't practical.
I don't understand your comparison to containerization. That feels like apples and oragnes.
And those bizarre designs went straight into XML, properties often in attributes, nodes that should have been attributes, over nesting, etc.
And we blamed XML for the mess where often it was just inexperience in software design as an industry that was the real cause. But XML had too much flexibility compared to the simplicity of the later JSON, meaning it helped cause the problem. JSON 'solved' the problem by being simpler.
But then the flip side was that it was too strict and starting one in code was a tedious pita where you had to specify a schema even though it didn't exist or even matter most of the time.
The hard truth is that XML lost to the javascript-native format (JSON). Any JavaScript-native format would have won, because "the web" effectively became the world of JavaScript. XML was not js-friendly enough: the parsing infrastructure was largely based on C/C++/Java, and then you'd get back objects with verbose interfaces (again, a c++/java thing) rather than the simple, nested dictionaries that less-skilled "JS-first" developers felt at ease with.
It's a dumber format but that makes it a better lingua franca between all sorts of programming languages, not just Javascript, especially if you haven't locked in on a schema.
Once you have locked in on a schema and IDL-style tooling to autogenerate adapter classes/objects, then non-JSON interchange formats become viable (if not superior). But even in that world, I'd rather have something like gRPC over XML.
"Data" lives on a spectrum of simple to complex; most is simple; JSON is great for that. But not for everything.
I agree, but let's be honest, how often does this actually come up for data interchange. Because the situations where you want a human-editable document that is also computer-legible are fairly few in number. Prose in office documents, human-written documentation for code, config files.
For things where computer programs are driving the show (which is most the time, today), you want interchange designed for programming languages, whether that's JSON, CSV, gRPC, or what have you.
This even applies to documents that are completely computer-generated: get the inputs into an appropriate data structure using easy interchange formats, and then render to the output document (HTML, XML, LaTeX, etc.).
> Data" lives on a spectrum of simple to complex; most is simple; JSON is great for that. But not for everything.
Fully agreed. But even where you do have documents, XML is not always the right thing either, which is why there are other markup formats in wide usage like TeX and Doxygen/Javadoc-style comments. XML seems best aligned to things like office document formats or other rich text where it makes sense to want to wrap some human text inside some computer-visible markers.
Pretty much anywhere with text-heavy payloads? It's quite a lot, I think, but still dwarfed by the number of cases where system A needs to perform some sort of RPC-like communication with system B.
I just think that there is plenty of room in the world for both approaches.
I think the reason is that it solved the "problem" of integrating XML into JavaScript, as if being good at XML was an end in itself. Once XML started being replaced by JSON in earnest, what was the pressing need for E4X? Doing stuff in SOAP or WS-* presumably, but that wasn't a common use case in browser JavaScript, though it might have come in handy if Node.js took off a bit earlier.
JSX took off because it helped frontend developers solve problems outside of JSX. Look at examples of its use and it's heavily intertwined with the rest of what you'd see on a webpage (HTML, JS and CSS), and you never get the sense that JSX is a "self-licking ice cream cone".
The few staunch XML supporters I worked with always wanted to divert blame to something else, refusing to acknowledge that maybe XML was the wrong tool for the job or even contributing to the problems.
In practice, it doesn't matter.
If the JSON payload is in the wrong format the server rejects it with an error.
If the server sends an integer "by mistake" then the purists would argue that the client should come to a halt and throw up an error to the user. Meanwhile the JSON users would see an integer coming back for the id field and use it, delivering something that works with the server as it exists today. Like it or not, this is why JSON wins.
Schema defined protocols are very useful in some circumstances, but in my experience the added overhead of keeping them in sync everywhere and across developers is a lot of overhead for most simple tasks.
Putting the data into a simple JSON payload and sending it off gets the job done in most cases.
It’s a mediocre data storage language.
This makes sense.
However, there are two ways to address it:
1) Work towards a more advanced system that addresses the issues (for example, RDF/Turtle – expands XML namespaces to define classes and properties, represents graphs instead of being limited to trees unlike XML and JSON)
2) Throw it away and start from scratch. First, JSON. Then, JSON schema. Jq introduces a kind of "JSONPath". JSONL says hi to XML stream readers. JSONC because comments in config files are useful. And many more primitives that existed around XML were eventually reimplemented.
Note how the discussion around removing XSLT 1 support similarly has two ways forward: yank it out or support XSLT 3.
I lean towards Turtle replacing XML over JSON, and for XSLT 3 to replace XSLT 1 support in the browsers.
Don't miss that they were reimplemented properly.
Even XML schemas, the one thing you'd think they were great at, ended up seeing several different implementation beyond the original DTD-based schema definitions and beyond XSD.
Some XML things were absolute tire fires that should have been reimplemented even earlier, like XML-DSIG, SAML, SOAP, WS-everything.
It's not surprising devs ended up not liking it, there are actual issues trying to apply XML outside of its strengths. As with networking and the eventual conceit of "smart endpoints, dumb pipes" over ESBs, not all data formats are better off being "smart". Oftentimes the complexity of the business logic is better off in the application layer where you can use a real programming language.
Of course not! W3C SHACL shapes, on the other hand...
schema.org is also a move in the right direction
XML without attributes probably would have seen wide and ready adoption.
“Keep things flat” is current good advice in terms of usability. That means favor attributes over children.
I do agree that attributes/data was always a huge contention point on where things should go and caused confusion and bikeshedding.
I also saw a bit of this in the React/JSX community with decisions like render props, HoC, etc where it took a bit to stabilize on best practices.
Imagine if instead of the current Dockerfile format, we used XML, which was dynamically generated from lists of packages, and filtered and updates according to RSS feeds describing CSVs and package updates.
I’m not saying this is anything other than strange fantasy. And not a particularly nice fantasy either.
XML failed because it forced devs to spend tons of unproductive time on it
They tended to be design by comittee messes that included every possible use case as an option.
Anyone who has ever had the misfortune of having to deal with SAML knows what i'm talking about. Its a billion line long specification, everyone only implements 10% of it, and its full of hidden gotchas that will screw up your security if you get them wrong. (Even worse, the underlying xml-signature spec is literally the worst way to do digital signatures possible. Its so bad you'd think someone was intentionally sabotaging it)
In theory this isn't xml's fault, but somehow XML seems to attract really bad spec designers.
JSON is too simplistic.
Something built from s-expressions would probably have been ideal but we've known that for 70 years.
Now I do think there is a need for the complexity supported by XML to exist, but 99% of the time JSON or similar is good enough while being easy to work with.
That all said, XHTML was amazing. I’d have loved to see XHTML become the standard for web markup. But alas that wasn’t to be.
So XHTML lost to the much more forgiving HTML.
There was an idea to make a forgiving XML for web use cases: https://annevankesteren.nl/2007/10/xml5 but it never got traction.
But I do agree that I’m likely in the minority of people (outside of web developers at least) that thought that way.
What a pity.
With JSON you can dump data structures from about any language straight out and it's okay to start toying around and experimenting. Over time you might add logic for filtering out some fields, rename others, move stuff a little around without too much trouble.
Also quickly writing the structure up by hand works a lot faster in any editor, without having to repeat closing tags (while at some point closing brackets and braces will take their tribute)
However I agree: once you got the XML machinery, there is a lot of power in it.
The idea behind XLST is nice — creating a stylesheet to transform raw data into presentation. The practice of using it was terrible. It was ugly, it was verbose, it was painful, it had gotchas, it made it easier for scrapers, it bound your data to your presentation more, and so on.
Most of the time I needed to generate XML to later apply a XLST style sheet, the resulting XML document was mostly a one off with no associated spec and not a serious transport document. It begged the question of why I was doing this extra work.
The entire point of XSLT is to separate your data from its presentation. That's why it made it easy to scrape. You could return your data in a more natural domain model and transform it via a stylesheet to its presentation.
And in doing so it is incredibly concise (mostly because XPath is so powerful).
It got abandoned because it sucks. New technology gets adopted because it's good. XML standard were just super meh and difficult to work with. There's really not much more to it than that.
Not sure how that is true. XML is a specification for a data format, but you still need to define the schema (i.e., elements, attributes, their meaning). It's not like XML for web pages (XHTML?) could also serve as XML for Linux container descriptions or as XML for Android app manifests.
Whoa, that doesn't have anything to do with the dislike for XML. We dislike XML because its use is heavily correlated with IBM java tech stack, and that is a complete disaster in usability and project management.
IBM WebSphere with all its fragile XML configuration files, which can't be edited by hand because everything breaks if you try, are my reason to avoid XML since, and if I ever have to choose, I will choose against XML.
Containerisation became a normal practice about a decade after I and the other developers I know, started to avoid XML.
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.
https://news.ycombinator.com/item?id=44909599
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.
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.
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.
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.
Gecko currently has much deeper integration of the XSLT engine with the browser internals: The XSLT engine operates on the browser DOM implementation. WebKit and Chromium integrate with libxslt in a way that's inherently bad for performance ( https://github.com/whatwg/html/issues/11578#issuecomment-321... )
Just Firefox XSLT is faster, better, cheaper than Google's (and JS), same, old Firefox extensions were to powerful Google could compete with Firefox (or block adblocks).
JS is very needed for ads, tracking and other strings attaching - and XSLT is not for that - but would make JS mostly obsolete in many cases.. (only "cross-browser functionality for XSLT is incomplete with certain features like <xsl:text disable-output-escaping="yes"> having open issues" ).
Google pay Mozilla to criple Firefox. It's money from ads, to not let the web be free. Right now, how much $ and CPU power a JS engine could cost, for that, is irrelevant - except for the final user !
Hopefully that could be enough to complete the evidence to split Google into pieces in antitrust case - or realizing that will make Google to back off ?
no, it don't wont :) that's the point
---
WWW made of interlinked documents,
yet making it to be interlinked code too.. may not last, as codes like changing and finding new ways.
Fancy stuff as JS may be very useful and I like it too, momentary, when well applied, but it needs: an effort to use it, keep working, adapting, if interoperating, all specific, for the purpose - and power, can't open 1000s tabs. Different kind of being. More fun, like with the hammer for everyhthing - not shy like XSLT trying be transparent.
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.
The real barrier to adoption for any tool are the network effects of other existing tools which create attention barriers and cultural barriers which may hinder adoption of superior alternatives.
A tool has to adhere and build on top of existing conceptual baggage in order to be appealing to the masses of developers.
This is partly because developers believe that the tools they're using now are cutting-edge and optimal... So a radical conceptual reinvention of their current favorite tools will look to them like a step backwards, regardless of how much further it can take them forward.
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)
And even then, using this stuff server side was more common than relying on browsers. XHTML was still being actively pushed and Whatwg kind of made that go away in favor of HTML5. Whatwg was a breadth of fresh air in the whole captial S and lower case s semantic web debates between XML purists on one hand and people just trying to create browsers that worked on the other hand. The latter camp won by virtue of eventually producing browsers that implemented Whatwg standards and then world+dog voting with their feet and making use of those browsers and standards. The whole debate just fizzled out after that.
XSL support in browsers is part of some of the reasons WhatWG was created: a lot of poorly thought through and half specified features being proposed by and rushed through the W3C. Which was putting browser makers on the spot having to support all that in a way that worked well across browsers. The job of "lets just sit down and specify this stuff properly" is why Whatwg was created. That's a job that took many years and it created the modern web and finally enabled high levels of interoperability between browsers.
And there are other mechanisms available to developers that are well endorsed by browser makers and standards. Including using whatever libraries you want in WASM form and running them in a sandboxed environment in a browser. Which is also complex of course but at least is being widely used and well specified at this point. I don't see many compelling reasons for this stuff to live outside of that sandbox.
XML/XSLT/CSS/JS: https://kherrick.github.io/x-ml-data/2025/01/exercising-xslt...
XHTML/CSS/JS: https://kherrick.github.io/x-app/2025/01/exercising-xslt/
It seems like XSLT 3.0 would open up a lot of new opportunities and patterns, especially if it continues to work with existing standards, as the current version does. The Web Platform is so cool.