As the author, the reason I removed some proposed alternatives is because people kept emailing me with stuff like "but what about X?" where "X" was something I never heard of, or was only superficially familiar with.
You make it sound like it's easy to just "propose an alternative", but it's not really. First off, some problems aren't necessarily obvious from just reading a few examples. YAML is a good example of this with a lot of subtle behaviour that can really trip people up. This isn't really obvious form just a glance, and required an in-depth review. So doing a full in-depth review of all alternatives is much harder than it might seem.
Secondly, there is no single right answer. It depends on what you're doing, the language and environment you're using, social factors (e.g. if all tools in your company already use XML, then it's probably a good idea to stick with that), and probably a bunch of other factors.
Alternatives that are better are also so plentiful that quite frankly, listing all possible alternatives strikes me as rather redundant. YAML, TOML, JSON5, or even eval(), and many more, all are decent alternatives for many different scenarios, although obviously not all.
That JSON is popular doesn't mean it's a good idea. I think there is a simple reason that it's so popular: for quite a few programming languages it's the only file format that's supported in the stdlib, and people are already kinda familiar with it. This is not unreasonable choice at face value, but at the same time a lot of people don't always see the downsides at face value.
"Tell me what I should do, not what I shouldn't do" sounds like a half-wisdom. Sure, it's probably more useful. But at the same time, pointing out possible errors people haven't thought of isn't useless. I've actually received quite a few emails over the years with the gist of "I wanted to use JSON for my program, but then I read your article and decided it was a bad idea so I used YAML instead, thanks!"; so clearly, it's useful for some.
You make it sound like it's easy to just "propose an alternative", but it's not really. First off, some problems aren't necessarily obvious from just reading a few examples. YAML is a good example of this with a lot of subtle behaviour that can really trip people up. This isn't really obvious form just a glance, and required an in-depth review. So doing a full in-depth review of all alternatives is much harder than it might seem.
Secondly, there is no single right answer. It depends on what you're doing, the language and environment you're using, social factors (e.g. if all tools in your company already use XML, then it's probably a good idea to stick with that), and probably a bunch of other factors.
Alternatives that are better are also so plentiful that quite frankly, listing all possible alternatives strikes me as rather redundant. YAML, TOML, JSON5, or even eval(), and many more, all are decent alternatives for many different scenarios, although obviously not all.
That JSON is popular doesn't mean it's a good idea. I think there is a simple reason that it's so popular: for quite a few programming languages it's the only file format that's supported in the stdlib, and people are already kinda familiar with it. This is not unreasonable choice at face value, but at the same time a lot of people don't always see the downsides at face value.
"Tell me what I should do, not what I shouldn't do" sounds like a half-wisdom. Sure, it's probably more useful. But at the same time, pointing out possible errors people haven't thought of isn't useless. I've actually received quite a few emails over the years with the gist of "I wanted to use JSON for my program, but then I read your article and decided it was a bad idea so I used YAML instead, thanks!"; so clearly, it's useful for some.