Hacker News Reader

Comment by bearjaws | Hacker News Reader

The whole reason JSON rules the world is because it's brutally simple.

We already have 5+ replacements that are far more robust(XML, YML) and IMO they are not great replacements for JSON.

Why? Because you can't trust most people with anything more complicated than JSON.

I shutter at some of the SOAP / XML I have seen and whenever you enable something more complicated inevitably someone comes up with a "clever" idea that ruins your day.

View on HN

> The whole reason JSON rules the world is because it's brutally simple.

I don't think that's the primary reason. JSON is pervasive because it started out being trivially parseable by JavaScript going back to when people just evaluated it, even before browsers had ridiculously high-perfomance safe JSON parsers. All the other formats are still harder to work with from JavaScript.

If not for that, personally I'd advocate TOML, which is incredibly simple.

I find toml impossible to both read and write in all but the simplest cases.

> trivially parseable by JavaScript going back to when people just evaluated it

Comments and all, ironically.

I mean sure, "and all" would frequently include script injections etc, but you can't argue it wasn't more feature rich!

We use JSON5 for two reasons:

1. Comments 2. Trailing commas

We don't use any other JSON5 features, which are primarily just that numbers may be encoded in hexadecimal and field names may have quotes elided.

We typically encode values with RFC 4648 base 64 URI canonical with padding truncated (b64ut) with values too large to be a JSON number, so hex isn't useful anyway. We haven't found that omitting field name quotes is a big deal.

Why not use JSONC then?

There's no spec for JSONC, it's basically "whatever VSCode does".

JSON5, in contrast, has an actual spec that has been stable for 6 years now.

    is yaml robust: no

Ever since YAML 1.2, released in 2009(!), your YAML example would parse your input as “is yaml robust” for the key, and “no” for the value.

No, it wouldn't ;)

Extra hint:

    scandinavian countries:
      - dk
      - no
      - se

Edit: it's extremely unlikely a yaml parser implements that spec; the spec is irrelevant.

Okay, I originally didn't respond, but your comment got upvoted out of gray so I'll put in the effort.

Your claim of "No, it wouldn't" is simply wrong. They said "since 1.2" and you can't just ignore that when you're citing a 1.1 problem. The disclaimer that you edited in gets at a relevant point but it's not strong enough to make your claim actually be true.

And the winky face and the "hint" just make things worse, since they knew exactly what you meant.

I used to think that fixed things, then I learned how many parsers refuse to update. Like PyYAML.

The only reason JSON got any traction is because it was a subset of client-side JavaScript and thus natively supported in the browser.

To be precise, JSON was a replacement for XML, not the other way around. And the problem with XML was that it's way to verbose and difficult to write by hand, so it's exactly the opposite of the direction YAML/JSON5/... are taking.

The problem with XML was people were using it for every possible thing they could think of and 90% of those ideas were garbage.

Because it was the only widely used generic text format for structured data.

Reply on news.ycombinator.com