← Back to context

Comment by JimDabell

8 days ago

Some recent discussion on XSLT here:

XSLT – Native, zero-config build system for the Web – 27th June 2025 (328 comments):

https://news.ycombinator.com/item?id=44393817

The only useful thing I have seen it do in the past couple of decades has been to style Atom/RSS feeds. I haven’t personally used it in 25 years. The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for keeping it.

> so it’s hard to make the case for keeping it.

How about “not breaking stuff” which can not be upgraded? Like old sites/services without active maintainers but still useful. Or hardware appliances that still work, but will not get firmware update ever. Let alone rss feeds, brought up multiple times in the linked thread.

Looks like builtin polyfill (similar to pdfjs in FF) would do. But google seems to be reluctant doing it.

  • When’s a reasonable time to pull the plug on out of fashion legacy stuff? Things can’t always remain backwards compatible forever. I think the places this is still in use can build contingencies where required

    • Why can’t things remain backwards compatible forever? In the 35 years that the Web has existed, browsers have come pretty damn close to meeting that standard. The one huge exception is the removal of plugin support around 2015, and the concomitant death of Flash and Java applets. There were also some major browser-specific APIs that got killed off, like ActiveX and NaCl. But when it comes to standardized, browser-native functionality… very little has ever been removed. I would prefer it if I could say the same thing in another 35 years.

      2 replies →

    • Things can remain backwards compatible forever. That is what any good standard does. Web standards and much else in software is sadly a complete mess where too few care about all the downsides of instability.

      I am a bit worried because for many years I used plugins like SinglePage to save web pages as HTML. That is not exactly future-safe since every relase of Chromium or Firefox has a list of things that were deprecated (and a list of things that changed, that might or might not break rendering of old pages). Old saved pages will eventually begin to degrade and some might eventually be unreadable without having to mess with virtual machines to run old browsers.

      6 replies →

  • Lets remind ourselves that thanks to Google we also did not got WebGL 2.0 Compute, it was too much for Chrome team to spend their resources between WebGL 2.0 Compute and WebGPU.

    How great that five years later WebGPU is something we can rely on in portable way. /s

The wikipedia api has an option where you can add an xslt stylesheet to its output.

When i was young and stupid and learning to program i made an xslt stylesheet to extract dictionary definitions from the api.

It was meant to be combined with a bookmarklet that when you double clicked a word opened it in an iframe.

It was terrible, but i was so proud of it at the time.

It seems like it stopped working at some point, i guess browsers are probably more strict with mime types now. https://en.wiktionary.org/w/api.php?action=parse&format=xml&...

Sorry if this is too off topic, it just triggered some memories

  • > It was terrible, but i was so proud of it at the time.

    Terrible why? Bookmarklets and XSLT (and things like Greasemonkey userscripts) were some of the things that made the web more "read-write" in the '00s: anyone could remix web content however they saw fit, optimizing it for their personal use-cases, and often attracted kids and "normies" to coding.

    Even today, they can be used to do stuff that most people find magical. Unfortunately they are unfashionable, so they're slowly getting strangled by the big players who want to have all the control all the time.

    • Sadly i just filed a bug to remove the xslt option from mediawiki's api.

      By terrible i just mean the code was really hacky. I was a newbie and exploring.