I have yet to read an article complaining about XSLT deprecation from someone who can explain why they actually used it and why it’s important to them.

> I will keep using XSLT, and in fact will look for new opportunities to rely on it.

This is the closest I’ve seen, but it’s not an explanation of why it was important before the deprecation. It’s a declaration that they’re using it as an act of rebellion.

My guess is that a lot of the controversy is simply because this is one of the first times that a major web feature has been removed from the web standards. For the past 20+ years, people have grown to expect that any page they make will remain viewable indefinitely. It doesn't matter that most people don't like XSLT, or that barely any sites use it. Removing XSLT does break some websites and that violates their expectation, so they get mad at it reflexively.

As someone who's interested in sustainable open source development, I also find the circumstances around the deprecation to be interesting and worth talking about. The XSLT implementation used by all the browsers is a 25 year old C library whose maintainer recently resigned due to having to constantly deal with security bugs reported by large companies who don't provide any financial contribution or meaningful assistance to the project. It seems like the browser vendors were fine with the status quo of having XSLT support as long as they didn't have to contribute any resources to it. As soon as that free maintenance went away and they were faced with either paying someone to continue maintenance or writing a new XSLT library in a safer language, they weren't willing to pay the market value for what it would cost to do this and decided to drop the feature instead.

What a horrible technology to wrap around your neck for rebellion's sake. XSLT didn't succeed because it's fundamentally terrible and was a bad idea from the very beginning.

But I suppose forcing one's self to use XSLT just to spite Google would constitute its own punishment.

Yeah, the idea that it's some kind of foundation of the "open web" is quite silly.

I've used XSLT plenty for transforming XML data for enterprises but that's all backend stuff.

Until this whole kerfuffle I never knew there was support for it in the browser in the first place. Nor, it seems, did most people.

If there's some enterprise software that uses it to transform some XML that an API produces into something else client-side, relying on a polyfill seems perfectly reasonable. Or just move that data transformation to the back-end.

I used it. It's an (ugly) functional programming language that can transform one XML into another - think of it as Lisp for XML processing but even less readable.

It can work great when you have XML you want to present nicely in a browser by transforming it into XHTML while still serving the browser the original XML. One use I had was to show the contents of RSS/Atom feeds as a nice page in a browser.

Making RSS/Atom feeds friendly to new users is key for its adoption, and for the open web. XSLT is the best way to do that.

I made a website to promote doing using XSLT for RSS/Atom feeds. Look at the before/after screenshots: which one will scare off a non-techie user?

https://www.rss.style/

All browsers ever implemented was XSLT 1.0, from 1999. There were 2.0 and 3.0 for which there is an open source Java based implementation (Saxon) but this never made it into libxslt and/or browsers!

> I have yet to read an article complaining about XSLT deprecation from someone who can explain why they actually used it and why it’s important to them.

I used it to develop a website because I'm not a programmer, but I still want to have some basic templates on my webpage without having to set up a dev environment or a static site generator. XML and XSLT extend HTML _just enough_ to let me do some fun things without me having to become a full-on programmer.

Imagine you have users that want to view an XML document as a report of some kind. You can easily do this right now by having them upload a document and attaching a stylesheet to it. I do this to let people view after-game reports for a video game (Nebulous: Fleet Command). They come in as XML and I transform them to HTML. Now I do this all client-side using the browser support for XSLT and about 10 lines of javascript because I don't want to pay for and run a server for file uploads. But if I did the XSLT support in the browser would make it truly trivial to do.

Now this obviously isn't critical infrastructure, but it sucks getting stepped on and I'm getting stepped on by the removal of XSLT.

I use XSLT because I want my website to work for users with JavaScript disabled and I want to present my Atom feed link as an HTML document on a statically hosted site without breaking standards compliance. Hope this helps.

If you have a lot of xml data and need an UI that does complex operations that scream xpath it would be rather spectacular if it could be done without much of a back end, in the browser without js.

I'm not good enough with XSLT to know if it is worth creating the problem that fits the solution.