javascript vision thing

Carsten Bormann cabo at tzi.org
Tue Jul 24 15:09:37 UTC 2018


On Jul 24, 2018, at 16:31, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
> 
> JSON isn’t really a topic for tc39 only but since the IETF consider JSON "done", an open question is where possible future developments should take place,

What is the best place where I should beat my wife?
No, that is not the question.

> including dealing with new data types like BigInt.

That, indeed, is a question for JavaScript.  It has nothing to do with “developing” JSON; JSON can already represent BigInt just fine.

> Personally I think the JSON WG should be rebooted but apparently I’m rather alone with that idea.

Indeed.

Frankly, JSON, together with the JavaScript-induced limitations in its ecosystem as documented in RFC 7493, is not a very brilliant data interchange format.  It is popular because it is extremely simple (at least on the surface), it is already familiar to users of most dynamic programming languages, and it hasn’t changed since 2002.  “Changing” JSON simply means no longer having JSON.

(And there are quite a few much better data interchange formats; maybe JavaScript can start to support some of them out of the box.)

> Obvious extensions include comments and dropping the "" requirement on keys that are JS compliant.

*Shudder*.   These are *not* needed for data interchange.  For configuration files and other data input by humans, DO NOT USE JSON.  If you need YAML(*) (which also has been fully stable for more than a decade, by the way), you know where to find it.  YAML also *is* the extended JSON that so many people are wishing for.

Grüße, Carsten

(*) and of course YAML supports graphs, binary (byte string) data, human-friendly input, etc.  It is approximately what any other effort to “humanize” JSON and fill in its shortcomings will arrive at eventually, just with some microdecisions you and I may not like but that are not relevant in the big picture.



More information about the es-discuss mailing list