It’s true, though, that JSON is just better for most applications.

{"comment": "Who says you can't do comments in JSON?"}

{"comment2": "I can do this all day."}

While I understand the critic about XPath and XSL, the fact that we have proper tools to query and tranform XML instead of the messy wat of getting specific information from JSON is also one of tge strong point of XML.

Skimming through the post, the code snippet about halfway through picked my attention. Been a while since I studied site development, but that snippet looks awfully like HTML. Are it and XML related?

The fact that json serializes easily to basic data structures simplifies code so much. Most use cases don’t need fully sematic data storage much of which you have to write the same amount of documentation about the data structures anyways. I’ll give XML one thing though, schemas are nice and easy, but high barrier to entry in json.

I never understood why people would say JSON is superior, and why XML seemed to be getting rarer, but the author explains it:

XML was not abandoned because it was inadequate; it was abandoned because JavaScript won.

I’ve been using it ever since I started using Linux because my favorite window manager uses it, and because of a long-running pet project that is almost just as old: first I used XML tools to parse web pages, later I switched to dedicated data providers that offered both XML and JSON formats, and stuck to what I knew.

I’m guessing that another reason devs - especially web devs - prefer JSON over XML is that the latter uses more bytes to transport the same amount of raw data. One XML file will be somewhat larger than one JSON file with the same content. That advantage is of course dwarved by all the other media and helper scripts - nay, frameworks, devs use to develop websites.

BTW, XML is very readable with syntax highlighting and easily editable if your code editor has some very basic completion for it. And it has comments!

IMHO one of the fundamental problems with XML for data serialization is illustrated in the article:

(person (name “Alice”) (age 30))
[is serialized as]

<person>
  <name>Alice</name>
  <age>30</age>
</person>

Or with attributes:
<person name=“Alice” age=“30” />

The same data can be portrayed in two different ways. Whenever you serialize or deserialize data, you need to decide whether to read/write values from/to child nodes or attributes.

That’s because XML is a markup language. It’s great for typing up documents, e.g. to describe a user interface. It was not designed for taking programmatic data and serializing that out.

<items>
  <item></item>
  <item></item>
  <item></item>
</items>

<items>
  <item index="1"></item>
  <item index="2"></item>
  <item index="3"></item>
</items>

Honestly, anyone pining for all the features of XML probably didn’t live through the time when XML was used for everything. It was actually a fucking nightmare to account for the existence of all those features because the fact they existed meant someone could use them and feed them into your system. They were also the source of a lot of security flaws.

This article looks like it was written by someone that wasn’t there, and they’re calling people telling them the truth that they are liars because they think features they found in w3c schools look cool.

Preaching the choir I like to sing in.

I didn’t know the link to S-Expressions, ty.

There exists a peculiar amnesia in software engineering regarding XML

That’s for sure. But not in the way the author means.

There exists a pattern in software development where people who weren’t around when the debate was actually happening write another theory-based article rehashing old debates like they’re saying something new. Every ten years or so!

The amnesia is coming from inside the article.

[XML] was abandoned because JavaScript won. The browser won.

This comes across as remarkably naive to me. JavaScript and the browser didn’t “win” in this case.

JSON is just vastly simpler to read and reason about for every purpose other than configuration files that are being parsed by someone else. Yaml is even more human-readable and easier to parse for most configuration uses… which is why people writing the configuration parser would rather use it than XML.

Libraries to parse XML were/are extremely complex, by definition. Schemas work great as long as you’re not constantly changing them! Which, unfortunately, happens a lot in projects that are earlier in development.

Switching to JSON for data reduced frustration during development by a massive amount. Since most development isn’t building on defined schemas, the supposed massive benefits of XML were nonexistent in practice.

Even for configuration, the amount of “boilerplate” in XML is atrocious and there are (slightly) better things to use. Everyone used XML for configuration for Java twenty years ago, which was one of the popular backend languages (this author foolishly complains about Java too). I still dread the massive XML configuration files of past Java. Yaml is confusing in other ways, but XML is awful to work on and parse with any regularity.

I used XML extensively back when everyone writing asynchronous web requests was debating between using the two (in “AJAX”, the X stands for XML).

Once people started using JSON for data, they never went back to XML.

Syntax highlighting only works in your editor, and even then it doesn’t help that much if you have a lot of data (like configuration files for large applications). Browsers could even display JSON with syntax highlighting in the browser, for obvious reasons — JSON is vastly simpler and easier to parse.

IMO, the best thing about YAML is the referencing. It’s super easy to reuse an object multiple times. Gives that same kind of parten child struct ability that programming languages have. Sure XML can do it, but it’s not in every parser. cough python built in parser cough But then YAML is also not a built in parser and doing DOM in things other than XML feels odd.

JSON is easier to parse, smaller and lighter on resources. And that is important in the web. And if you take into account all the features XML has, plus the entities it gets big, slow and complicated. Most data does not need to be self descriptive document when transferring through web. Fundementally these languages are two different kind of languages: XML is a general markup language to write documents, while JSON is a generalized data structure with support for various data types supported by programming languages.

I love XML, when it is properly utilized. Which, in most cases, it is not, unfortunately.

JSON > CSV though, I fucking hate CSV. I do not get the appeal. “It’s easy to handle” – NO, it is not. It’s the “fuck whoever needs to handle this” of file “formats”.

JSON is a reasonable middle ground, I’ll give you that

{
    "columns": ["id", "name", "age"],
    "rows": [
        [1, "bob", 44], [2, "alice", 7], ...
    ]
}

ASN.1 crying in the corner.

XMPP shows pretty well that XML can do things that cannot be done easily without it. XMPP wouldn’t work nearly as well with JSON. Namespaces are a super power.

I’m sure XML has its uses

I’m also sure that for 99% of the applications out there, XML is overkill and over complicated, making things slower and more error prone

Use JSON, and you’ll be fine. If you really really need XML then you probably already know why

When you receive an XML document, you can verify its structure before you ever parse its content. This is not a luxury. This is basic engineering hygiene.

This is actually why my colleagues and I helped kill off XML.

XML APIs require extensive expertise to upgrade asynchronously (and this expertise is vanishingly rare). More typically all XML endpoints must be upgraded during the same unscheduled downtime.

JSON allows unexpected fields to be added and ignored until each participant can be upgraded, separately and asynchronously. It makes a massive difference in the resilience of the overall system.

I really really liked XML when I first adopted it, because before that I was flinging binary data across the web, which was utterly awful.

But XML for the web is exactly where it belongs - buried and forgotten.

Also, it is worth noting that JSON can be validated to satisfy that engineering impulse. The serialize/deserialize step will catch basic flaws, and then the validator simply has to be designed to know which JSON fields it should actually care about. This gets much more resilient results than XMLs brittle all-in-one shema specification system - which immediately becomes stale, and isn’t actually correct for every endpoint, anyway.

The shared single schema typically described every requirement of every endpoint, not any single endpoint’s actual needs. This resulted in needless brittleness, and is one reason we had such a strong push for “microservices”. Microservices could each justify their own schema, and so be a bit less brittle.

That said, I would love a good standard declarative configuration JSON validator, as long as it supported custom configs at each endpoint.

I agree with everything this article said. A lot of software would work better if devs took the time to learn and appreciate XML. Many times I’ve found myself reinventing shit XML gives you for free.

…But at the same time, if I’m working on a developer-facing product of any kind, I know that choosing XML over JSON is going to turn a lot of people away.

XML is best suited for storing documents, JSON for transmitting application data over networks.

SVG is an example of an excellent use of XML, it doesn’t mean we should use XML for transmitting data from a backend to a frontend.