←back to thread

Show HN: I Built a XSLT Blog Framework

(vgr.land)
116 points vgr-land | 5 comments | 24 Aug 25 17:38 UTC | HN request time: 0.002s | source

A few weeks ago a friend sent me grug-brain XSLT (1) which inspired me to redo my personal blog in XSLT.

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

1. chrismorgan ◴[25 Aug 25 04:21 UTC] No.45010171[source]▶
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).

replies(2): >>45010523 #>>45015241 #
2. vgr-land ◴[25 Aug 25 05:29 UTC] No.45010523[source]▶
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.

replies(1): >>45010585 #
3. chrismorgan ◴[25 Aug 25 05:41 UTC] No.45010585[source]▶
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.

4. cxr ◴[25 Aug 25 15:57 UTC] No.45015241[source]▶
> 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?

replies(1): >>45021730 #
5. chrismorgan ◴[26 Aug 25 02:45 UTC] No.45021730[source]▶
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…