10 ms·

Hacker News reacts to JSON5 (2012)

41 points by _eojb 3y ago

eternityforest 3y ago
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?
ninepoints 3y ago
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.
- rewmie 3y ago
  If anything, to me it seems all comments critical of json5 were right on the money.
  - ninepoints 3y ago
    The comments, to my eye, have aged extremely poorly.
  - mort96 3y ago
    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?
  - aschearer 3y ago
    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.
    - rewmie 3y ago
      > Meanwhile it's become extremely popular. What's your definition of "extremely popular"?
      - _eojb 3y ago
        Used by sqlite, babel, others, and millions of downloads not good enough for you?
        pwdisswordfishc 3y ago
        So, ignored everywhere other than (reluctantly) SQLite and the dumpster fire that is NPM?
        rewmie 3y ago
        > 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 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?
        mort96 3y ago
sillysaurusx 3y ago
It’s interesting the author got the last laugh. https://news.ycombinator.com/item?id=32387153 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.
- pwdisswordfishc 3y ago
  How about both are bad
mort96 3y ago
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 https://github.com/mortie/json5cpp.
- Timon3 3y ago
  > 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).
  - mort96 3y ago
    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.
    - idbehold 3y ago
IshKebab 3y ago
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.
aschearer 3y ago
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!"
- usrusr 3y ago
  The reactions were to the https://github.com/json5/json5/tree/v0.0.0 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.
bdcravens 3y ago
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 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 https://news.ycombinator.com/item?id=32379245
- sph 3y ago
  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.
- firesteelrain 3y ago
  He kind of won his own fight
ChrisArchitect 3y ago
(2012) The more recent post from the author a year ago and discussion: https://news.ycombinator.com/item?id=32379245 https://news.ycombinator.com/item?id=32379245
captainmuon 3y ago
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.

41 points by _eojb 3y ago

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?

ninepoints 3y ago

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.

rewmie 3y ago
If anything, to me it seems all comments critical of json5 were right on the money.
- ninepoints 3y ago
  The comments, to my eye, have aged extremely poorly.
- mort96 3y ago
  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?
- aschearer 3y ago
  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.
  - rewmie 3y ago
    > Meanwhile it's become extremely popular. What's your definition of "extremely popular"?
    - _eojb 3y ago
      Used by sqlite, babel, others, and millions of downloads not good enough for you?
      - pwdisswordfishc 3y ago
        So, ignored everywhere other than (reluctantly) SQLite and the dumpster fire that is NPM?
      - rewmie 3y ago
        > 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 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?
        mort96 3y ago

sillysaurusx 3y ago

It’s interesting the author got the last laugh. https://news.ycombinator.com/item?id=32387153 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.

pwdisswordfishc 3y ago
How about both are bad

mort96 3y ago

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 https://github.com/mortie/json5cpp.

Timon3 3y ago
> 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).
- mort96 3y ago
  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.
  - idbehold 3y ago

IshKebab 3y ago

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.

aschearer 3y ago

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!"

usrusr 3y ago
The reactions were to the https://github.com/json5/json5/tree/v0.0.0 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.

bdcravens 3y ago

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 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 https://news.ycombinator.com/item?id=32379245

sph 3y ago
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.
firesteelrain 3y ago
He kind of won his own fight

ChrisArchitect 3y ago

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

captainmuon 3y ago

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.