YHK - yet another hacker news clone

Only the XSLT that ships with browsers.

I find this whole removal idea a bit lazy. In theory some logic possibly declares some aspects of the BOM/DOM must be JS for introspection reasons, etc, but the reverse can't really be true.. There's nothing that can declare things like XSLT must be more native than a little trick with a otherwise standard JS VM, so the unique security edges of delegating things to a second class backwards support level could be quite small.

Good LWN coverage from a bit ago, https://lwn.net/Articles/1034560/

It's just an idea & very amorphous, but I dig Dorian Taylor's swet. As an idea of where we could go. wasm but also how it gets used too, what xslt could mean. https://github.com/doriantaylor/swet

Worth repeating again that the browser's never really maintained or supported XSLT at all. That, afaik, it never got past 1.0 era support. Which was bad. But there's a 2.0 (vastly better!), a 3.0, and at the same time the browsers decided not to support xslt, a 4.0.

XSLT is not a straight fit for use, doesn't seem likely to become a mainstream technology. But it's incredibly powerful & very declarative a way to produce, to transform. In that way, it's one of the most RFC 8890 The Internet Is For End Users specifications of all time, one of the only places where we can describe what is fundamentally compute as clear data, without all the opinion and decoration of code, in a clear way. We could build visualizations and explainers of what XSLT is happening, what productions are occuring, that illuminate what the page is doing, that link data in to data out in a traceable, clear, identifiable way. That the arbitrariness of code can compete with, but never so universally, only by creating it's own bespoke particular solutions, where-as XSLT has some universality.

I'm both pretty sad at the situation, but ultimately, I don't think the browser's bad choice & their laziness to help make the right thing possible matters. There's great good here, and their lack of doing the right thing doesn't actually slow things down. The problem is still that we just lack the will of the good, that developers and more so enterprises want to do the big industrial stacks, but that that is totally decoupled from what is good for the web, what is good for the users.

I have good memories of using XSLT. It was a neat idea at the time.

I suppose the world has nearly moved away from XML (for browsers, not yet for folks still enjoying SOAP APIs). And as a result, XSLT has fallen into obscurity.

Aren't browsers implementations of the XSLT and XPATH standards really out of date to start with?

What would be a modern equivalent of a JSON to HTML transformer?

Seems rather absolutist. XSLT was an idea that sounded good, but in practice was quite awkward (like many xml technologies) and never got off the ground. Do we really need to hang every failed experiment around browser vendors' necks forever? I would prefer they work on things people care about.

From one of the issue trackers:

"While it's important to not break existing web content, it's also important to prevent security vulnerabilities. XSLT has been in maintenance mode in browsers and has been an ongoing source of security issues."