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.
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.
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."
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.
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.
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).
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.
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.
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.
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.
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.
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.
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?
29 comments
[ 495 ms ] story [ 151 ms ] threadWould you think criticism of TOML for having comments would be "right on the money"? No? Then why do you think differently for JSON5?
What's your definition of "extremely popular"?
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?
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.
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.
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).
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.
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.
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!"
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.
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
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.
The more recent post from the author a year ago and discussion: https://news.ycombinator.com/item?id=32379245
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.
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?