I love the little historical overview in the post. With more than 25 years of hindsight, the push against user-centred standards is so obvious. W3C is always better than whatever coolaid-du-jour big corps wants you to drink because (at the very least), someone actually thinks "how is this going to affect people using it" as opposed to Google/Apple's approach "How is this going to affect our revenue".
api · 5m ago
Nobody pays for anything with user centric standards. If software were free to produce and services were free to run this would work, but it doesn’t. Software in particular is incredibly time consuming and expensive, especially if you want to make it usable.
sharpfuryz · 43m ago
The article is about intentional killing XSLT/XML in the browser. I think it is evolutionary: devs switched to JSON, AI agents don't care at all - they can handle anything; XML just lost naturally, like GOPHER
isodev · 33m ago
The problem is not XML vs. JSON. This is not about choosing the format to store a node app's configuration. This is about an entire corpus of standards, protocols that depend on this. The root problem for me is:
1) Google doing whatever they want with matters that affect every single human on the planet.
2) Google running a farse with "public feedback" program where they don't actually listen, or in this case ask for feedback after the fact.
3) Google not being truthful or introspective about the reasons for such a change, especially when standardized alternatives have existed for years.
4) Honestly, so much of standard, interoperable "web tech" has been lost to Chrome's "web atrocities" and IE before that... you'd think we've learned the lesson to "never again" have a dominant browser engine in the hands of a "for profit" corp.
rapnie · 1m ago
Yes, this is the real issue, and it is a pity so many comments delve into json vs. xml and not on the title stating that "google is killing the open web". A new stage of the web is forming where Big Tech AI isn't just chatbots, but matured to offer fully operational end-to-end services. All AI-operated and served, up to tailor-made domain-specific UI. Then the corporations, winners in their market, don't have a need for open web anymore to slurp data from. All open web data absorbed, now fresh human creativity flows in exclusively via these service, directly feeding the AI systems.
mattlondon · 30m ago
+1 I think XML "lost" some time ago. I really doubt anyone would chose to use it for anything new these days.
I think, from my experience at least, that we keep getting these "component reuse" things coming around "oh you can use Company X's schema to validate your XML!" "oh you can use Company X's custom web components in your web site!" etc etc yet it rarely if ever seems to be used. It very very rarely ever feels like components/schemas/etc can be reused outside of their intended original use cases, and if they can they are either so trivially simple it's hardly worth the effort, or they are so verbose and cumbersome and abstracted trying to be all things to all people then it is a real pain to work with. (And for the avoidance of doubt I don't mean things like tailwind et Al here)
I'm not sure who keeps dreaming these things up with this "component reuse" mentality but I assume they are in "enterprise" realms where looking busy and selling consulting is more important than delivering working software that just uses JSON :)
temporallobe · 58s ago
XML might have “lost” but it’s still a format being used by many legacy and de novo projects. Transform libraries are also alive and well, some of them coming with hefty price tags.
NoboruWataya · 17m ago
It may be that nobody would choose XML as the base for their new standard. But there are a ton of existing standards built around XML that are widely used and important today. RSS, GPX, XMPP, XBRL, XSLT, etc. These things aren't being replaced with JSON-based open standards. If they die, we will likely be left without any usable open standards in their respective niches.
weinzierl · 4m ago
"I really doubt anyone would chose to use it for anything new these days."
Funny how went from "use it for everything" (no matter how suitable) to "don't use it for anything new" in just under two decades.
To me XML as a configuration file format never made sense. As a data exchange format it has always been contrived.
For documents, together with XSLT (using the excellent XPath) and the well thought out schema language RelaxNG it still is hard to beat in my opinion.
bayindirh · 24m ago
> I really doubt anyone would chose to use it for anything new these days.
I use it to store complex 3D objects. It works surprisingly well.
MrVandemar · 19m ago
> I really doubt anyone would chose to use it for anything new these days.
Use the correct tool for the job. If that tool is XML, then I use it instead of $ShinyThing.
bayindirh · 25m ago
XML is not a file format only. It's a complete ecosystem built around that file. Protocols, verifiers, file formats built on top of XML.
You can get XML and convert it to everything. I use it to model 3D objects for example, and the model allows for some neat programming tricks while being efficient and more importantly, human readable.
Except being small, JSON is worst of both worlds. A hacky K/V store, at best.
diggan · 23m ago
> XML just lost naturally, like GOPHER
Lost? The format is literally everywhere and a few more places. Hard to say something lost when it's so deeply embedded all over the place. Sure, most developers today reach for JSON by default, but I don't think that means every other format "lost".
Not sure why there is always such a focus on who is the "winner" and who is the "loser", things can co-exists just fine.
sharpfuryz · 16m ago
Do you use it daily in browser?
jeroenhd · 4m ago
Tons of APIs and applications work with XML. XSLT less so; that's more of a backend language.
jon-wood · 16m ago
> AI agents don't care at all
And I don't care at all about the feelings of AI agents. That a tool that's barely existed for 15 minutes doesn't need a feature is irrelevant when talking about whether or not to continue supporting features that have been around for decades.
vidarh · 11m ago
Agreed. Having actually built and deployed an app that could render entirely from XML with XSLT in the browser: I wouldn't do it again.
Conceptually it was beautiful: We had a set of XSL transforms that could generate RSS, Atom, HTML, and a "cleaned up" XML from the same XML generated by our frontend, or you could turn off the 2-3 lines or so of code used to apply the XSL on the server side and get the raw XML, with the XSLT linked so the browser would apply it.
Every URL became an API.
I still like the idea, but hate the thought of using XSLT to do it. Because of how limited it is, we ended up having e.g. multiple representations of dates in the XML because trying to format dates nicely in XSLT for several different uses was an utter nightmare. This was pervasive - there was no realistic prospect of making the XML independent of formatting considerations.
_heimdall · 40m ago
The only reason AI agents don't care about XML is because the developers decided, yet again, to attempt to recreate the benefits of REST on top of JSON.
That's been tried multiple times over the last two decades and it just ends up with a patchwork of conventions and rules defining how to jam a square peg into a round hole.
afavour · 30m ago
Many years ago I tried very hard to go all-in on XML. I loved the idea of serving XML files that contain the data and an XSLT file that defined the HTML templates that would be applied to that XML structure. I still love that idea. But the actual lived experience of developing that way was a nightmare and I gave up.
"Developers keep making this bad choice over and over" is a statement worthy of deeper examination. Why? There's usually a valid reason for it. In this instance JSON + JS framework of the month is simply much easier to work with.
molteanu · 22m ago
"Choice" is a big word here. It would imply "we've weighted the alternatives, the pros and cons, we've tested and measured different strategies and implementations and we came out with this conclusion: [...]." You know, like science and engineering.
While oftentimes what happens is is "oh, this thing seems to be working. And it looks easy. Great! Moving on.."
bilog · 19m ago
Most of the issues of using client-side XSLT is that browsers haven't updated their implementations since v1 nor their tooling to improve debugging. Both of these issues are resolved improving the implementations and tooling, as pointed out by several commenters on the GH issue.
FeepingCreature · 2m ago
That kind of demonstrates why XSLT is a bad idea as well though. JSON has its corner cases, but mostly the standard is done. If you want to manipulate it, you write code to do so.
sharpfuryz · 24m ago
People have been building things differently for the last 10 years, using json/grpc/graphql (that's why replacing complex formats like xml/wsdl/soap with just JSON is a bad idea), so why train(spend money) AI for legacy tech?
myfonj · 27m ago
Coincidentally spotted this source code in some Microsoft Windows Server® 2022 Remote Desktop Web Access thingy yesterday:
Coders have this tendency to value ideology over practicality. What matters is something that works and people use, not a theoretical picture of how it could have worked in an alternative timeline.
isaacremuant · 22m ago
Actually, control means practicality. Linux won the server wars and that was a combination of ideology AND practicality.
If a company breaks something so only their path works it's short term practicality to use it and long term practicality to fight for an alternative that keeps control in the developers hand.
Monopolies are terrible for software developers. Quality and customisation tend to go down, which means less value for the Devs.
pjmlp · 33m ago
It is already ChromeOS Application Platform for quite some time now.
Every Chrome installation or related fork, plus Electron shippments, counts.
Google is a corporation maximizing shareholder value. That this goal is not aligned with serving the greater good and freedom should come as no surprise.
colesantiago · 37m ago
What can we do to stop Google killing the open web other than complaining?
One way is to tell everyone to use Firefox (uBlock origin works there)
It is still an issue that the Mozilla Foundation is still 80% funded by Google though, so this needs to be solved first.
Somehow Firefox needs to be moved away from Mozilla if they cannot find an alternative funding source other than Google.
ozgrakkurt · 14m ago
You can donate to some project like ladybird or servo if they take donations. Or contribute.
pjmlp · 33m ago
Stop using Chrome and Electron, but of course no one will, it was devs that made them what they are today.
andersmurphy · 35m ago
That would have been true pre Mozilla implosion.
ymolodtsov · 35m ago
Firefox is used by 1% of users.
MrVandemar · 16m ago
The top 1% of users :-)
izacus · 26m ago
You need to admit to yourself that maintaining a critical piece of software like a web browser costs a lot in work and finance and start figuring where and how you'll fund people that do more than complain.
Developing software is hard - and OSS hasn't found a way to do hard things yet.
stackedinserter · 28m ago
Google is evil, but man, I never missed XSLT. I'm old enough to remember it and it gives me war flashbacks.
The good thing is that it makes you strong and resilient to pain over time. It's painfully unreadable. It's verbose (ask chatgpt to write a simple if statement). Loops? - here's your foreach and that's all we have. Debugging is for weak, stdout is your debugger.
It's just shit tech, period. I hope devs that write soul harvesting surveillance software at Google go to hell where they are forced to write endless xslt's. Maybe that's the reason they want to remove it from Chrome.
jeroenhd · 7m ago
I don't really get the hatred for XSLT. It's not the most beautiful language, I'll give you that, but it's really not as bad as people make it out to be.
I can't imagine wanting to use anything more complex than a for-each loop in XSLT. You can hack your way into doing different loops but that's like trying to implement do/while in Haskell.
Is it that I've grown too comfortable with thinking in terms of functional programming? Because the worst part of XSLT I can think of is the visual noise of closing brackets.
Devasta · 1h ago
Getting rid of XSLT from the browser would be a mistake, no doubt about it.
You can see it clear as day in the github thread that they weren't asking permission, they were doing it no matter what, all their concerns about security just being the pretext.
It would have been more honest of them to just tell everyone to go fuck themselves.
JimDabell · 14m ago
> their concerns about security just being the pretext.
It seems entirely reasonable to be concerned about XSLT’s effects on security:
> 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.
What do you think their real reason for wanting to remove XSLT is, if not what they claim?
El_Camino_Real · 15m ago
Why side with the megacorps on every thread, even when it doesn't relate to the big hotness of large language models?
jacquesm · 40m ago
To increase the depth of their moat. XSLT would allow anybody with a minimum of effort to extract semantic information from the web.
JimDabell · 12m ago
> XSLT would allow anybody with a minimum of effort to extract semantic information from the web.
XSLT has been around for decades so why are you speaking in hypotheticals, as if it’s an up-and-coming technology that hasn’t been given a fair chance yet? If it hasn’t achieved that by now, it never will.
jon-wood · 18m ago
I feel like this is overly conspiratorial. Likely they want to remove it because it's a pain to support, and used by an ever shrinking proportion of the internet. I don't even necessarily think removing support is a terrible thing, if you want to turn XML into HTML or whatever with XSLT you're still very welcome to do so, you just might have to do it server side rather than expecting every web browser to it for you.
mschuster91 · 14m ago
> a minimum of effort
That is not a combination of words that should be mentioned in the same sentence as the word XML or, even worse, XSLT.
XML has its value in enterprise and reliable application development because the tooling is very old, very mature and very reliable. But it's not something taught in university any more, it's certainly not taught in "coding bootcamps", simply because it's orders of magnitude more complex than JSON to wrap your head around.
Of course, JSON has jsonschema, but in practice most real-world usages of JSON just don't give a flying fuck.
gennarro · 43m ago
Site not loading? Maybe the open web isn’t all it’s cracked up to be? /s
andersmurphy · 37m ago
Loading fine for me.
wltr · 34m ago
Might not load if you’re in Ukraine and the location of the server you’re trying to access is in Russia. Blocked on the country level. Works very well for me, I can easily distinguish someone trying to pretend they are in the EU, while being in Russia. Have no idea whether this is the case, but it does not load for me either.
cyberlimerence · 2m ago
It's hosted in Italy, as per the DNS record. I don't think you can register .eu domain if you're not based in Europe/EU.
EVa5I7bHFq9mnYK · 30m ago
It's a very ong article, here is ChatGpt summary:
Google removed XML/XSLT/RSS/etc., and replaced them with alternatives that serve centralization and corporate control.
RSS & Atom (open feeds) → Replaced by Google Reader’s shutdown (2013) and a push toward centralized social media feeds (Facebook, Twitter, Google+, later corporate “news” algorithms).
XSLT (standard declarative templating
/transformation) → Marginalized in favor of JavaScript frameworks (React, Angular, Vue, etc.) and JSON APIs (instead of XML).
SMIL (declarative SVG animations) → Replaced by CSS animations and JavaScript-driven animation libraries, which are heavier and more entangled with corporate-controlled browser APIs.
keygen (built-in client-side crypto & mutual authentication) → Effectively replaced by Google-controlled identity systems (OAuth, Sign in with Google) and by TLS/HTTPS enforced through certificate authorities (increasingly under corporate influence).
JPEG XL (next-gen image format) → Squashed, leaving devs stuck with WebP (Google’s own format), or the old JPEG/PNG/GIF trio.
MathML (semantic math markup) → Suppressed for years, replaced in practice by JavaScript libraries like MathJax, until reintroduced only thanks to outside effort.
Open web syndication & blogging culture → Replaced by corporate platforms (Blogger, YouTube, Gmail, Google Docs, later AMP and “instant articles” clones), all optimized for ads, surveillance, and lock-in.
1) Google doing whatever they want with matters that affect every single human on the planet.
2) Google running a farse with "public feedback" program where they don't actually listen, or in this case ask for feedback after the fact.
3) Google not being truthful or introspective about the reasons for such a change, especially when standardized alternatives have existed for years.
4) Honestly, so much of standard, interoperable "web tech" has been lost to Chrome's "web atrocities" and IE before that... you'd think we've learned the lesson to "never again" have a dominant browser engine in the hands of a "for profit" corp.
I think, from my experience at least, that we keep getting these "component reuse" things coming around "oh you can use Company X's schema to validate your XML!" "oh you can use Company X's custom web components in your web site!" etc etc yet it rarely if ever seems to be used. It very very rarely ever feels like components/schemas/etc can be reused outside of their intended original use cases, and if they can they are either so trivially simple it's hardly worth the effort, or they are so verbose and cumbersome and abstracted trying to be all things to all people then it is a real pain to work with. (And for the avoidance of doubt I don't mean things like tailwind et Al here)
I'm not sure who keeps dreaming these things up with this "component reuse" mentality but I assume they are in "enterprise" realms where looking busy and selling consulting is more important than delivering working software that just uses JSON :)
Funny how went from "use it for everything" (no matter how suitable) to "don't use it for anything new" in just under two decades.
To me XML as a configuration file format never made sense. As a data exchange format it has always been contrived.
For documents, together with XSLT (using the excellent XPath) and the well thought out schema language RelaxNG it still is hard to beat in my opinion.
I use it to store complex 3D objects. It works surprisingly well.
Use the correct tool for the job. If that tool is XML, then I use it instead of $ShinyThing.
You can get XML and convert it to everything. I use it to model 3D objects for example, and the model allows for some neat programming tricks while being efficient and more importantly, human readable.
Except being small, JSON is worst of both worlds. A hacky K/V store, at best.
Lost? The format is literally everywhere and a few more places. Hard to say something lost when it's so deeply embedded all over the place. Sure, most developers today reach for JSON by default, but I don't think that means every other format "lost".
Not sure why there is always such a focus on who is the "winner" and who is the "loser", things can co-exists just fine.
And I don't care at all about the feelings of AI agents. That a tool that's barely existed for 15 minutes doesn't need a feature is irrelevant when talking about whether or not to continue supporting features that have been around for decades.
Conceptually it was beautiful: We had a set of XSL transforms that could generate RSS, Atom, HTML, and a "cleaned up" XML from the same XML generated by our frontend, or you could turn off the 2-3 lines or so of code used to apply the XSL on the server side and get the raw XML, with the XSLT linked so the browser would apply it.
Every URL became an API.
I still like the idea, but hate the thought of using XSLT to do it. Because of how limited it is, we ended up having e.g. multiple representations of dates in the XML because trying to format dates nicely in XSLT for several different uses was an utter nightmare. This was pervasive - there was no realistic prospect of making the XML independent of formatting considerations.
That's been tried multiple times over the last two decades and it just ends up with a patchwork of conventions and rules defining how to jam a square peg into a round hole.
"Developers keep making this bad choice over and over" is a statement worthy of deeper examination. Why? There's usually a valid reason for it. In this instance JSON + JS framework of the month is simply much easier to work with.
While oftentimes what happens is is "oh, this thing seems to be working. And it looks easy. Great! Moving on.."
If a company breaks something so only their path works it's short term practicality to use it and long term practicality to fight for an alternative that keeps control in the developers hand.
Monopolies are terrible for software developers. Quality and customisation tend to go down, which means less value for the Devs.
Every Chrome installation or related fork, plus Electron shippments, counts.
One way is to tell everyone to use Firefox (uBlock origin works there)
It is still an issue that the Mozilla Foundation is still 80% funded by Google though, so this needs to be solved first.
Somehow Firefox needs to be moved away from Mozilla if they cannot find an alternative funding source other than Google.
Developing software is hard - and OSS hasn't found a way to do hard things yet.
The good thing is that it makes you strong and resilient to pain over time. It's painfully unreadable. It's verbose (ask chatgpt to write a simple if statement). Loops? - here's your foreach and that's all we have. Debugging is for weak, stdout is your debugger.
It's just shit tech, period. I hope devs that write soul harvesting surveillance software at Google go to hell where they are forced to write endless xslt's. Maybe that's the reason they want to remove it from Chrome.
I can't imagine wanting to use anything more complex than a for-each loop in XSLT. You can hack your way into doing different loops but that's like trying to implement do/while in Haskell.
Is it that I've grown too comfortable with thinking in terms of functional programming? Because the worst part of XSLT I can think of is the visual noise of closing brackets.
You can see it clear as day in the github thread that they weren't asking permission, they were doing it no matter what, all their concerns about security just being the pretext.
It would have been more honest of them to just tell everyone to go fuck themselves.
It seems entirely reasonable to be concerned about XSLT’s effects on security:
> 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://www.offensivecon.org/speakers/2025/ivan-fratric.html
— https://www.youtube.com/watch?v=U1kc7fcF5Ao
XSLT has been around for decades so why are you speaking in hypotheticals, as if it’s an up-and-coming technology that hasn’t been given a fair chance yet? If it hasn’t achieved that by now, it never will.
That is not a combination of words that should be mentioned in the same sentence as the word XML or, even worse, XSLT.
XML has its value in enterprise and reliable application development because the tooling is very old, very mature and very reliable. But it's not something taught in university any more, it's certainly not taught in "coding bootcamps", simply because it's orders of magnitude more complex than JSON to wrap your head around.
Of course, JSON has jsonschema, but in practice most real-world usages of JSON just don't give a flying fuck.
Google removed XML/XSLT/RSS/etc., and replaced them with alternatives that serve centralization and corporate control.
RSS & Atom (open feeds) → Replaced by Google Reader’s shutdown (2013) and a push toward centralized social media feeds (Facebook, Twitter, Google+, later corporate “news” algorithms).
XSLT (standard declarative templating /transformation) → Marginalized in favor of JavaScript frameworks (React, Angular, Vue, etc.) and JSON APIs (instead of XML).
SMIL (declarative SVG animations) → Replaced by CSS animations and JavaScript-driven animation libraries, which are heavier and more entangled with corporate-controlled browser APIs.
keygen (built-in client-side crypto & mutual authentication) → Effectively replaced by Google-controlled identity systems (OAuth, Sign in with Google) and by TLS/HTTPS enforced through certificate authorities (increasingly under corporate influence).
JPEG XL (next-gen image format) → Squashed, leaving devs stuck with WebP (Google’s own format), or the old JPEG/PNG/GIF trio.
MathML (semantic math markup) → Suppressed for years, replaced in practice by JavaScript libraries like MathJax, until reintroduced only thanks to outside effort.
Open web syndication & blogging culture → Replaced by corporate platforms (Blogger, YouTube, Gmail, Google Docs, later AMP and “instant articles” clones), all optimized for ads, surveillance, and lock-in.
Please don’t do this.