Hacker News reacts to JSON5 (2012) | Hacker News Reader

Hacker News reacts to JSON5 (2012)

news.ycombinator.com

41 points_eojb29 comments

The nice thing about JSON5 is, you can move a project from a JSON-based config to JSON5-based config and get a significant improvement in human friendliness without sacrificing backwards compatibility; yet it's a fairly well-documented and well-known format that's not as clinically insane as YAML. It's interesting to see how many people in that HN thread talks about JSON5 as if it's a data interchange format, complaining about things like comments and other features not needed for data interchange, when it's clearly meant to be a format for humans to read/write for things like configs (or they pretend all the problems with hand-editing JSON is trivially solved in the text editor).

I do have a few gripes though. I think allowing so many weird Unicode characters as whitespace was a bad choice. JSON5's reliance on Unicode character classes in general both makes it harder to write a parser and introduces compatibility concerns as different parsers will parse files differently based on which version of Unicode they use. But all in all, JSON5 is pretty nice.

In fact, I recently wrote my own parser for it: https://github.com/mortie/json5cpp.

Amazingly nonsensical arguments against it on historic thread: that you should stringify object like its always an easy option, that comments shouldnt be used because of dsls like there is no even more stupid alternative, that it should not be changed because Daglas said so, and most fascinating, that one already has Yaml like its not 10000x times bigger language instead of 3 extra rules everybody actually wants. Amazed. Its really true that no progress is possible until current generation dies off :)

> The nice thing about JSON5 is, you can move a project from a JSON-based config to JSON5-based config and get a significant improvement in human friendliness without sacrificing backwards compatibility

What backwards compatibility are you referring to? It seems like you actually are sacrificing BC, as the JSON5 file won't be readable by older versions of your software (that doesn't use a JSON5 parser yet).

That's forwards compatibility.

Backwards compatibility: New versions of the software can use the files from old versions.

Forwards compatibility: Old versions of the software can use the files from new versions.

If you switch from JSON to JSON5, the new version can use the config file from an old version. If you switch from JSON to TOML, your users have to create a new config file, or you will have to support both JSON and TOML.

The software maybe backwards compatible, but the format is not backwards compatible as old software (expecting JSON) cannot parse the JSON5 format.

I'm not going to argue about that, since I never claimed that JSON5 is backwards compatible with JSON. I said software can move from JSON to JSON5 without breaking backwards compatibility. If you want to claim that JSON5 is forwards compatible but not backwards compatible with JSON, that's fine by me.

Makes sense, thank you!

Hell hath no fury like a nerd who perceives something is wrong!

Meanwhile u/aseemk gets to have the last laugh. In _hacker spirit_ he went and did the thing and now JSON5 "ranks in the top 0.1% of the most depended-upon packages on npm." Pretty good for an "abmonination!"

The reactions were to the https://github.com/json5/json5/tree/v0.0.0 version I think. Later versions (including what we see today on the repository) acknowledged much of the critique and narrowed down the scope to human writeable.

It might seem like unwarranted "nerd fury" from the perspective of what JSON5 has become, but at the time it was presented as (and naively believed to be) a better JSON in every way. Apparently the seeming "fury" was actually productive input.

It’s interesting the author got the last laugh. https://news.ycombinator.com/item?id=32387153

I think there’s a lesson in here about marketing. This wouldn’t have been adopted if it weren’t called JSON.

I love that everyone said “don’t call it JSON!” when JavaScript itself pulled the same damn trick vs Java.

How about both are bad

While writing a quick JSON5 parser, I encountered this old thread of incendiary takes from the HN community on the initial JSON5 proposal. Make of it what you will.

If anything, to me it seems all comments critical of json5 were right on the money.

The comments, to my eye, have aged extremely poorly.

How so? Almost all of the criticism is about how JSON5's changes make it a worse data interchange format. It's not meant to be a computer<->computer data interchange format, it's meant to be used in contexts where humans are involved, such as for config files.

Would you think criticism of TOML for having comments would be "right on the money"? No? Then why do you think differently for JSON5?

A bunch of folks bloviating why it's a terrible idea and no one will use it. Meanwhile it's become extremely popular. And you're conclusion is they're "right on the money?" Um, OK.

