Live data from Hacker News

JSON5 Data Interchange Format

json5.org

101–110 of 157 posts

Re: JSON5 Data Interchange Format

#101

Regardless of how good this is or not, every time it pops up I just wonder if anybody actually gives a crap or not. JSON is one of those formats that's "good enough" even if it's stinky and it's also universally accepted that a small iteration on it with small conveniences doesn't make that much sense imho.

And XML is a very battle-tested alternative that supports every conceivable edge case and arbitrary depths of strictness and validation. There was soooo much energy poured in to making XML the One Format To Rule Them All. It has so many advanced features like strict definitions, includes syntax, support for mixed content, entities and references, comment syntax. But it turns out that 99% of users never needed any of that and just wanted nested key-value pairs.

Re: JSON5 Data Interchange Format

#102

These days, JS has moved on while JSON has remained stuck in the past. There are some fairly important ones it'd be great to get a standard format for in JSON. e.g. JSON.stringify({z: 1n}) Also, round tripping ArrayBuffers, Maps, Sets, Symbols and Dates would be really useful. Sadly JSON5 doesn't address those. I'd quite like a next gen JSON not to get upset on circular references too, although that would most likely…

Bigints, dates, and buffers I can understand to a degree.

Sets can easily be serialized as a json array. Maps can be serialized as a json array of arrays or as a single json dictionary if the key types are compatible.

Re: JSON5 Data Interchange Format

#103

Earlier quoted context omitted.

Not sure human-readability was a major consideration of JSON really, but maybe. One of the major considerations that many seem to miss today though was simplicity of parsing: it's a much more strict syntax than actual JS so there's a lot less ambiguity in parsing it. E.g. there's no need to have layered logic for recognizing unquoted identifiers, no need to check for multiple quote types on IDs & strings, consistent…

Agreed. Every single feature here complicates parsing, and the only two that are worth it IMO are comments and multi-line strings (though I'm sure others disagree on which ones are most important, which is how we end up with something like this)

Comments maybe. Multi-line strings though I don't really see as very valuable.

Lack of multi-line strings in JS was a very large, but infrequent pain for years before it was added. That infrequency tends toward zero for JSON: most of it is generated, and even when it is hand-authored, long strings are very much an exception in those cases (in my experience).

Re: JSON5 Data Interchange Format

#104

Regardless of how good this is or not, every time it pops up I just wonder if anybody actually gives a crap or not. JSON is one of those formats that's "good enough" even if it's stinky and it's also universally accepted that a small iteration on it with small conveniences doesn't make that much sense imho.

JSON is "good enough" for a textual, mostly human readable data interchange format. But as a configuration format, for example the package.json file for node/npm/yarn, it is most definitely not "good enough". For two reasons: no comments and no multiline strings. The latter might not be important for some types of configuration, but it is for things that need something like a description that is more than a single sentence.

Re: JSON5 Data Interchange Format

#105
post #29
post #11

Earlier quoted context omitted.

Because: ‘I am “really” angry’ Is much nicer than: “I am \”really\” angry”

Json is not meant to be human readable or writeable.

I've worked on 4+ years of technology that was entirely based on humans hand-tweaking, editing, and updating JSON configs. My text editors validate it quickly, and know how to fold, sort, prettify. Based on my experience (and editing it all day long) It's a very human readable and editable configuration.

Re: JSON5 Data Interchange Format

#106

Regardless of how good this is or not, every time it pops up I just wonder if anybody actually gives a crap or not. JSON is one of those formats that's "good enough" even if it's stinky and it's also universally accepted that a small iteration on it with small conveniences doesn't make that much sense imho.

It is just that people keep insisting on using JSON for human-maintained configuration files, and JSON sucks for that: no comments, trailing commas, or multi-line strings.

Since JSON5 is trivially pre-processed into JSON, it tends to be useful as a tack-on to such projects to let your startup scripts generate the real file given the useful on without having unrelated syntax.

Re: JSON5 Data Interchange Format

#107
post #91
post #52

Earlier quoted context omitted.

> What's the point? Some code bases use single quotes, and it's annoying to copy/paste an object from that code into a JSON objdct and have to change the quotes.

prettier solved that

Prettier doesn't work in Postman or any other non-text editor that I might be using.

Re: JSON5 Data Interchange Format

#109
post #106

Regardless of how good this is or not, every time it pops up I just wonder if anybody actually gives a crap or not. JSON is one of those formats that's "good enough" even if it's stinky and it's also universally accepted that a small iteration on it with small conveniences doesn't make that much sense imho.

It is just that people keep insisting on using JSON for human-maintained configuration files, and JSON sucks for that: no comments, trailing commas, or multi-line strings. Since JSON5 is trivially pre-processed into JSON, it tends to be useful as a tack-on to such projects to let your startup scripts generate the real file given the useful on without having unrelated syntax.

In practice, I've found most program configs allow comments and non quoted keys, for what it's worth.

Re: JSON5 Data Interchange Format

#110
post #59

Earlier quoted context omitted.

Maybe they don't think it should be up to them to decide which one you should go with.

What's the point of standards then?

The standard says you can use either. Why do you disagree with the standard?
Post reply on HN