Last week I suggested some modest JSON improvements, and conversation ensued. Obviously, much was “He’s Wrong On The Internet (again)” but lots was juicy and tasty, and worth considering further.
This is based on reaction in my own comments, and on Hacker News.
“Just use X” · For values of X including Hjson, Amazon Ion, edn, Transit, YAML, and TOML.
Nah, most of them are way, way richer than JSON, often with fully-worked-out type systems and Conceptual Tutorials and so on. I just want JSON that’s easier to edit and can do timestamps.
Hmm, SON looks pretty close to what I’m thinking.
Also, I gather that edn simply asserts that commas are whitespace, which smells sort of brilliant to me.
“Comments, please please comments!” ·
Can’t think of a good reason to say no. # or // and/or /* */? Why
use two characters where one would do? I’m thinking #.
“You shouldn’t want to hand-edit JSON” · Yeah, I shouldn’t and actually I don’t. But somehow I keep having to. And it’s a sucky, horrible, experience, but it doesn’t have to be.
“You’ll lose JavaScript compatibility!” ·
Sorry, JSON
already
isn’t a JavaScript subset. Also, you should never use eval()
on JavaScript, the right approach is always JSON.parse() and
JSON.toString() or your language’s equivalent.
“Unquoted field names, please!” · Bah, can’t see the benefit. If I have to look at the value to decide whether to quote it, I’m doing it wrong.
Is it too late? · The only real argument is whether it’s counterproductive, or maybe just too late, to try to prune some JSON irritants. Can’t say as I know. Anyhow, if it were worth doing, I think you could build a consensus around:
Declaring that commas are whitespace,
adding comments (I’d vote for
#but whatever), andadding RFC3339 timestamps — people seemed to like the
@-prefix idea too.
One nice consequence is that all existing JSON would also be the .next version or whatever we call it. Speaking of which, I even picked a catchy name and snagged the domain. So far, not hearing the drumbeat of virtual feet on the virtual street though.
Contributions
Comment feed for ongoing:
From: Grahame Grieve (Project Lead, FHIR) (Aug 25 2016, at 21:37)
Yes please. Like those changes. Lots+++
[link]
From: Don MacAskill (Aug 26 2016, at 00:20)
Please, for the love of God, talk about some sort of binary compatibility or standard encoding of binary or something. :)
[link]
From: Daniel Ly (Aug 26 2016, at 00:21)
Sorry to nitpick but I wonder if you meant RFC 3339?
https://tools.ietf.org/html/rfc3339
[link]
From: Matthew (Aug 26 2016, at 01:15)
Perhaps it could become as popular as XML 1.1.
[link]
From: Luci (Aug 26 2016, at 01:46)
Commas being whitespace is taken directly from Clojure, where it does indeed work very well. Most code never uses them, except for cases where it would help readability (just like whitespace).
I have similar gripes with JSON as yourself and none of the suggested alternatives seem good enough.
I really would like a reasonable schema system and ideally also a binary serialisation based on given schemas.
[link]
From: Vinny Fonseca (Aug 26 2016, at 04:05)
Hi Tim,
Good ideas and a good start for this conversation. I deal with JSON day in day out and it really needs some fixes.
In my opinion:
- the key should always be unquoted and allow single words only in a key/value pair
- the comment syntax should be // and /* */ for block comments, instead of #, as JSON is still closely associated with JS
Other than that, I agree with JSON.parse and JSON.toString usage at the application level, the timestamps implementation and commas as whitespace.
[link]
From: Carlos Fernández (Aug 26 2016, at 05:04)
Those ones are good approaches, but shouldn't be 'fixes'.
The problem here is that people have been using JSON the way they shouldn't, and the way JSON should be used doesn't need spaces instead of commas, comments and so. (The @date approach would be nice, maybe, not sure).
If you want something that looks somehow like JSON but have different syntax and objective, don't call it JSON\JSON.next, just use another name, because it's a different thing.
[link]
From: StanD. (Aug 26 2016, at 11:38)
I still think edn is the solution. In addition to treating commas as whitespace it also
* Dispenses with the colon between keys and values (it's not whitespace though)
* Has single character comments (the semi-colon)
* Has keywords (:key, for example) which can be used as keys. Easier to type than double-quotes.
* Supports dates via reader literals (#inst "2012-03-22T10:20:00Z" is a date)
The reader literal system is extensible if you want (#UUID "[uuid string]" is also built in, for example) but parsers can just treat them as strings as a fallback.
[link]
From: Bob Foster (Aug 26 2016, at 17:43)
# for comments? You want to make whitespace significant? Good grief.
[link]
From: Jesse Wilson (Aug 27 2016, at 05:55)
I’d love it if a revised JSON spec made a general recommendation on the case format of names. It’s sad when an integration breaks because the client sent `full_name` when the server expected `fullName`. Even a weak endorsement of a specific scheme could help to reduce the number of dialects we need to use.
[link]