> "- xml contain comments, sooner or later someone will try to add data to comments, but you already have the thing for data, the format itself, adding data to comments is stupid"

That's easily the worst argument against comments I've ever heard! Would you argue against comments in code because some jackass could abuse it to insert custom compiler directives or something? Ridiculous. The good comments do easily outweighs any harm some moron is going to do to himself by parsing comments for data.

I don't like XML any more than the rest of you, but praising json for not having comments just smacks of sour grapes.

The intentional lack of comments cements json's position as a (human readable) data interchange format. It's not designed to be anything else. Which is fine. There's nothing wrong with a file format being focused on one goal.

Indeed.

And the point of the article is that JSON is fine for data, but configs are not data. Configs are code.

Lack of comments just makes it a data interchange format. It’s comments which make things human readable.

But you don't _need_ to abuse comments for extra (or meta-) data if you're using XML, you just use a separate namespace.

It's definitely the case that XML has features that aren't needed -- or at least, we've survived without them thus far -- but there definitely feels like more than just a smidge of only realising later why some of that complexity was present. See also: npm vs pretty much any other dependency management system.

> parsing xml may cause random random network requests (firewall issues)

inability to properly use a library should not count against it