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).

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).

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.

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.

Haven't seen this much interest in XML/XSLT in 20 years.

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".

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();

Suggestion, replace this:

    <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>

Lighthouse score 0 .. I wonder what are implications on SEO.

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?

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.