XSLT is such an underused technology. It’s a bit like Makefiles, the syntax is alright but quirky and inelegant in non-trivial cases, but it’s surprising how far you can go with it.
(not so) funny is how frontend people back then complained how XML/XSLT is complex and spread hate against these technologies… and later they developed their monstrous ever-changing frontend toolkits, transpilers, frameworks etc. and made almost everything dependent on Chrome (a 20+ million lines-of-code cute piece of software that – wait for it – includes the XML parser and XSLT processor, just as Firefox does).
I can’t say I have much experience with modern “front-end” development, but XHTML/XSLT seriously sucked ergonomically. Misplace one single character in your markup and conforming browsers would display an error message. And the declarative nature of XSLT, while similar in concept to CSS, is not intuitive for most developers (viz. the widespread griping about SQL.)
It’s true that if you generated all your markup programmatically a lot of these problems were mitigated, but from memory tools to do that were few and far between.
XSLT is such an underused technology. It’s a bit like Makefiles, the syntax is alright but quirky and inelegant in non-trivial cases, but it’s surprising how far you can go with it.
Indeed, some years ago Gentoo Linux used XML/XSLT to build their entire website, which was very modern and exciting at the time - https://www.funtoo.org/The_Gentoo.org_Redesign,_Part_4
(not so) funny is how frontend people back then complained how XML/XSLT is complex and spread hate against these technologies… and later they developed their monstrous ever-changing frontend toolkits, transpilers, frameworks etc. and made almost everything dependent on Chrome (a 20+ million lines-of-code cute piece of software that – wait for it – includes the XML parser and XSLT processor, just as Firefox does).
I can’t say I have much experience with modern “front-end” development, but XHTML/XSLT seriously sucked ergonomically. Misplace one single character in your markup and conforming browsers would display an error message. And the declarative nature of XSLT, while similar in concept to CSS, is not intuitive for most developers (viz. the widespread griping about SQL.)
It’s true that if you generated all your markup programmatically a lot of these problems were mitigated, but from memory tools to do that were few and far between.
I’d say most developers nowadays would prefer https://gerikson.com/m/feed.json to https://gerikson.com/m/feed.atom, even though the former has no provision for styling, and the latter theoretically does.
Everything about xslt is fine and cool until you have deal with an implementation of xslt :D
I use a little selector trickery (really just the
|operator) to style both my RSS and my Atom feed with the same XSLT: https://github.com/jordemort/jordemort.github.io/blob/main/public/feed.xsl