Hacker News new | ask | show | jobs
by robert_tweed 1088 days ago
If anyone is looking for a real-world example, the BBC does it:

http://feeds.bbci.co.uk/news/rss.xml

2 comments

The BBC and other examples are present in the article under this heading: https://darekkay.com/blog/rss-styling/#examples
Ah, I only skimmed the article and missed that. The BBC RSS feed was the main example I referred back to while I was learning XSLT around 2010-ish.

AFAIK it's the only major implementation of this technique. Most other big sites that provided an RSS feed didn't bother, and most of those RSS feeds are dead now. The BBC one has hardly changed since those days and it still works really well as a dual-delivery system.

I'm not a frequent XSLT user but I'm aware for example that, for example, you can add any text you want to the presentation of the feed with <xsl:text>. Can you add script, images, and basically end up with something similar to a modern webpage?

You have to wonder. What would the world look like if more publishers had gone the route of styling RSS or Atom feeds, and maybe supported and extended the relevant standards in the places they found those standards to be deficient? Could we have ended up with a world where content delivery was all RSS, the relationship was exclusively between you and the publisher, and we didn't need Meta as the middle-man sucking publisher profits dry while convincing our daughters to kill themselves?

...Nahhhhh, I'm sure that going full neanderthal, RSS LOOK SCARY, clubbing it over the head and removing it from a website is the better approach. /snark

I've never really liked JSON as replacement for XML. Had we continued with RSS, Atom and XML, not only would we make peer to peer distribution far easier, we'd have a very easy publishing mechanism.

But we threw out XML for JSON. With JSON we need loads of custom, client side code to turn it into a DOM that the user can look at. With XML we only need XSLT. It won't work for all cases, but the majority of sites wouldn't need a single line of JS to renders sites. Yet here we are: shadow DOM, event listeners, useeffect, JSX, progressive hydration, and so forth and so on. To build web-experiences that we could deliver back in early 2000 but were deemed too complex and too daunting.

To be fair, many of the things you listed are able to implement features not possible with XSLT.
Not sure if I understand correct, but the things I listed (event listeners, AJAX, etc) are things needed to be implemented so that you get what XML+XSLT in a browser give you for free.

To be clear: there are lots of things that XML+XSLT cannot do, but which JavaScript+HTML can do (in an HTTP context).

But for the most typical HTTP usecase: a website presenting information, XML+XSLT is fully up to the task, yet we forego that, and instead pull out the big, complex "guns", entire JS frameworks. A knee-jerk reaction that I blame on the bad rep XML got, and the praise it's incomplete but simpler replacement, JSON, got.

Good news, you can nowadays transform JSON using XSLT, even in the browser.
JSON is great, but lacks one feature that XML and its ecosystem has - extensibility and deep standarisation. XSLT, XML Schema, XML signing and encryption, native support of ids and refs, etc. All that missing points are doable with JSON or were added quite late, but yeah, standarisation is important.
JSON somehow have standardisation with OpenAPI.

But yeah, JSON is a pain. XML was pretty smart.

> Can you add script, images, and basically end up with something similar to a modern webpage?

Sure, you can use anything you would on a regular HTML page. I was consuming my local news website via their RSS feed in my browser, as it looked like a regular website (but without all the fluff). Unfortunately, they've dropped the custom view completely, and it's now back to raw XML content :(