Direction of travel seems to be JavaScript for all of this sort of thing

Posted Aug 27, 2025 19:39 UTC (Wed) by farnz (subscriber, #17727)
Parent article: The tangled web of XSLT browser support

It looks to me like the direction of travel is JavaScript for all conversions of input data to renderable HTML; there appear to be pure JavaScript XSLT implementations, and thus this ends up being like PDF.js, just another way to convert from a non-HTML source to something the browser can render, using JavaScript to do all the hard work.

You end up with a "web platform" that's HTML5 + CSS + JavaScript, where the JavaScript does the heavy lifting client side to take interesting inputs (as XML, JSON, or something else) and provide something the web platform can render.

Direction of travel seems to be JavaScript for all of this sort of thing

Posted Aug 27, 2025 20:45 UTC (Wed) by iq-0 (subscriber, #36655) [Link] (6 responses)

Eventhough I despise "code as an alternative to mark-up" in general. I think this is a good use case for these kinds of semi-legacy formats. The in-browser implementation suck and are not consistent across vendors. The javascript (which is generic enough to execute properly on all browsers) brings us to a level playing field, thus creating an evironment for generally available incremental improvement.

If XSLT (especially newer versions) turn out to be popular it will start benefiting from optimized browser support. Should it turn out to be a dud then at least all browsers are able to represent all the documents and format that assumed it would be a success, keeping the open web access alive.

Separating data and mark-up - JavaScript versus XSLT

Posted Aug 28, 2025 8:43 UTC (Thu) by farnz (subscriber, #17727) [Link] (5 responses)

I, in general, don't really care how you convert the raw data to something pretty for the user to view. JavaScript and XSLT both work for me here, with JavaScript having more flexibility.

The thing that I do want to see more of, and that XSLT was supposed to usher in (but didn't, for a variety of reasons) is a world where the data is separate to presentation. If that's data supplied as XML and transformed into a presentation form by XSLT, great. If it's supplied as JSON, or XML, or CBOR, and transformed into a presentation form by JavaScript code, that's also great.

Key for me, though, is that the data is supplied separately, and that I can, as a hacker type, use the presentation renderer to reverse-engineer the data format and reuse the data in ways the originator did not think of. It's also a nice side-benefit if the presentation layer (whether XSLT, or JavaScript) is highly cacheable, so that the data is small; I'd prefer to get the data in a single TCP packet each time it updates, rather than downloading 200 KiB of "echo" formatted HTML (or 200 KiB of XML for 100 bytes of new data, for that matter).

Separating data and mark-up - JavaScript versus XSLT

Posted Aug 28, 2025 16:25 UTC (Thu) by wahern (subscriber, #37304) [Link] (4 responses)

Compare the podcast ecosystem to the YouTube and Instagram ecosystem. In which ecosystem is the presentation layer tightly integrated with the media data delivery layer? Which ecosystem has standardized and *reliable* metadata and data formats? Which ecosystem has a plethora of both web and native apps that can access content across multiple (or even indefinite) number of media hosts? Which ecosystem are you more likely to even be able to access the raw media without the presentation layer acting as a kind of DRM? Which ecosystem has become more monopolized and centralized by big players?

Now ask yourself, why is that? What's better technologically for a single outlet is not necessarily better for the health of the broader ecosystem. Technology shapes and channels how players interact. Once upon a time the FOSS world, or at least part of it, understood that. But we've all become utterly inured to centralization and walled gardens that few can even remember the previous era, of which RSS is a vestige. There's an alternative universe where Spotify is the singularly dominate player in podcasting, similar to YouTube and Instagram for video. Would that be a better universe?

Separating data and mark-up - JavaScript versus XSLT

Posted Aug 28, 2025 16:50 UTC (Thu) by farnz (subscriber, #17727) [Link] (3 responses)

I don't think any of that is particularly related to XSLT, however. One of the reasons XSLT is so lightly used is that nobody bothered with it back in the day; even now, it's common for RSS feeds to not also have an associated XSLT transform to give you a nice web page if you open the RSS feed directly.

Rather, it's about money. Video and photo sharing centralised because, at the time, bandwidth prices were high compared to the sizes of files; the YouTube and Instagram gambles, (which paid off) were that if you could grow fast enough, you could get enough investment to allow you to stay ahead of the cost curve, up until bandwidth became cheap enough that they could cover their costs from their income.

Had the typical home user had an unlimited usage 100M symmetric connection back in 2004, with 10G being cheap in datacentres, we might well not have seen the centralisation we say, because it would have been cheap to host your video yourself, and therefore extending the podcast ecosystem to a videocast ecosystem would have been something people did.

Separating data and mark-up - JavaScript versus XSLT

Posted Aug 28, 2025 18:22 UTC (Thu) by wahern (subscriber, #37304) [Link] (2 responses)

I don't think XSLT is the reason the podcast ecosystem was successful. There were and are alot of dynamics at play. But I appreciate the argument that XSLT has helped it survive in the face of all the pressures it now faces, particularly from commercialization; i.e. that it helps to (indirectly) preserve sufficient diversity to stave off catastrophic centralization. I doubt XSLT is even the most important factor today, but perhaps it's important enough that in its absence the ecosystem will collapse, it's loss being the veritable straw breaking the camel's back. Dropping XSLT could introduce just enough friction among users that usage patterns and expectations (of listeners, producers, hosters, aggregators, etc) shift in a way that allows the market to be terminally captured.

Also, I'm admittedly biased because I really do like XSLT. I dislike XML, and dislike XSLT's XML syntax, but in terms of functionality and longevity, even prospectively (alternatives aplenty, but always ephemeral), there's nothing else like it. Saying that browsers don't need XSLT because we have JavaScript is like saying browsers don't need WebRTC or PushAPI because we have JavaScript, WASM, and HTTP 1.1. Sure, but that's beside the point. Even though XML is seemingly in its golden years, I wouldn't be surprised if it's still more ubiquitous in terms of breadth and depth of software support and data encapsulated than JSON. All the world isn't a Rest API. And manipulating XML is much nicer using XSLT & friends (XPath, XQuery, etc). And despite the WHATWG's best efforts, XML and HTML remain sufficiently alike that it strains credulity to suggest XSLT couldn't or shouldn't be a contender for HTML templating.

The most convincing argument against XSLT for me is the lack of well maintained libraries. So what's clearly necessary, if not sufficient, for XSLT to survive is the FOSS community stepping up to fill the vacuum--libxslt successfully revived (thankfully some people are already taking a stab at that), Saxon opening up more and seeing greater adoption, or some newcomer library/ies. Preferably all of the above.

Separating data and mark-up - JavaScript versus XSLT

Posted Aug 28, 2025 18:33 UTC (Thu) by wahern (subscriber, #37304) [Link]

To be clear, by "Dropping XSLT" I meant "Dropping browser-native XSLT and therefore losing the single URL model of podcast sharing and integration". Because it's not XSLT, per se, that is argued to undergird the ecosystem, but the single URL model. It's like flipping the YouTube model on its head, where a YouTube link functions as both a link to the raw video that can be followed by any HTTP-aware software, but also happens to magically render a convenient (yet host-controllable) UX when opened by a web browser. It's an artifact of the way the latter aspect works that helps to protect the viability and persistence of the former--open-access to the raw media.

Separating data and mark-up - JavaScript versus XSLT

Posted Aug 28, 2025 19:35 UTC (Thu) by excors (subscriber, #95769) [Link]

I suspect the main reason podcasts have avoided centralisation is that listeners are generally split between Spotify, Apple Podcasts, and increasingly nowadays YouTube, with a pretty small fraction from all the other platforms combined. In particular Apple Podcasts could never have become a monopoly, because not everyone has an Apple device, but podcast creators have to support it because a lot of people do have an Apple device.

Following the zero-one-infinity rule, since podcasters have to support more than one platform they'll use a third-party hosting service who know how to publish to all the platforms at once (and how to handle listener stats for all those platforms to attract advertisers, etc), so the minor platforms can still hang on. But I think it's the duopoly of commercial platforms who have allowed the industry to take that shape.

Direction of travel seems to be JavaScript for all of this sort of thing

Posted Aug 27, 2025 22:42 UTC (Wed) by wahern (subscriber, #37304) [Link] (1 responses)

I suspect most people would be happy with a PDF.js-like solution.[1] The point of contention is whether it would be integrated into the browser, like PDF.js is with Mozilla, or whether you have to explicitly bootstrap it by emitting a snippet of HTML and JS to get the ball rolling. The whole debate regarding RSS is about the importance to the open ecosystem of being able to share a single URL, and to do so without requiring any specialized server-side application logic and client detection.

Imagine if browsers couldn't display PDFs, either natively or by reliably being able to pass it off to a local viewer. PDF as a open document format would lose much of its value, and walled gardens would flourish even more. This dynamic is precisely why YouTube makes it extremely difficult, if not impossible, to directly pull a video. Making the content tightly bound to their viewing platform is integral to how they achieved and maintain their dominance. It would appear (at least based on the claims) that RSS, like SMTP, achieved escape velocity before the dominance of walled garden platforms squashed the ecosystem, but that dynamic largely rests on built-in XSLT support.

Direction of travel seems to be JavaScript for all of this sort of thing

Posted Aug 28, 2025 8:32 UTC (Thu) by farnz (subscriber, #17727) [Link]

PDF.js was prototyped outside the browser, and integrated when it was clear that it was useful (to replace PDF plugins, admittedly).

I don't see any strong reason why the same couldn't happen with XSLT; people show cool tech demos outside the browser, using a JavaScript based viewer for their XML format (which is something that most of the usage of XSLT I've seen, bar the trick of making an RSS feed pretty, could do easily - they're currently serving an XML data file and XSLT file to generate a web page, they could serve a HTML5+JavaScript+CSS fileset and an XML data file).

The RSS use would need a bit more server-side assistance to serve the web page to browsers, and the RSS feed to RSS readers, but would at least be something you could prove works well, before asking browsers to integrate xslt.js.