Rather than just build my own blog on it, I wrote it up for others to use and I've published it on GitHub https://github.com/vgr-land/vgr-xslt-blog-framework (2)
Since others have XSLT on the mind, now seems just as good of a time as any to share it with the world. Evidlo@ did a fine job explaining the "how" xslt works (3)
The short version on how to publish using this framework is:
1. Create a new post in HTML wrapped in the XML headers and footers the framework expects.
2. Tag the post so that its unique and the framework can find it on build
3. Add the post to the posts.xml file
And that's it. No build system to update menus, no RSS file to update (posts.xml is the rss file). As a reusable framework, there are likely bugs lurking in CSS, but otherwise I'm finding it perfectly usable for my needs.
Finally, it'd be a shame if XSLT is removed from the HTML spec (4), I've found it quite eloquent in its simplicity.
(1) https://news.ycombinator.com/item?id=44393817
(2) https://github.com/vgr-land/vgr-xslt-blog-framework
(3) https://news.ycombinator.com/item?id=44988271
(4) https://news.ycombinator.com/item?id=44952185
(Aside - First time caller long time listener to hn, thanks!)
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.
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).
Is there something (besides (lack of) client support) that makes RSS better suited for podcasting?
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…
A quick glance at Atom though says to me its worth an attempt to refactor.
(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.
Well yeah I hope not! That's what a programming language is for, to turn data into documents.
> 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.
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.
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...
[1]: https://github.com/whatwg/html/issues/11523#issuecomment-318...
//Edit: Rephrased "PRs" to "Discussions".
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.
// 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();
Because if you can remove any server processing, it's just the perfect solution for simple websites.
<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>
<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>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
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.
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.
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.
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 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.
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.