javascript vision thing

[Carsten Bormann]

On Jul 24, 2018, at 18:29, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
> 
> On 2018-07-24 17:09, Carsten Bormann wrote:
>> 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,
>> 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.
> 
> Serializing BigInt as JSON Number is the solution then?

For applications that make good use of BigInt, I would say so.
So you wouldn’t use JSON.parse, but a new interface that preserves integers beyond 2**53 as BigInt (or possibly even all integers; I don’t want to design this on a napkin)

> There are a few argument against that:
> 
> - This would typically require low-level parsers to always rely on a BigNumber type.  Oracle's JSON-B does exactly that.  Currently there is no BigNumber type in JS or .NET.

There is no need for the above interface to handle floating point numbers (NR2/NR3).

> - There is quite a bunch of IETF standards defining JSON structures. As far as I know none of them exploit JSON outside of its original, JS-induced limitations.

Maybe the IETF was smart enough to stay in the confines of I-JSON…

But really, JSON never had that particular limitation.  A JSON-based ecosystem that wants to enable the use of JavaScript JSON.parse does, as Twitter found out when they were sending their perfectly valid JSON to JavaScript applications.

> - Although BigInt is a very welcome addition to JS, usages are few and typically confined to specific things like crypto or money.  Creating backward incompatibility for that is IMO counterproductive.

Right, so maybe the motivation for touching JSON really isn’t that massive.

> - Serializing BigInts as a string does not break anything.

After JSON.parse, they are text strings then, not BigInts.
Generally, there is the expectation that, for an interesting set of x, JSON.parse(JSON.stringify(x)) == x
Hence the exception when you pass BigInt to JSON.stringify today.

>>> Personally I think the JSON WG should be rebooted but apparently I’m rather alone with that idea.
>> Indeed.
> 
> That might be the case but it doesn’t solve the problem.

It also doesn’t create the problem of damaging JSON by instability.

>> 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 seems to work well in spite of not being brilliant.

Right.  As do bicycles.  Until you need to transport a sofa or cross the Atlantic.
JSON is the right tool for a large number of jobs.

> Yes, CBOR is great https://tools.ietf.org/html/rfc7049 :-)

Can’t disagree here :-)

Grüße, Carsten