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.

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.

And yet the design of wasm is the way it is to a large extent because of V8 limitations and Google's pushback on having to do any substantial changes for the sake of a clean design.

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.

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 :)

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.

https://www.loc.gov/ead/tglib1998/tlin125.html

Earlier I had only seen the mix of values in body and values in tags. With one even being a tag called "value".

Thanks for showing more examples of XML being used to write unreadable messes.

Granted, html actually makes sense in the xml-ish (I don't remember if it's technically compliant), since it weaves formatting into semantically uninterrupted text.

If that's not the case, I don't see a real benefit to use XML over anything sane (not yaml... Binary formats depending on use case)

I guess if that's the standard then reading any data format is also a slog because hey, most data and document formats get rendered as something for "human consumption" but that said when one is a programmer one often has to read the format without the rendering, and so, your witty reply aside I guess you must find this task where HTML is concerned a slog.

This is too bad because most mixed content formats like EAD, HTML etc. are like that, and if you want humans to be able to write the content with say a paragraph, but inside that paragraph is a link etc. you're going to write it mixed content, because that works best based on millions of programmer and editor hours over decades and JSON would be crap for it.

Is it super great, nope it's only the best way of writing document formats (with highly technical and mix of structured and unstructured content) that we currently know of, in the same way that Democracy is the worst form of politics except for all the all others and multiple other examples of things that suck in the world but are better than all the alternatives.

I didn't say EAD was great, I said it was better than JSON for what it needed to do, part of which is having humans write mixed content.

Believe me I have certainly seen people who have been JSON enthusiasts try to replicate mixed content type documents in JSON and it has always ended up looking at least as bad as any XML but without all the tooling to make it easier to write XML and with a tendency to brittleness because in doing mixed content in JSON you are going to have to do a lot of character escaping.

I'm going to end off here with the observation that I doubt you are actually acquainted with the workflows of editors, writers, publishing industries and the use of markup formats in any sort of long running type of company using these things? I just have a feeling on this matter. You seem like your technical area of expertise is not in the area you are critiquing? Some of these companies are actually quite technically advanced, so I'm just putting that out there that you might not be as aware of the requirements of parts of the world that use things that you would build in a superior manner if only you were given the task to do so.

I use it to store complex 3D objects. It works surprisingly well.

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.

    <foo    bar="x"  baz  = "y" />

Use the correct tool for the job. If that tool is XML, then I use it instead of $ShinyThing.

They had like 50 different configurators built at different times using different tech etc. (my memory is a bit fuzzy here as to how many they had etc. but it was a lot) So of course they wanted to make a solution for putting their codebase together and also make it easy to make new configurators.

So they built a React application to take a configurator input format that would tell you how to build this application and what components to render and blah blah blah etc.

Cool. But the configurator format was in JSON so they needed to make an editor for their configurator format.

They didn't have a schema or anything like this they made up the format as they went along, and they designed the application as they went along by themselves, so application designed by programmers with all the wonder that description entails.

That application at the end was just a glorified tree editor that looked like crap and of course had all sorts of functionality behavior and design mixed in with its need to check constraints for outputting a particular JSON structure at a particular point. Also programmed in React.

There was about 10 programmers, including several consultants who had worked on this for over a year when I came along, and they were also shitting bricks because they had only managed to port over 3 configurators, and every time they ported a new one they needed to add in new functionality to the editor and the configurator compiler, and there was talk of redesigning the whole configurator editor cause it sucked to use.

Obviously the editor part should have been done in XML. Then people could have edited the XML by learning to use XML spy, they could have described their language in XML schema real easy, and so forth.

But no they built everything in React.

The crowning hilarity - this application at most would ever be used by about 20 people in the world and probably not more than 10 people at all.

I felt obligated by professional pride (and also by the fact that I could see no way could this project keep being funded indefinitely so it was to my benefit to make things work) to explain how XML would be a great improvement over this state of affairs but they wouldn't hear of it.

After about 3 months on it was announced the project would be shut down in the next year. All that work wasted on an editor that could probably have been done by one expert in a month's time.

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.

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?

For hands-on experience, I used rapidxml for parsing said 3D object files. A 116K XML file is parsed instantly (the rapidxml library's aim is to have speed parity with strlen() on the same file, and they deliver).

Converting the same XML to my own memory model took less than 1ms including creation of classes and interlinking them.

This was on 2010s era hardware (a 3rd generation i7 3770K to be precise).

Verifying the same file against an XSLT would add some milliseconds, not more. Considering the core of the problem might took hours on end torturing memory and CPU, a single 20ms overhead is basically free.

I believe JSON and XML's readability is directly correlated with how the file is designed and written (incl. terminology and how it's formatted), but to be frank, I have seen both good and bad examples on both.

If you can mentally parse HTML, you can mentally parse XML. I tend to learn to parse any markup and programming language mentally so I can simulate them in my mind, but I might be an outlier.

If you're designing a file format based on either for computers only, approaching Perl level regular expressions is not hard.

Oops, forgot the link:

[0]: https://pugixml.org/benchmark.html

That’s always been the main flaw of XML.

There are very few use case where you wouldn’t be better served by an equivalent more efficient binary format.

You will need a tool to debug xml anyway as soon as it gets a bit complex.

https://en.m.wikipedia.org/wiki/Efficient_XML_Interchange

But somehow google forgot to implement this.

Most of the time you will actually be debugging what’s inside the file to understand why it caused an issue and find if that comes from the writing or receiving side.

It’s pretty much like with a binary format honestly. XML basically has all the downside of one with none of the upside.

It's also pretty easy to emit, "I didn't find what I'm looking for under $ELEMENT" while parsing the file, or "I expected a string but I got $SOMETHING at element $ELEMENT".

Maybe I'm distorted because I worked with XML files more than decade, but I never spent more than 30 seconds while debugging an XML parsing process.

Also, this was one of the first parts I "sealed" in the said codebase and never touched it again, because it worked, even if the coming file is badly formed (by erroring out correctly and cleanly).

I think we are actually in agreement. You could do exactly the same with a binary format without having to deal with the cumbersomeness of xml which is my point.

You are already treating xml like one writing errors in your own parsers and "sealing" it.

What’s the added value of xml then?

Telling the parser to navigate to first element named $ELEMENT, checking a couple of conditions and assigning values in a defensive manner is not cumbersome in my opinion.

