It's nice to see this. Things used to be simple! (XSLT itself should've been simpler of course).
BTW, as I commented on earlier HN threads re: removal of XSLT support from HTML spec and browswers, IBM owns a high-performance XSLT implementation that they may want to consider contributing to one or more browsers. (It is a JIT that generates machine code directly from XSLT and several other data transformation and policy languages, and then executes it).
I don’t think XSLT 1.0 is all that complicated. It’s a declarative language for transforming trees into trees or strings in an arbitrary manner, and you could argue that problem statement is too wide, but if you’re OK with it then I don’t think there’s any inappropriate complexity in the solution.
The surface syntax is bad, true, but that’s because of its verbosity, not its complexity. Once you put a bit of an Algol veneer on it[1], it becomes perfectly palatable.
I think it would be very unlikely browsers would use a jit engine for xslt. They are removing it because they are afraid of the security footprint. A JIT engine would make that footprint much worse.
Not necessarily. The security issues are with the libxml implementation, a different one might be more secure even with JIT. That's part of what makes the whole situation so ridiculous.
Still, from a security perspective considering the low amount of sites that use it I think a better solution would be to implement it with a JS shim like PDF.js.
JS is already required to have a XML DOM parser, an universal XSLT engine in JS should be a low-effort web to continue supporting XSLT, as for performance the transform could probably be eval'ed and cached to JS snippets so that they in turn become JIT-compiled.
There are multiple CVEs in multiple Chrome-only non-standards that Chrome spits out by the hundreds in the past few years. They have no issues releasing those, supporting them, and fixing them.
Somehow they have an issue with supporting, fixing (and updating to latest version) this particular one. Possibly because it doesn't result in promotions.
Even without arguing over whether JIT engines are inherently risky or add much risk given the modern computing environment is full of them, from graphics to Javascript.
One recommendation I’d make: replace RSS with Atom. Outside of podcasting, everything that supports RSS supports Atom, and Atom is just better, in various ways that actually matter for content correctness, and in this case in ways that make it easier to process. One of the ways that matters here: Atom <published> uses RFC 3339 date-time, rather than the mess that is RSS’s pubDate. As it stands, you’re generating an invalid JSON-LD datePublished. (If you then want to convert it into a format like “25 August 2025”, you’ll have to get much fancier with substringing and choosing, but it’s possible.)
One of the nice things about Atom is that you can declare whether text constructs (e.g. title, content) are text (good if there’s to be no markup), HTML encoded as text (easiest for most blog pipelines), or HTML as XML (ideal for XSLT pipelines).
Absolutely nothing. Technically, it’s strictly worse. People even added other namespaces to patch up some of its deficiencies, e.g. <content:encoded>.
I think the reason that RSS is used can be summed up as: Apple is lousy at developer relations.
They didn’t invent podcasting (name or technology), but they were the first major player to do stuff with it. Although consensus was already strong that RSS was technically terrible and Atom had existed for over a year (though it was not finalised) and was even fairly popular, Google especially having embraced it⸻ Apple chose the old-and-inferior RSS as their foundation. And then stuck their heads in the sand and didn’t talk to anyone, ever. Because that’s Apple’s style: throw stuff out there, let people do what they want with it, don’t attempt to be a community leader.
So what did everyone else do? Feeds had to be RSS, of course, to appease Apple. And then other apps implemented RSS, just RSS, like Apple had done, because what’s even the point of using Atom if it won’t work on the biggest platform? General-purpose feed readers didn’t have much specialised functionality, and had a few major players and a long tail of other clients; it was a much more well-distributed field, all things considered. But podcasting was, as I understand it, much more only one player for a while, then only up to two or three; and it depended on more specialised functionality. So it was never as democratic as general web feeds.
Over time podcast feeds ended up a horrible mess of repeating the same logical field 3–6 times in differently-named elements for different platforms, as they all added their own namespaces and mostly-identical-but-sometimes-slightly-different data fields¹. Because people were using it as an actual data format with domain-specific fields, they were more likely to just use an XML parser and talk just RSS, rather than a feed library which would be RSS-/Atom-neutral.
I believe that at some point Apple did implement Atom (not sure when), but it was too late, too much other stuff didn’t support it and so no one used it and so they ripped it out again a couple of years ago, and podcasting is set in stone using the inferior RSS.
I should write this up further at some point: the tragedy of podcast feeds.
—⁂—
¹ This stupid pattern can be seen on the web too. <meta name=description>, <meta property=og:description>, <meta name=twitter:description>, something in a JSON+LD block…
For your possible interest, my own https://chrismorgan.info/atom.xsl is the most thorough Atom Feed Document stylesheet that I know of.
(I did also make an RSS version of it, https://temp.chrismorgan.info/2022-05-10-rss.xsl, including handling RSS’s stupid date format as perfectly as possible for some reason. It would actually be a useful guide for reversing that process, too…)
For maximum enthusiasm in this direction, make posts actual Atom Entry Documents. Will it benefit anyone? … well, I suppose it could be convenient for tooling to make a feed by just concatenating documents.
The core concept behind XSLT is evergreen: Being able to programmatically transform the results of a HTTP request into a document with native tools is still useful. I don't foresee any equivalent native framework for styling JSON ever coming into being though.
I could easily imagine a functional-programming JSON transformation language, or perhaps even a JSLT based on latest XSLT spec. The key in these things is to constraing what is can do.
We wouldn't even need anything as complex as XSLT, or a functional language for transforming JSON. Other markup-based template processing systems exist for higher-level languages like Pug, Mustache, etc. for Node.js. You could achieve a lot with a template engine in the browser!
> I want to see XSL import an XML. I want to see the reverse. XSL will be the view. XML will be the model. And the browser will be the controller. MVC paradigm.
It then dawned on me that the MVC framework for XML is where XML is the model (or data or database table). And XSLT is the viewer in the rear. Meaning the web browser can browse database information.
I never appreciated this very much before. The web has this incredible format to see database information in raw form or a styled form.
I still want to see development of it in reverse, and I hope to find better use cases now that I understand this paradigm.
It would not make sense to start from an XSLT. An XSLT is only a set of transformation rules (a transformation stylesheet). If there is nothing to transform, then the stylesheet produces nothing.
But you can kind of achieve what you want by treating the initial XML as a "view definition/configuration", and the referenced XSLT as a "view builder", and referencing your "model" as an external document via XPath document and applying to the XSLT template(s). i.e. you create configurations of your view that apply external data.
Depends on the task, JSON won because it was so simple whilst XML is waaay to complex. Maybe an alternative to JSON with just a tad more complexity for sanity could have won 20 years ago, but alas it never happened.
JSON is less complex because it only solves some of the problems that XML solves. That doesn't make it better or worse, but adding schema support or attempting to make REST APIs with JSON because complex, and IMO fragile, quickly.
It solves the important problems that XML solved, without the mistakes.
What is it missing? I think only namespacing, but that isn't really necessary in JSON because it isn't a document format where arbitrary elements can appear in arbitrary places. I have never once needed namespacing in JSON.
Schemas... well there's JSON schema which is ok I guess. But in reality you probably don't want that either. Schemas are useful for IDEs and linters but that's it. Normally you validate a JSON file by parsing it, e.g. with Pydantic or Serde or Zod.
The biggest missing feature from XML that JSON should have had is comments! Yes it was a mistake to omit them.
Validating JSON with third party runtime libraries like zod is only necessary because JSON doesn't support schemas though. There's nothing wrong with those libraries, they solve a real problem but the problem is in JSON itself.
The whole point of REST was to allow visitors to not only see the response to a request but to also be able to understand both the semantics and the functionality of it.
Think HTML - it would be comparatively useless if HTML could only contain structured data with meaning, semantics, or schemas. Anchor tags, buttons, and forms are semantic and tell the user not only what a piece of text is but how they can interact with it.
With JSON you have to know the shape of requests supported, the shape of data returned, and how to use that data to make other requests.
> Validating JSON with third party runtime libraries like zod is only necessary because JSON doesn't support schemas though.
No this is completely backwards. First of all, JSON Schema exists. Second libraries like Serde and Pydantic aren't schema validators; they are parsers. They parse strings (or sometimes dynamically typed JSON) into statically typed objects that you can actually use in your program. That's what you should use.
A program that uses a separate schema validator and then blindly trusts the result is badly designed. There's even a name for this mistake - "parse don't validate" (you can Google it).
> With JSON you have to know the shape of requests supported, the shape of data returned, and how to use that data to make other requests.
Obviously. XML doesn't magically avoid the need for API documentation! I'm wondering if you've ever actually used XML at this point....
On the contrary I think they did the right thing in not supporting any schema it.
1: The "simpleness" made it easy for producers/consumers with unstructured languages (ie JS,Python,PHP,Ruby,etc) to participate in the ecosystem without feeling that things were "bloated" (technically a drawback perhaps but pushed popularity)
2: DTD was put into the standard, but from my recollection most stuff was defined with XSD in practice (so a separate standard), so now implementations needed to carry both deprecated stuff and another layer. (Then again, sure you could generate bindings with XSD).
3: We needed 3 versions of Swagger/OpenAPI to come to a somewhat good standardized binding API (it itself depends/extends JSON Schema), but it's there today and we don't need to consider deprecated libraries,etc and can just point our code-generators to the schema documents and get automatic bindings.
So in practice you basically have no fragility today even if there is binding generator bugs, but that feels more of an implementation issue than a systematic error, and if anything it shows that schema generators.
Now one could argue that the "free-ness" of the JSON Format made schema generators needlessly cumbersome, and maybe that's true to a certain extent but it's still not nearly as bad as trying to interpret ASN.1 files despite all the standards (there it is.. "good luck trying to find the correct IDL files").
Nice one! Although it seems that the engineers at the different browser vendors are committed to remove XSLT due to reasons outlined here [1]. It's a shame these Discussions got so heated, but that's just the nature of the internet, I guess.
Unfortunately a topic like this is perfect bait for a lot of the resentments folks have with the modern internet ecosystem.
There’s some rarely used tech that few have talked about in a long time. Tech giants have decided somewhat unilaterally to get rid of it because it’s barely used and has had security flaws.
There’s a discussion to be had about that specifically but most people didn’t care a jot about XSLT until it was threatened. What they do care about is tech giants controlling the fate of the internet. That’s a far bigger issue than can be solved in a GitHub discussion, but it doesn’t stop anyone trying.
<item>
<title>Last Blog Post</title>
<description>
I am Jack's XML Parser. I consume unclosed tags I kill jack.
</description>
<link>https://xsltblogdemo.vgr.land/content/posts/20250707.xml</link>
<guid isPermaLink="false">post-20250707</guid>
<pubDate>Mon, 7 Jul 2025 13:00:00 +0000</pubDate>
<author>vgr.xsltbf@example.com (vgr)</author>
</item>
With this:
<post
title="Last Blog Post"
description="I am Jack's XML Parser. I consume unclosed tags I kill jack."
link="https://xsltblogdemo.vgr.land/content/posts/20250707.xml"
isPermaLink="false"
guid="post-20250707"
pubDate="Mon, 7 Jul 2025 13:00:00 +0000"
author="vgr.xsltbf@example.com (vgr)">
Content of the post....
</post>
I wonder why everybody want's to use XSLT on the client side. On te Server side it is so powerful and works like a charme with PHP:
// XML
$xml_doc = new DOMDocument();
$xml_doc->load("file1.xml");
// XSL
$xsl_doc = new DOMDocument();
$xsl_doc->load("file.xsl");
// Proc
$proc = new XSLTProcessor();
$proc->importStylesheet($xsl_doc);
$newdom = $proc->transformToDoc($xml_doc);
As long as the LLM crawler fetches the XML in the first place I assume it would be fine. Lighthouse is trying to score the rendered HTML, the LLM just needs to understand what's in the document and it can parse the XML directly.
It's good to see more real-world applications of XSLT in browsers. There were some other excellent examples before the current discussion about removing XSLT support from browsers. Here is an easy one to get started with: https://xsl-website.widloski.com/
Why use HTML specifically? Markdown generator/transformer based frameworks can usually transform markdown into every commonly used html tag and for the tags that it can’t, you can just write html in the markdown file, just seems like you’re adding a ton of extra cruft imo.
Nice!
I always wanted to build an XSLT that parses Markdown and outputs HTML, but was lacking the time. That would elevate your blog framework to a wider audience.
I guess I just don't get the point. In order for the page to load it needed to make four round trips on the server sequentially which ended up loading slower than my bloated javascript spa framework blog on a throttled connection. I don't really see how this is preferential to html, especially when there is a wealth of tools for building static blogs. Is it the no-build aspect of it?
It did make all those requests, but only because the author set up caching incorrectly. If the cache headers were to be corrected, site.xsl, pages.xml, and posts.xml would only need to be downloaded once.
The cache headers are correct, you can't indefinitely cache those because they might change. Maybe you could get away with a short cache time but you can't cache them indefinitely like you can a javascript bundle.
Not to mention on a more involved site, each page will probably include a variety of components. You could end up with deeper nesting than just 4, and each page could reveal unique components further increasing load times.
I don't see much future in an architecture that inherently waterfalls in the worst way.
There are cache times other than 0 and infinity. Ideally the XSLT would change rarely, as would things like nav menus. So "relatively short" could mean several minutes to an hour. And with ETags the resource could be revalidated before expiry and never have to be re-downloaded.
With HTTP/2 multiplexing all of those requests can be made in a batch without round trips. And complexity of caching? An Etag done right is content-based. There's no logic to worry about.
It's really unfortunate that this style of architecture lost the battle. It's elegant. Data cleanly separated from presentation, small digestible entities, and it all kind of makes sense. But what killed it was the verbosity of XML, as well as its extreme pedantry that results in lack of robustness where a single error would kill the entire transform. Also transformation-based systems notoriously lack proper tools for debugging early on. Lastly, typically buggy implementations of pipelining in HTTP/1.1 made it so that you actually had to make those round trips. But conceptually we had all the pieces to make it work well back in the early 2000s.
Hm - how would multiplexing help here? Does the browser read ahead and process cached assets to find dependencies before firing off etag requests in a batch? I'd be surprised if that was the case.
The appeal of XML is semantic. I think about things in a certain way. I write the text the way I think, inventing XML elements and structure as I go. Then I transform it into whatever. This obscures the semantic, but the transformation is transient, merely to present this to the user.
To do this dynamically I serve the content as I wrote it with a single processing instruction that refers to a stylesheet. This is elegant, isn't it? It is less efficient than a static site, but not that different from a typical HTML: HTML, CSS, JS. It is also trivial to change it to build statically (or to embed all the resources and XSLT into individual XML files, although this would be strange.)
And if browsers supported alternative stylesheets it would be trivial to provide alternative renderings at the cost of one processing instruction per rendering. Why don't they? Isn't this puzzling? I think it is even in the specification.
I get it, but if we're building things for others to use the elegance of our solutions doesn't matter. What matters is things like the efficiency, the experience of using it, not writing it. And I think browsers should serve the end user, not the developer. If we sacrifice some elegance for security that seems like a win for the user. Even if we lose some of the elegance of the abstraction, that's not what it's about.
Of course everyone is free to create things they want with their own abstractions, but let's not pretend that it's an optimal solution. Elegance and optimal are often at odds.
Disclaimer: it's possible XSLT got better over time, although I doubt it.
I actually wrote a whole app that used XSLT back 25 years ago, even backed by an XML database! Super hip (tech stack wasn't my choice).
XSLT is bad tech and you shouldn't use it. The modern equivalent is React+JSON which implements many of the same ideas in a much better way. And I say that as someone who isn't a big React fan but who has used both. It's not a coincidence that this example is for a 1999-era static blog; it's about the limit of what you can do with this tech.
The core idea of XSLT is to provide a functional transform from an app-specific model to a view, where both are expressed in XML. It does that by asking you to supply templates that match patterns in the original data structure. This idea has some deep flaws:
1. The syntax and generic data model used to express your app's own model has to be XML, but XML is descended from a line of technologies intended to express views. XML-based languages are a competent enough way to express a view which is why React invented JSX, but they are less natural for expressing data structures. Modern apps use JSON for expressing data structures which is also far from ideal but it's still an improvement over XML.
2. Transforms from data to view can be arbitrarily complex. React uses a regular imperative programming language with some additional rules to make it "functional-ish", XSLT gives you XPath and what is basically an XML syntax for something a bit like Haskell. Expressing complex transforms is very awkward in this language. Something as simple as a for loop over a list - very easy in JS - requires you to think in pure functional terms in XSLT.
3. Modularity? Debugging? Nope. It's Web Tech, what do you expect? If you make a syntax error you might get a parse error if you're lucky, if you make a logic error you get to sit down with a pen and paper to work out what might be going wrong. Because it's a functional transform rather than a programming language there isn't even really printf style logging. And IIRC there's no such thing as XSLT libraries.
4. There is no solution for interactivity. Mutating the model might yield retransformation depending on implementation (I don't know for modern browsers, I think I mostly tested on IE6 back in the day). If it does, it'll be a retransform of the entire document that blows away any changes to the DOM. But if you want actual app-level state in UI components that efficiently re-render, then you're just out of luck, you have to mutate the generated HTML DOM directly as if XSLT didn't exist at all.
5. There is no functioning protocol for controlling server-side rendering or not (in practice most XSLT based apps give up on browser rendering pretty quickly). Soooooo the original motivation of exposing the app's data structures directly allowing machine-readable access to data, does not actually apply in practice, because there's no systematic way to ask the server to give you the raw XML. Sure a tiny number of servers might actually serve you something different if you use an Accept header with text/xml up front, but even when XSLT was hip apps that did that in the wild were unicorn poop. People claimed they saw one once, but I never actually tracked down a real server that did it.
This blog demo could have been implemented using Preact and the results would be better. The view logic would be much easier to read and write. The underlying data would be a JSON file, or perhaps a combination of JSON and Markdown, i.e. syntaxes designed for the convenient expression of data and marked up text. The browser would still take care of rendering, and the server could easily do the render work up front to make things snappy by avoiding extra roundtrips. The advantage would be that debugging, modularity and retransformation for interactivity all work well.
Agreed, having worked with a few people who thought xslt is the bee knees it's just not very good at all for this type of thing. In fact I'd say it's not very good at anything really.
My thoughts:
1) It's fragile. As xml is so dynamic small changes in the data can mean your transform doesn't work or worse that it does run but doesn't transform to the correct thing anymore
2) Hard to actually make xslt work. Like there are no decent debugging tools the best you'll get is a site you can plug in data and it will auto run the transformation. The devex here is really really poor which is why I'm baffled anyone would build this. As you say it's a transform language so you can't really step through it you just have to run it and see
3) Very hard to test properly. The amount of times something small would change in the data and then the transforms wouldn't work was awful. The "unit testing" we done was produce a bunch of XML and then run the transforms and check the XML. Like I couldn't actually test parts of the transform as I was going
4) Most importantly was maintenance. XSLT seemed to be a write only language as in hardly anyone as able to pickup someone elses transform and figure it out.
The people who liked it normally only used it for toy applications.
Yeah it seems a bit nuts to me. Zero type safety, zero debugging story, no libraries, unusual syntax, it's not expressive like Javascript or other "real" programming languages, no interactivity, bad performance...I just don't get why people love it.
It's nice to see this. Things used to be simple! (XSLT itself should've been simpler of course).
BTW, as I commented on earlier HN threads re: removal of XSLT support from HTML spec and browswers, IBM owns a high-performance XSLT implementation that they may want to consider contributing to one or more browsers. (It is a JIT that generates machine code directly from XSLT and several other data transformation and policy languages, and then executes it).
> XSLT itself should've been simpler of course
I don’t think XSLT 1.0 is all that complicated. It’s a declarative language for transforming trees into trees or strings in an arbitrary manner, and you could argue that problem statement is too wide, but if you’re OK with it then I don’t think there’s any inappropriate complexity in the solution.
The surface syntax is bad, true, but that’s because of its verbosity, not its complexity. Once you put a bit of an Algol veneer on it[1], it becomes perfectly palatable.
[1] https://juniper.github.io/libslax/slax-manual.html
I think it would be very unlikely browsers would use a jit engine for xslt. They are removing it because they are afraid of the security footprint. A JIT engine would make that footprint much worse.
Not necessarily. The security issues are with the libxml implementation, a different one might be more secure even with JIT. That's part of what makes the whole situation so ridiculous.
Still, from a security perspective considering the low amount of sites that use it I think a better solution would be to implement it with a JS shim like PDF.js.
JS is already required to have a XML DOM parser, an universal XSLT engine in JS should be a low-effort web to continue supporting XSLT, as for performance the transform could probably be eval'ed and cached to JS snippets so that they in turn become JIT-compiled.
https://developer.mozilla.org/en-US/docs/Web/API/DOMParser
Whether or not it is actually secure, as a factual matter, has nothing to do with its security footprint.
Emphasis on might be. Finding out whether it actually is is not a trivial process.
There are multiple CVEs in multiple Chrome-only non-standards that Chrome spits out by the hundreds in the past few years. They have no issues releasing those, supporting them, and fixing them.
Somehow they have an issue with supporting, fixing (and updating to latest version) this particular one. Possibly because it doesn't result in promotions.
This often ends up as an anti-Google argument but all the major browser makers agree with this deprecation proposal.
I don't think that follows, esp. since when we're talking about a mature, actively commercially maintained JIT engine.
Why not? JIT engines are inherently risky. They are great for performance but terrible for security.
Briefly, because
overall risk = new inherent risk / (architecture * security reputation * ongoing maintenance investment)
Even without arguing over whether JIT engines are inherently risky or add much risk given the modern computing environment is full of them, from graphics to Javascript.
One recommendation I’d make: replace RSS with Atom. Outside of podcasting, everything that supports RSS supports Atom, and Atom is just better, in various ways that actually matter for content correctness, and in this case in ways that make it easier to process. One of the ways that matters here: Atom <published> uses RFC 3339 date-time, rather than the mess that is RSS’s pubDate. As it stands, you’re generating an invalid JSON-LD datePublished. (If you then want to convert it into a format like “25 August 2025”, you’ll have to get much fancier with substringing and choosing, but it’s possible.)
One of the nice things about Atom is that you can declare whether text constructs (e.g. title, content) are text (good if there’s to be no markup), HTML encoded as text (easiest for most blog pipelines), or HTML as XML (ideal for XSLT pipelines).
> Outside of podcasting, everything that supports RSS supports Atom, and Atom is just better
Is there something (besides (lack of) client support) that makes RSS better suited for podcasting?
Absolutely nothing. Technically, it’s strictly worse. People even added other namespaces to patch up some of its deficiencies, e.g. <content:encoded>.
I think the reason that RSS is used can be summed up as: Apple is lousy at developer relations.
They didn’t invent podcasting (name or technology), but they were the first major player to do stuff with it. Although consensus was already strong that RSS was technically terrible and Atom had existed for over a year (though it was not finalised) and was even fairly popular, Google especially having embraced it⸻ Apple chose the old-and-inferior RSS as their foundation. And then stuck their heads in the sand and didn’t talk to anyone, ever. Because that’s Apple’s style: throw stuff out there, let people do what they want with it, don’t attempt to be a community leader.
So what did everyone else do? Feeds had to be RSS, of course, to appease Apple. And then other apps implemented RSS, just RSS, like Apple had done, because what’s even the point of using Atom if it won’t work on the biggest platform? General-purpose feed readers didn’t have much specialised functionality, and had a few major players and a long tail of other clients; it was a much more well-distributed field, all things considered. But podcasting was, as I understand it, much more only one player for a while, then only up to two or three; and it depended on more specialised functionality. So it was never as democratic as general web feeds.
Over time podcast feeds ended up a horrible mess of repeating the same logical field 3–6 times in differently-named elements for different platforms, as they all added their own namespaces and mostly-identical-but-sometimes-slightly-different data fields¹. Because people were using it as an actual data format with domain-specific fields, they were more likely to just use an XML parser and talk just RSS, rather than a feed library which would be RSS-/Atom-neutral.
I believe that at some point Apple did implement Atom (not sure when), but it was too late, too much other stuff didn’t support it and so no one used it and so they ripped it out again a couple of years ago, and podcasting is set in stone using the inferior RSS.
I should write this up further at some point: the tragedy of podcast feeds.
—⁂—
¹ This stupid pattern can be seen on the web too. <meta name=description>, <meta property=og:description>, <meta name=twitter:description>, something in a JSON+LD block…
Thanks for the suggestion I’ll dig into this, admittedly I haven’t worked with Atom so I didn’t consider it
A quick glance at Atom though says to me its worth an attempt to refactor.
For your possible interest, my own https://chrismorgan.info/atom.xsl is the most thorough Atom Feed Document stylesheet that I know of.
(I did also make an RSS version of it, https://temp.chrismorgan.info/2022-05-10-rss.xsl, including handling RSS’s stupid date format as perfectly as possible for some reason. It would actually be a useful guide for reversing that process, too…)
For maximum enthusiasm in this direction, make posts actual Atom Entry Documents. Will it benefit anyone? … well, I suppose it could be convenient for tooling to make a feed by just concatenating documents.
The core concept behind XSLT is evergreen: Being able to programmatically transform the results of a HTTP request into a document with native tools is still useful. I don't foresee any equivalent native framework for styling JSON ever coming into being though.
If I'm not mistaken, XSLT 3 works with JSON too. It'd be nice to see that shipped in browsers instead of seeing v1 removed.
I could easily imagine a functional-programming JSON transformation language, or perhaps even a JSLT based on latest XSLT spec. The key in these things is to constraing what is can do.
We wouldn't even need anything as complex as XSLT, or a functional language for transforming JSON. Other markup-based template processing systems exist for higher-level languages like Pug, Mustache, etc. for Node.js. You could achieve a lot with a template engine in the browser!
JSX!
That's not... really the same.
> I don't foresee any equivalent native framework for styling JSON ever coming into being though.
Well yeah I hope not! That's what a programming language is for, to turn data into documents.
XSLT 2.0 is Turing complete.
So are many esoteric languages, but I doubt people would appreciate me comparing XSLT to Brainfuck or FORTRAN 66.
Having something declarative is good here, and XSL fills that.
Let’s rewrite W3C into XML and xslt.
A few HN posts ago I commented this
> I want to see XSL import an XML. I want to see the reverse. XSL will be the view. XML will be the model. And the browser will be the controller. MVC paradigm.
It then dawned on me that the MVC framework for XML is where XML is the model (or data or database table). And XSLT is the viewer in the rear. Meaning the web browser can browse database information.
I never appreciated this very much before. The web has this incredible format to see database information in raw form or a styled form.
I still want to see development of it in reverse, and I hope to find better use cases now that I understand this paradigm.
It would not make sense to start from an XSLT. An XSLT is only a set of transformation rules (a transformation stylesheet). If there is nothing to transform, then the stylesheet produces nothing.
But you can kind of achieve what you want by treating the initial XML as a "view definition/configuration", and the referenced XSLT as a "view builder", and referencing your "model" as an external document via XPath document and applying to the XSLT template(s). i.e. you create configurations of your view that apply external data.
Haven't seen this much interest in XML/XSLT in 20 years.
Fortunately! It was cool to do the easy things, but then you had monstruous path expressions, and all sort of programmatical drama.. Pfff...
did you know that XSLT was shown to be Turing complete ? https://staff.emu.edu.tr/zekibayram/Documents/papers/XSLT_Tu...
On the other side, I find XML/XSD still much better than JSON. JSON is way too simple...
Depends on the task, JSON won because it was so simple whilst XML is waaay to complex. Maybe an alternative to JSON with just a tad more complexity for sanity could have won 20 years ago, but alas it never happened.
JSON is less complex because it only solves some of the problems that XML solves. That doesn't make it better or worse, but adding schema support or attempting to make REST APIs with JSON because complex, and IMO fragile, quickly.
It solves the important problems that XML solved, without the mistakes.
What is it missing? I think only namespacing, but that isn't really necessary in JSON because it isn't a document format where arbitrary elements can appear in arbitrary places. I have never once needed namespacing in JSON.
Schemas... well there's JSON schema which is ok I guess. But in reality you probably don't want that either. Schemas are useful for IDEs and linters but that's it. Normally you validate a JSON file by parsing it, e.g. with Pydantic or Serde or Zod.
The biggest missing feature from XML that JSON should have had is comments! Yes it was a mistake to omit them.
Validating JSON with third party runtime libraries like zod is only necessary because JSON doesn't support schemas though. There's nothing wrong with those libraries, they solve a real problem but the problem is in JSON itself.
The whole point of REST was to allow visitors to not only see the response to a request but to also be able to understand both the semantics and the functionality of it.
Think HTML - it would be comparatively useless if HTML could only contain structured data with meaning, semantics, or schemas. Anchor tags, buttons, and forms are semantic and tell the user not only what a piece of text is but how they can interact with it.
With JSON you have to know the shape of requests supported, the shape of data returned, and how to use that data to make other requests.
> Validating JSON with third party runtime libraries like zod is only necessary because JSON doesn't support schemas though.
No this is completely backwards. First of all, JSON Schema exists. Second libraries like Serde and Pydantic aren't schema validators; they are parsers. They parse strings (or sometimes dynamically typed JSON) into statically typed objects that you can actually use in your program. That's what you should use.
A program that uses a separate schema validator and then blindly trusts the result is badly designed. There's even a name for this mistake - "parse don't validate" (you can Google it).
> With JSON you have to know the shape of requests supported, the shape of data returned, and how to use that data to make other requests.
Obviously. XML doesn't magically avoid the need for API documentation! I'm wondering if you've ever actually used XML at this point....
On the contrary I think they did the right thing in not supporting any schema it.
1: The "simpleness" made it easy for producers/consumers with unstructured languages (ie JS,Python,PHP,Ruby,etc) to participate in the ecosystem without feeling that things were "bloated" (technically a drawback perhaps but pushed popularity)
2: DTD was put into the standard, but from my recollection most stuff was defined with XSD in practice (so a separate standard), so now implementations needed to carry both deprecated stuff and another layer. (Then again, sure you could generate bindings with XSD).
3: We needed 3 versions of Swagger/OpenAPI to come to a somewhat good standardized binding API (it itself depends/extends JSON Schema), but it's there today and we don't need to consider deprecated libraries,etc and can just point our code-generators to the schema documents and get automatic bindings.
So in practice you basically have no fragility today even if there is binding generator bugs, but that feels more of an implementation issue than a systematic error, and if anything it shows that schema generators.
Now one could argue that the "free-ness" of the JSON Format made schema generators needlessly cumbersome, and maybe that's true to a certain extent but it's still not nearly as bad as trying to interpret ASN.1 files despite all the standards (there it is.. "good luck trying to find the correct IDL files").
Nice one! Although it seems that the engineers at the different browser vendors are committed to remove XSLT due to reasons outlined here [1]. It's a shame these Discussions got so heated, but that's just the nature of the internet, I guess.
[1]: https://github.com/whatwg/html/issues/11523#issuecomment-318...
//Edit: Rephrased "PRs" to "Discussions".
Unfortunately a topic like this is perfect bait for a lot of the resentments folks have with the modern internet ecosystem.
There’s some rarely used tech that few have talked about in a long time. Tech giants have decided somewhat unilaterally to get rid of it because it’s barely used and has had security flaws.
There’s a discussion to be had about that specifically but most people didn’t care a jot about XSLT until it was threatened. What they do care about is tech giants controlling the fate of the internet. That’s a far bigger issue than can be solved in a GitHub discussion, but it doesn’t stop anyone trying.
There is a related issue to instead add XSLT 3 support [1]
[1] https://github.com/whatwg/html/issues/11578
Suggestion, replace this:
With this:Perfectly illustrating one of XML's stupidest flaws.
I don't know if this is intentionally hilarious or unintentionally hilarious, I guess it's the same result either way.
I wonder why everybody want's to use XSLT on the client side. On te Server side it is so powerful and works like a charme with PHP: // XML $xml_doc = new DOMDocument(); $xml_doc->load("file1.xml");
// XSL $xsl_doc = new DOMDocument(); $xsl_doc->load("file.xsl");
// Proc $proc = new XSLTProcessor(); $proc->importStylesheet($xsl_doc); $newdom = $proc->transformToDoc($xml_doc);
// Output print $newdom->saveXML();
> I wonder why everybody want's to use XSLT on the client side
Because if you can remove any server processing, it's just the perfect solution for simple websites.
Lighthouse score 0 .. I wonder what are implications on SEO.
Probably abysmal
Since xslt is built dynamically in the DOM most crawlers don’t build the site and pick up the metadata.
Although I’m not convinced chasing SEO is a useful endeavor any more https://housefresh.com/beware-of-the-google-ai-salesman/
I wonder if AI crawlers would have the same problem and pass over the site
As long as the LLM crawler fetches the XML in the first place I assume it would be fine. Lighthouse is trying to score the rendered HTML, the LLM just needs to understand what's in the document and it can parse the XML directly.
Just do Server-Side rendering then.
Or just end user experience...
It's good to see more real-world applications of XSLT in browsers. There were some other excellent examples before the current discussion about removing XSLT support from browsers. Here is an easy one to get started with: https://xsl-website.widloski.com/
Why use HTML specifically? Markdown generator/transformer based frameworks can usually transform markdown into every commonly used html tag and for the tags that it can’t, you can just write html in the markdown file, just seems like you’re adding a ton of extra cruft imo.
Nice! I always wanted to build an XSLT that parses Markdown and outputs HTML, but was lacking the time. That would elevate your blog framework to a wider audience.
Nice.
The newer XSLT bits interest me.
Its tempting to do something like this but lean on something that provides it like SaxonJS.
I'm pretty curious to see how far I could get making an SVG editor based on that.
I guess I just don't get the point. In order for the page to load it needed to make four round trips on the server sequentially which ended up loading slower than my bloated javascript spa framework blog on a throttled connection. I don't really see how this is preferential to html, especially when there is a wealth of tools for building static blogs. Is it the no-build aspect of it?
It did make all those requests, but only because the author set up caching incorrectly. If the cache headers were to be corrected, site.xsl, pages.xml, and posts.xml would only need to be downloaded once.
The cache headers are correct, you can't indefinitely cache those because they might change. Maybe you could get away with a short cache time but you can't cache them indefinitely like you can a javascript bundle.
Not to mention on a more involved site, each page will probably include a variety of components. You could end up with deeper nesting than just 4, and each page could reveal unique components further increasing load times.
I don't see much future in an architecture that inherently waterfalls in the worst way.
There are cache times other than 0 and infinity. Ideally the XSLT would change rarely, as would things like nav menus. So "relatively short" could mean several minutes to an hour. And with ETags the resource could be revalidated before expiry and never have to be re-downloaded.
ETags still require a round trip. You could cache for longer but now you have to deal with the complexities and struggles of caching.
With HTTP/2 multiplexing all of those requests can be made in a batch without round trips. And complexity of caching? An Etag done right is content-based. There's no logic to worry about.
It's really unfortunate that this style of architecture lost the battle. It's elegant. Data cleanly separated from presentation, small digestible entities, and it all kind of makes sense. But what killed it was the verbosity of XML, as well as its extreme pedantry that results in lack of robustness where a single error would kill the entire transform. Also transformation-based systems notoriously lack proper tools for debugging early on. Lastly, typically buggy implementations of pipelining in HTTP/1.1 made it so that you actually had to make those round trips. But conceptually we had all the pieces to make it work well back in the early 2000s.
Hm - how would multiplexing help here? Does the browser read ahead and process cached assets to find dependencies before firing off etag requests in a batch? I'd be surprised if that was the case.
The appeal of XML is semantic. I think about things in a certain way. I write the text the way I think, inventing XML elements and structure as I go. Then I transform it into whatever. This obscures the semantic, but the transformation is transient, merely to present this to the user.
To do this dynamically I serve the content as I wrote it with a single processing instruction that refers to a stylesheet. This is elegant, isn't it? It is less efficient than a static site, but not that different from a typical HTML: HTML, CSS, JS. It is also trivial to change it to build statically (or to embed all the resources and XSLT into individual XML files, although this would be strange.)
And if browsers supported alternative stylesheets it would be trivial to provide alternative renderings at the cost of one processing instruction per rendering. Why don't they? Isn't this puzzling? I think it is even in the specification.
I get it, but if we're building things for others to use the elegance of our solutions doesn't matter. What matters is things like the efficiency, the experience of using it, not writing it. And I think browsers should serve the end user, not the developer. If we sacrifice some elegance for security that seems like a win for the user. Even if we lose some of the elegance of the abstraction, that's not what it's about.
Of course everyone is free to create things they want with their own abstractions, but let's not pretend that it's an optimal solution. Elegance and optimal are often at odds.
I got my file extensions mixed up, thought this was going to be a "Use M$ Excel as an IDE" type post.
Disclaimer: it's possible XSLT got better over time, although I doubt it.
I actually wrote a whole app that used XSLT back 25 years ago, even backed by an XML database! Super hip (tech stack wasn't my choice).
XSLT is bad tech and you shouldn't use it. The modern equivalent is React+JSON which implements many of the same ideas in a much better way. And I say that as someone who isn't a big React fan but who has used both. It's not a coincidence that this example is for a 1999-era static blog; it's about the limit of what you can do with this tech.
The core idea of XSLT is to provide a functional transform from an app-specific model to a view, where both are expressed in XML. It does that by asking you to supply templates that match patterns in the original data structure. This idea has some deep flaws:
1. The syntax and generic data model used to express your app's own model has to be XML, but XML is descended from a line of technologies intended to express views. XML-based languages are a competent enough way to express a view which is why React invented JSX, but they are less natural for expressing data structures. Modern apps use JSON for expressing data structures which is also far from ideal but it's still an improvement over XML.
2. Transforms from data to view can be arbitrarily complex. React uses a regular imperative programming language with some additional rules to make it "functional-ish", XSLT gives you XPath and what is basically an XML syntax for something a bit like Haskell. Expressing complex transforms is very awkward in this language. Something as simple as a for loop over a list - very easy in JS - requires you to think in pure functional terms in XSLT.
3. Modularity? Debugging? Nope. It's Web Tech, what do you expect? If you make a syntax error you might get a parse error if you're lucky, if you make a logic error you get to sit down with a pen and paper to work out what might be going wrong. Because it's a functional transform rather than a programming language there isn't even really printf style logging. And IIRC there's no such thing as XSLT libraries.
4. There is no solution for interactivity. Mutating the model might yield retransformation depending on implementation (I don't know for modern browsers, I think I mostly tested on IE6 back in the day). If it does, it'll be a retransform of the entire document that blows away any changes to the DOM. But if you want actual app-level state in UI components that efficiently re-render, then you're just out of luck, you have to mutate the generated HTML DOM directly as if XSLT didn't exist at all.
5. There is no functioning protocol for controlling server-side rendering or not (in practice most XSLT based apps give up on browser rendering pretty quickly). Soooooo the original motivation of exposing the app's data structures directly allowing machine-readable access to data, does not actually apply in practice, because there's no systematic way to ask the server to give you the raw XML. Sure a tiny number of servers might actually serve you something different if you use an Accept header with text/xml up front, but even when XSLT was hip apps that did that in the wild were unicorn poop. People claimed they saw one once, but I never actually tracked down a real server that did it.
This blog demo could have been implemented using Preact and the results would be better. The view logic would be much easier to read and write. The underlying data would be a JSON file, or perhaps a combination of JSON and Markdown, i.e. syntaxes designed for the convenient expression of data and marked up text. The browser would still take care of rendering, and the server could easily do the render work up front to make things snappy by avoiding extra roundtrips. The advantage would be that debugging, modularity and retransformation for interactivity all work well.
Agreed, having worked with a few people who thought xslt is the bee knees it's just not very good at all for this type of thing. In fact I'd say it's not very good at anything really.
My thoughts:
1) It's fragile. As xml is so dynamic small changes in the data can mean your transform doesn't work or worse that it does run but doesn't transform to the correct thing anymore
2) Hard to actually make xslt work. Like there are no decent debugging tools the best you'll get is a site you can plug in data and it will auto run the transformation. The devex here is really really poor which is why I'm baffled anyone would build this. As you say it's a transform language so you can't really step through it you just have to run it and see
3) Very hard to test properly. The amount of times something small would change in the data and then the transforms wouldn't work was awful. The "unit testing" we done was produce a bunch of XML and then run the transforms and check the XML. Like I couldn't actually test parts of the transform as I was going
4) Most importantly was maintenance. XSLT seemed to be a write only language as in hardly anyone as able to pickup someone elses transform and figure it out.
The people who liked it normally only used it for toy applications.
Yeah it seems a bit nuts to me. Zero type safety, zero debugging story, no libraries, unusual syntax, it's not expressive like Javascript or other "real" programming languages, no interactivity, bad performance...I just don't get why people love it.