javascript vision thing

[Isiah Meadows]

IMHO, I'd like to see four things:

- Native JSON multi-object support
- Binary data support that doesn't require delimiters
- Native JSON property streaming support
- Spec-level binary JSON support

Apart from that, I don't really see anything JSON lacks.

-----

Isiah Meadows
me at isiahmeadows.com
www.isiahmeadows.com

On Tue, Jul 24, 2018 at 12:43 PM, Carsten Bormann <cabo at tzi.org> wrote:
>
> 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
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss