There are a lot of comments focusing more on the specifics of XML and XSLT because that's what much of the article laboriously drones on about, despite its general title.

> NaCL? Mozilla won this one. Wasm is a continuation of asm.js.

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.

Amp pages' miserable failure. There's a lot of Google failures.

Tons of APIs and applications work with XML. XSLT less so; that's more of a backend language.

Yes, RSS.

Immaterial. If the answer is either 'yes' or 'no', it makes no actual difference: gopher still exists, is still a thing, is still successful. It feels like you're just trying to move the goal-posts and redefine what 'lose' means and trying to lure the poster into a "gotcha".

Looking at the list, what actually jumps out at me is there is probably a gap in the world of standards for a JSON-based replacement to RSS. Looking it up someone came up with the idea of https://www.jsonfeed.org/ and hopefully it gains traction.

In hindsight, it is hard to imagine a JSON-based RSS-style standard struggling to catch. The first project every aspiring JS developer would be doing is how to add a feed to their website.

EAD does indeed look like a good example of why we shouldn't use XML.

Uh can't XML have whitespace throughout it just as much as JSON? They seem pretty similar in this respect.

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

I have a hilarious example of this. I was hired to consult at a large company that had "configurators" which were applications that decided all sorts of things for if you were building a new factory and needed to use this company's stuff for your factory, so for example one configurator would be a search for replacement part in your area - so if you are building a factory in Asia but you want to use a particular part but that part is has export restrictions for it from the U.S where it is manufactured you would use this tool to pick out the appropriate replacement part made somewhere in Asia.

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.

By efficiency, I mean it's text and compresses well. If we mean speed, there are extremely fast XML parsers around see this page [0] for state of the art.

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

> Calling XML human readable is a stretch.

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.

It's kinda funny to see "not human readable" as an argument in favor of JSON over XML, when the former doesn't even have comments.

This is why you can have attributes in a tag. You can make an XML file self explanatory.

Consider the following example:

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

RSS says hi!

> You can write your page in pretty much pure HTML, or even pure HTML if you use comments or custom tags for block markers.

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.

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.

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

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.