I would not call parsing binary formats cumbersome (I'm a demoscene fan, so I aspire to match their elegance and performance in my codebases), but not the pragmatic approach for that particular problem at hand.

So, we arrive to your next question:

> What’s the added value of xml then?

It's various. Let me try to explain.

First of all, it's a self documenting text format. I don't need an extensive documentation for it. I have a spec, but someone opening it in a text editor can see what it is, and understand how it works. When half (or most) of the users of your code are non-CS researchers, that's a huge plus.

Talking about non-CS researchers, these folks will be the ones generating these files from different inputs. Writing an XML in any programming language incl. FORTRAN and MATLAB (not kidding) is 1000 times easier and trivial than writing a binary blob.

Expanding that file format I have developed on XML is extremely easy. You change a version number, and maybe add a couple of paths to your parser, and you're done. If you feel fancy, allow for backwards compatibility, or just throw an error if you don't like the version (this is for non-CS folks mostly. I'm not that cheap). I don't need to work with nasty offsets or slight behavior differences causing to pull my hairs out.

The preservation is much easier. Scientific software rots much quicker than conventional software, so keeping file format readable is better for preservation.

"Sealing" in that project's parlance means "verify and don't touch it again". When you're comparing your results with a ground truth with 32 significant digits, you don't poke here and there leisurely. If it works, you add a disclaimer that the file is "verified at YYYYMMDD", and is closed for modifications, unless necessary. Same principle is also valid for performance reasons.

So, building a complex file format over XML makes sense. It makes the format accessible, cross-platform, easier to preserve and more.

<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.

Consider the following example:

    <MyRoot>
      <AnElement type="list" items="1">
        <Item>Hello, World!</Item>
      </AnElement>
    <MyRoot>

JSON for all it's flaws is beautifully simple in comparison. A number is either a number or the document is invalid. Arrays are just arrays and objects are just objects.

XML on the other hand is the wild west. This particular XML beast had some difficulty sticking to one thing.

Take for instance lists. The same document had two different ways to do them:

  <Thing>
    <Name>...</Name>
    <Image>...</Image>
    <Image>...</Image>
  </Thing>

  <Thing>
    <Name>...</Name>
    <Images>
      <Image>...</Image>
      <Image>...</Image>
    </Images>
  </Thing>

To prevent code reuse, some element names were namespaced, so you might have <ThingName /> and <FooName />.

To round off my already awful day, some numbers were formatted with thousands separators. Of course, these can change depending on your geographical location.

Now, one could say that this is just the fault of the specific XML files I was parsing. And while I would partially agree, the fact that a format makes this possible is a sign of it's quality.

Since there's no clear distinction between objects and arrays you have to pick one. Or multiple.

Since objects can be represented with both attributes and children you have to pick one. Or both.

Since there are no numbers in XML, you can just write them out any way you want. Multiple ways is of course preferable.

I know you describe a real-life situation, but if XML gets abused it's not XML's fault - like it's not JSON's fault if JSON gets abused

As far as I can tell, the file was a fully valid XML file. The issue is that doesn't really tell you (or guarantee) much.

There's just no one specific way to do a thing.

Simple formats are abuse-proof because of their limitations, and it makes perfect sense in some cases (I'm a Markdown fan, for example, but prefer LaTeX for serious documents). Flexible formats are more prone to abuse and misuse. XML is extremely flexible and puts the burden of designing and sanity checking the file to the producers and consumers of the file format in question. This is why it has a couple of verification standards built on top of it.

I personally find very unproductive to yell at a particular file format because it doesn't satisfy some users' expectation out of the box. The important distinction is whether it provides the capability to address those or not. XML has all the bells and whistles and then some to craft sane, verifiable and easily parseable files.

I also strongly resist that the notion of making everything footgun proof. Not only it stifles creativity and progress, it makes no sense. We should ban all kinds of blades, then. One shall read the documentation of the thing they are intending to handle before starting. The machine has no brain, we shall use ours instead.

I'm also guilty of it myself. Some of my v1 code holds some libraries very wrong, but at least I reread the docs and correct the parts iteration by iteration (and no, I don't use AI in any form or shape for learning and code refactoring).

So if somebody misused any format and made it miserable to parse, I'd rather put the onus on the programmer who implemented the file format on top of that language, not the language itself (XML is a markup language).

The only file format I don't prefer to use is YAML [2]. The problem is its "always valid" property. This puts YAML into "Risk of electric shock. Read the manual and read it again before it operate this" category. I'm sure I can make it work if I need to, but YAML's time didn't come for me, yet. I'd rather use INI or TOML (INI++) for configuring things.

[0]: https://news.ycombinator.com/item?id=41120254

[1]: https://news.ycombinator.com/item?id=44934386

[2]: https://noyaml.com/

How is it a sailed ship?

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.

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.

Developers deemed it too complex (or they were just stupid?)

SharePoint 2013 went the CSR (Microsofts "Client-Side-Rendering") path and SharePoint 2016 went the JSON/React path

Maybe with current AI aid XSLT would have had a chance... or we are still just too stupid.

Yes, XML/XSLT is a better technology, so was any Video Casette tape BUT VHS in the early 80s

That's exactly what we didn't want. The XSL encoded the view. The "page" was a pure semantic representation of the data in XML that wherever possible were direct projections from the models stored and serialied internally in our system, and the XSL generated each of the different views - be it HTML, RSS, Atom, or a condensed/simplified XML view. The latter was necessary largely because the "raw" XML data was more verbose than needed due to the deficiencies of XSL.

It's possible it'd be more pleasant to use XSL your way, but that way wouldn't have solved any issues we had a need to solve.

> you want to support that on the server so the data (dates, numbers, labels) lands on the client in the correct language and culture.

That would've meant the underlying XML would need to mix view and model considerations, which is exactly what we didn't want.

Today I'd simply use a mix of server-side transformations, CSS, and web components to achieve the same thing rather than try to force XSL to work for something it's so painful to use for.

What I wanted to say is that I didn't write XSLT by hand. Instead I was writing XHTML files with just few short, convenient markers, and my regexps based "compiler" converted them to various xls nasty tags generating output XSLT that was served.

For example `$name` was converted to `<xsl:value-of select="name" />` and `@R:person` was converted to `<xsl:for-each select="person">` and `@E` was converted to `</xsl:for-each>`

Basically there were 5 tags that were roughly equivalent to

with, for, else, if, end

`with` descended into a child in XML tree if the child was present and displayed enclosed XHTML

`for` displayed copy of the enclosed XHTML for each copy of its argument present in XML, descending into them

`else` displayed enclosed XHTML only if the argument node didn't exist in XML

`if` displayed enclosed XHTML Argument only if the element existed

Neither if nor else descended into the argument node in XML. With and for descended. XSLT was using relative paths everywhere.

`end` marked the end of each respective block.

> That would've meant the underlying XML would need to mix view and model considerations, which is exactly what we didn't want.

The thing is, what you are serving to the browser is always a View-Model. If you serve a Model instead you are just "silently casting" it onto a View-Model because at that moment they are identical. Sooner or later the need will arise to imbue this with some presentation specific information attached on the fly to data from your data layer Model.

I no longer try to use XSLT either, but I think web components are completely orthogonal tool. Your XSLT could still generate web components if you like. You could even "hydrate" generated HTML with React for interactivity.

What XML+XSLT was solving was basically skipped entirely by programmers. Instead of taking care about separating concerns, performance, flexibility they just thrown into the browser a server side generated soup that is only one step away from compiled binary and called it a day.

There's a huge difference in the level of presentation specific logic you include, though. E.g. between including the publication date of something vs. including the publication date in 4 different ways because it needs to be presented in 4 different ways in different formats and templates. One is about having to ensure a superset of the information required is available, and that superset can often involve very limited overhead (and can even end up being "cheaper" through being able to have fewer, more heavily accessed, cached items), while the other means you need to closely couple it to specific details of the presentation.

> I no longer try to use XSLT either, but I think web components are completely orthogonal tool. Your XSLT could still generate web components if you like. You could even "hydrate" generated HTML with React for interactivity.

Web components alone maybe, but combined with a higher level framework that also lets you do server side rendering, we're back to being able to serve up a single format and choose to transform it either on the server side or client side as needed, without the pain of XSL

> Your XSLT could still generate web components if you like.

Yes, but I wouldn't gain anything at all from that other than the pain of dealing with XSLT.

> What XML+XSLT was solving was basically skipped entirely by programmers.

Because XML+XSLT wasn't solving it in a way that was good enough even for people like me who badly wanted to like it. We got it to work, but neve

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.

XSLT is more related to frontend frameworks like react. Where XML and JSON are ways of representing state, XSLT and react (or similar) are ways of defining how that state is converted to HTML meant for human consumption.

For what its worth, XSLT 3.0 can apparently work with JSON as well if your main concern from a couple comments up is XML vs JSON.

While oftentimes what happens is is "oh, this thing seems to be working. And it looks easy. Great! Moving on.."