> Meanwhile it's become extremely popular.

What's your definition of "extremely popular"?

Used by sqlite, babel, others, and millions of downloads not good enough for you?

> Used by sqlite, babel, others (...)

I believe SQLite "uses" json5 in the sense that one of its important customers asked for json5 ingestion, and json5 was supported only for input in the spirit of the robustness principle.

From the horse's mouth.

"The important point to keep in mind is that SQLite will read JSON5, but it never writes it. The JSON that SQLite generates is canonical JSON that is fully compliant with the original JSON spec."

https://news.ycombinator.com/item?id=35962213

If your definition of success is accepting an extension because an important customer asked for an extension, so be it.

In the meantime, are you sure you want to compare plain old JSON with the mess that's JSON5? Because projects such as SQLite explicitly refuse to support JSON5, and apparently their decisions pass off as the definition of success.

> and millions of downloads

Are you sure you want to use that as a success metric?

Shit if my spec was incorporated into juggernauts like SQLite I would certainly count that as a tremendous success, but if your standards are higher than that then I guess that's mainly just a semantic discussion.

This sounds to me like SQLite fully supports JSON5, but always outputs JSON for compatibility reasons, rather than any kind of animus against JSON5.

So, ignored everywhere other than (reluctantly) SQLite and the dumpster fire that is NPM?

One of my "favorite" threads, or at least one that stuck with me. Can't believe it was so long ago. Around that time I was working on my PhD and for some reason I needed a lenient JSON parser. I took one implemented in Python and made basically the same thing, but not as nicely and didn't release it. And after reading the thread I was glad that I didn't share my code.

Also reminds me of some comments on the Nuitka Python compiler ("completely misguided"), Vlang, and multiple other projects. Some projects against conventional wisdom, but for others I'm not sure why they elicit such nerd rage.

11 years ago and this is the first time I've heard of it

I do see that a few years later he tooted his own horn:

https://aseemk.substack.com/p/ignore-the-f-ing-haters-json5

Interestingly enough, that response received more upvotes on HN than his original post

https://news.ycombinator.com/item?id=32379245

He kind of won his own fight

The comments to that last post are still as obnoxious and as short-sighted as the original: a bunch of nerds bike-shedding and defending the status quo as if their life depended on it. Only there you can find so many that just love JSON, as if it descended from heaven and they have never had any issue with it. What's a trailing comma?

I guess the lesson is: avoid the opinion of popularity-based social media, such as Reddit, HN, Twitter, etc. 90% is people trying to outsmart each other with their drive by criticism for karma.

In fact, in general, just ignore pretty much anyone's opinion if you are creating something, whether it's a personal project, a work of art or any other creative endeavour. Vision is a solitary process; the vast majority lack vision at all, and pretty much no one shares YOUR vision.

I think JSON5 is great but unfortunately it still doesn't have as good support as JSON even in very popular environments. For example C++ has nlohman's JSON for Modern C++ which supports a ton of formats but not JSON5. VSCode has a JSON5 extensions but it doesn't support JSON Schema, which is a huge benefit. The Python JSON5 module is apparently 200x slower than even the pure Python JSON parser. 1-6000x slower than C!

Given that, I might switch to jsonnet. It seems to have better support, and while it is a lot more complex and includes some crazy anti-features (automatic type coercion - guys it's 2023), sometimes those features do come in handy and it seems to be mostly well designed.

The only big issue I've found with it so far is that it also has no schema support.

I think INI files are often better for anything that will be hand written. Once you start adding layers of nesting the semantics themselves get confusing and people get tempted to reorganize things.

Flat is Better than Nested, says Python.

JSON is great for machine to machine stuff that a human might incidentally modify or debug. For anything else, there's other formats. Although multiline strings are nice to have.

Seems like a decent approach might be the robustness principle. Accept it, and if support becomes really common, them start writing it?

This lacks unquoted string values though. I'm not sure why being a subset of ecmascript matters aside from just consistency for the programmer?

(2012)

The more recent post from the author a year ago and discussion: https://news.ycombinator.com/item?id=32379245

Reply on news.ycombinator.com