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
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.
The narrative would be more compelling to me if Google didn’t fail to impose their technology on the web so many times.
NaCL? Mozilla won this one. Wasm is a continuation of asm.js.
Dart? It now compiles to Wasm but has mostly failed to replace js while Typescript filled the niche.
Sure, Google didn’t care much for XML. They had a proper replacement for communication and simple serialisation internally in protobuf which they never actually try to push for web use. Somehow json ended up becoming the standard.
I personally don’t give much credit to the theory of Google as a mastermind patiently under minding the open web for years via the standards.
Now if we talk about how they have been pushing Chrome through their other dominant products and how they have manipulated their own products to favour it, I will gladly agree that there is plenty to be said.
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.
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.
+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 :)
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.
probably nobody would choose it for anything new because the sweet spots for XML usage have all already been taken, that said if someone was to say hey we need to redo some of these standards they can of course find ways to make JSON work for some standards that are XML nowadays, but for a lot of them JSON would be the absolute worst and if you were redoing them you would use XML to redo.
basically anything that needs to combine structured and unstructured data and switch between the two at different parts of your tree are probably better represented as XML.
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.
LLMs produce much more consistent XML than JSON because JSON is a horrible language that can be formatted in 30 different ways with tons of useless spaces everywhere, making for terrible next token prediction.
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.
Calling XML human readable is a stretch. It can be with some tooling, but json is easier to read with both tooling and without.
There's some level of the schema being relevant to how human readable the serialization is, but I know significantly fewer people that can parse an XML file by sight than json.
Efficient is also... questionable. It requires the full turing machine power to even validate iirc. (surely does to fully parse).
by which metric is XML efficient?
Serialize that to a JavaScript object, then tell me, is "AnElement" a list or not?
That's one of the reasons why XML is completely useless on the web. The web is full of XML that doesn't have a schema because writing one is a miserable experience.
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.
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.
XSLT is much nicer to use if you just create a very simple templating language that compiles to XSLT. Subset of XLST already has a structure of typical templating language. It can even be done with regexps.
Then simplicity becomes a feature. You can write your page in pretty much pure HTML, or even pure HTML if you use comments or custom tags for block markers. Each template is simple and straightforward to write and read.
And while different date format seems to be a one off thing you'd prefer to deal with as late as possible in the stack, if you think broader, like addressing global audience in their respective languages and cultures, you want to support that on the server so the data (dates, numbers, labels) lands on the client in the correct language and culture. Then doing just dates and perhaps numbers in the browser is just inconsistent.
I think JSON is generally better than XML (although XML is better for some things, mostly it isn't), but JSON is not so good either; I think DER format is much better.
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.
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.
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?
isodev|6 months ago
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.
StopDisinfo910|6 months ago
NaCL? Mozilla won this one. Wasm is a continuation of asm.js.
Dart? It now compiles to Wasm but has mostly failed to replace js while Typescript filled the niche.
Sure, Google didn’t care much for XML. They had a proper replacement for communication and simple serialisation internally in protobuf which they never actually try to push for web use. Somehow json ended up becoming the standard.
I personally don’t give much credit to the theory of Google as a mastermind patiently under minding the open web for years via the standards.
Now if we talk about how they have been pushing Chrome through their other dominant products and how they have manipulated their own products to favour it, I will gladly agree that there is plenty to be said.
rapnie|6 months ago
diggan|6 months ago
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|6 months ago
mattlondon|6 months ago
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 :)
NoboruWataya|6 months ago
bryanrasmussen|6 months ago
example formats that should not ever be JSON
TEI https://tei-c.org/ EAD https://www.loc.gov/ead/ docbook https://docbook.org/
are three obvious ones.
basically anything that needs to combine structured and unstructured data and switch between the two at different parts of your tree are probably better represented as XML.
bayindirh|6 months ago
I use it to store complex 3D objects. It works surprisingly well.
temporallobe|6 months ago
weinzierl|6 months ago
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.
ekianjo|6 months ago
MrVandemar|6 months ago
Use the correct tool for the job. If that tool is XML, then I use it instead of $ShinyThing.
bayindirh|6 months ago
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.
ongy|6 months ago
Efficient is also... questionable. It requires the full turing machine power to even validate iirc. (surely does to fully parse). by which metric is XML efficient?
mortarion|6 months ago
<MyRoot> <AnElement> <Item></Item> </AnElement> </MyRoot>
Serialize that to a JavaScript object, then tell me, is "AnElement" a list or not?
That's one of the reasons why XML is completely useless on the web. The web is full of XML that doesn't have a schema because writing one is a miserable experience.
agos|6 months ago
jon-wood|6 months ago
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|6 months ago
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.
scotty79|6 months ago
Then simplicity becomes a feature. You can write your page in pretty much pure HTML, or even pure HTML if you use comments or custom tags for block markers. Each template is simple and straightforward to write and read.
And while different date format seems to be a one off thing you'd prefer to deal with as late as possible in the stack, if you think broader, like addressing global audience in their respective languages and cultures, you want to support that on the server so the data (dates, numbers, labels) lands on the client in the correct language and culture. Then doing just dates and perhaps numbers in the browser is just inconsistent.
If browsers implemented https://en.m.wikipedia.org/wiki/Efficient_XML_Interchange the web would get double digit percent lighter and faster and more accessible to humans and ai.
But that would let you filter out ads orders of magnitude easier. So it won't happen.
int_19h|6 months ago
zzo38computer|6 months ago
_heimdall|6 months ago
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|6 months ago
"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.
sharpfuryz|6 months ago
unknown|6 months ago
[deleted]