Blame Apple and Mozilla, too, then. They all agreed to remove it.

They all agreed because XSLT is extremely unpopular and worse than JS in every way. Performance/bloat? Worse. Security? MUCH worse. Language design? Unimaginably worse.

EDIT: I wrote thousands of lines of XSLT circa 2005. I'm grateful that I'll never do that again.

▲

stickfigure 21 hours ago | parent | next [-]

This is only repeated by people who have never used it.

XSLT is still a great way of easily transforming xml-like documents. It's orders of magnitude more concise than transforming using Javascript or other general programming languages. And people are actively re-inventing XSLT for JSON (see `jq`).

▲

garethrowlands 19 hours ago | parent | next [-]

I used to use XSLT a lot, though it was a while ago.

You can use Javascript to get the same effect and, indeed, write your transforms in much the same style as XSLT. Javascript has xpath (still). You have a choice of template language but JSX is common and convenient. A function for applying XSLT-style matching rules for an XSLT push style of transform is only a few lines of code.

Do you have a particular example where you think Javascript might be more verbose than XSLT?

▲

imtringued 3 hours ago | parent | prev | next [-]

Who is transforming XML documents on the web? Most people produce HTML to begin with, so XSLT is a solution seeking a problem. If you really insist, you could just use XSLT via server side rendering.

▲

mschuster91 21 hours ago | parent | prev [-]

I actually do have to work with raw XML and XSLTs every once in a while for a java-based CMS and holy hell, it's nasty.

Java in general... Maven, trying to implement extremely simple things in Gradle (e.g. only execute a specific Thing as part of the pipeline when certain conditions are met) is an utter headache to do in the pom.xml because XML is not a programming language!

▲

stickfigure 19 hours ago | parent [-]

It is an unfortunate fact about our industry that all build tools suck. Tell me what your favorite build tool is and I can point at hundreds of HN threads ripping it to shreds. Maybe it's NPM? Cue the screams...

I agree though, "XML is not a programming language" and attempts to use it that way have produced poor results. You should have seen the `ant` era! But this is broader than XML - look at pretty much every popular CI system for "YAML is not a programming language".

That doesn't mean that XML isn't useful. Just not as a programming language.

▲

dfabulich 19 hours ago | parent | next [-]

But, that's what XSL is! XSL is a Turing-complete programming language in XML for processing XML documents. Being in XML is a big part of what makes XSL so awful to write.

▲

stickfigure 18 hours ago | parent [-]

XSL may be Turing-complete but it's not a programming language and wasn't intended to be one. It's a declarative way to transform XML. When used as such I never found it awful to write... it's certainly much easier than doing the equivalent in general purpose programming languages.

Maybe by analogy: There are type systems that are Turing complete. People sometimes abuse them to humorous effect to write whole programs (famously, C++ templates). That doesn't mean that type systems are bad.

	▲	dfabulich 12 hours ago \| parent [-]
		XSL is a functional programming language, not a declarative language. When you xsl:apply-template, you're calling a function. Functional programming languages can often feel declarative. When XSL is doing trivial, functional transformations, when you keep your hands off of xsl:for-each, XSL feels declarative, and doesn't feel that bad. The problem is: no clean API is perfectly shaped for UI, so you always wind up having to do arbitrary, non-trivial transformations with tricky uses of for-each to make the output HTML satisfy user requirements. XSL's "escape hatch" is to allow arbitrary Turing-complete transformations. This was always intended to exist, to make easy transformations easy and hard transformations possible. You basically never need to write Turing-complete code in a type system, but in any meaningful XSL project you will absolutely need to write Turing-complete XSL. XSL's escape hatch is always needed, but it's absolutely terrible, especially compared to JS, especially compared to modern frameworks. This is why JS remained popular, but XSL dwindled.

▲

DonHopkins 17 hours ago | parent | prev | next [-]

"Java is a big DSL to transform XML into stacktraces"

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

XSLT (or ANT) may be Turing complete, but it's firmly embedded in the Turing Tarpit.

https://en.wikipedia.org/wiki/Turing_tarpit

>"54. Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy." -Alan Perlis

▲

mschuster91 19 hours ago | parent | prev [-]

> It is an unfortunate fact about our industry that all build tools suck. Tell me what your favorite build tool is and I can point at hundreds of HN threads ripping it to shreds. Maybe it's NPM? Cue the screams...

npm isn't even a build tool, it's a package manager and at that it's actually gotten quite decent - the fact that the JS ecosystem at large doesn't give a fuck about respecting semantic versioning or keeps reinventing the wheel or that NodeJS / JavaScript itself lacks a decent standard library aren't faults of npm ;)

Maven and Gradle in contrast are one-stop-shops, both build orchestrators and dependency managers. As for ant, oh hell yes I'm aware of that. The most horrid build system I encountered in my decade worth of tenure as "the guy who can figure out pretty much any nuclear submarine project (aka, only surfaces every few years after everyone working on it departed)" involved Gradle, which then orchestrated Maven and Ant, oh and the project was built on a Jenkins that was half DSL, half clicked together in the web UI, and the runner that executed the builds was a manually set up, "organically grown" server. That one was a holy damn mess to understand, unwind, clean up and migrate to Gitlab.

> look at pretty much every popular CI system for "YAML is not a programming language".

Oh yes... I only had the misfortune of having to code for Github Actions once in my life time, it's utter fucking madness compared to GitLab.

▲

dfox 21 hours ago | parent | prev | next [-]

> Security? MUCH worse.

Comparing single-purpose declarative language that is not even really turing-complete with all the ugly hacks needed to make DOM/JS reasonably secure does not make any sense.

Exactly what you can abuse in XSLT (without non-standard extensions) in order to do anything security relevant? (DoS by infinite recursion or memory exhaustion does not count, you can do the same in JS...)

	▲	dfabulich 18 hours ago \| parent \| next [-]
		If you would RTFA, they're removing XSLT specifically for security reasons. They provide the following links: https://www.offensivecon.org/speakers/2025/ivan-fratric.html > Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs. https://nvd.nist.gov/vuln/detail/CVE-2025-7425 https://nvd.nist.gov/vuln/detail/CVE-2022-22834 (And, for the record, XSL is Turing-complete. It has xsl:variable, xsl:if, xsl:for-each, and xsl:apply-template function calls.)
	▲	exasperaited 19 hours ago \| parent \| prev [-]
		Are the security concerns not about libxslt, rather than XSLT?

▲

silon42 21 hours ago | parent | prev | next [-]

How is it worse than JS? It's a different thing...

▲

cxr 21 hours ago | parent | prev | next [-]

> They all agreed to remove it.

All those people suck, too.

Were you counting on a different response?

> XSLT is extremely unpopular and worse than JS in every way

This isn't a quorum of folks torpedoing a proposed standard. This is a decades-old stable spec and an established part of the Web platform, and welching on their end of the deal will break things, contra "Don't break the Web".

▲

shadowgovt 20 hours ago | parent [-]

You can continue to use XSLT server-side to emit HTML if you are deeply, deeply concerned about the technology.

▲

cxr 15 hours ago | parent [-]

Do you still beat your wife? <https://en.wikipedia.org/wiki/Do_you_still_beat_your_wife?>

▲

shadowgovt 15 hours ago | parent [-]

I don't think that applies here (especially since I didn't even ask a question).

"I'm sad it's going away in the client!"

"So move it to the server, and the end-user will get essentially the same experience."

Am I missing something here?

▲

cxr 13 hours ago | parent [-]

> especially since I didn't even ask a question

Oh, that's the operative part? Accept my apologies. What I meant to say is, "I can see that you're deeply, deeply concerned about being able to continue beating your wife. I think you should reconsider your position on this matter."

No question mark, see? So I should be good now.

> Am I missing something here?

Probably not. People who engage in the sort of underhandedness linked to above generally don't do it without knowing that they're doing it. They're not missing anything. It's deliberate.

So, too, I would guess, is the case with you—particularly since your current reply is now employing another familiar underhanded rhetorical move. Familiar because I already called it out within the same comment section:

> The problem is that there is content that works today that will break after the Chrome team follows through on their announced plans of shirking on their responsibility to not break the Web. That's what the problem is. Any "solution" that involves people having to go around un-breaking things that the web browser broke is not a solution to the problem that the Chrome team's actions call for people to go around un-breaking things that the web browser broke.

<https://news.ycombinator.com/item?id=45824392>

	▲	shadowgovt 11 hours ago \| parent [-]
		I seem to have personally offended you, and for that I am sorry. This seems personal to you so I'll bow out of further discourse on the subject as it is not particularly personal to me. The websites I maintain use a framework to build RSS output, and the framework will be modified to do server-side translation or polyfill as needed to provide a proper HTML display experience for end-users who want that.

▲

righthand 21 hours ago | parent | prev [-]

They did not agree to remove it. This is a spun lie from the public posts I can see. They agreed to explore removing it but preferred to keep it for good reasons.

Only Google is pushing forward and twisting that message.

▲

JimDabell 20 hours ago | parent [-]

> They did not agree to remove it. This is a spun lie from the public posts I can see. They agreed to explore removing it but preferred to keep it for good reasons.

Mozilla:

> Our position is that it would be good for the long-term health of the web platform and good for user security to remove XSLT, and we support Chromium's effort to find out if it would be web compatible to remove support.

— https://github.com/mozilla/standards-positions/issues/1287#i...

WebKit:

> WebKit is cautiously supportive. We'd probably wait for one implementation to fully remove support, though if there's a known list of origins that participate in a reverse origin trial we could perhaps participate sooner.

— https://github.com/whatwg/html/issues/11523#issuecomment-314...

Describing either of those as “they preferred to keep it” is blatantly untrue.

▲

righthand 16 hours ago | parent [-]

So you’re choosing to help them spin the lie by cherry picking comments.

The Mozilla comment itself ends with:

> If it turns out that it's not possible to remove support, then we think browsers should make an effort to improve the fundamental security properties of XSLT even at the cost of performance.

> If it turns out not to be possible to remove the feature, we’d like to replace our current implementation. The main requirements would be compatibility with existing web content, addressing memory safety security issues, and not regressing performance on non-XSLT content. We’ve seen some interest in sandboxing libxslt, and if something with that shape satisfied our normal production requirements we would ship it.

But the only way it’s possible to remove the feature is if you ignore everyone asking you to please not to remove it.

Therefor by totally ignoring push back you can then twist Mozilla reps words to mean the only option is to remove it.

Similarly with the Webkit comment:

> WebKit is cautiously supportive.

Both these orgs requested investigation not removal. Both expressed some concern and caution. Google did not, they only ever pushed forward with removing it. Even goong so far as to ignore the followup request to implement XSLT 3.0.

No it’s not blatantly untrue. It’s unblatantly misleading.

Furthermore I’d say for those specific comments, “go ahead and remove it”, the inverse is blatantly untrue.

	▲	JimDabell 8 hours ago \| parent [-]
		If somebody says “our position is A but if that’s not possible we should do B”, it means they prefer A. It doesn’t mean they prefer B, and telling people that they prefer B when you know otherwise is dishonest.