Submitted for your approval, JSOX

Felipe Nascimento de Moura felipenmoura at
Tue Sep 18 22:52:44 UTC 2018

I agree with that.
I too feel JSON could have an upgrade!
For instance, I almost always use JSON5 ( transpilation
in any project I have to deal with JSON files.

[ ]s


*Felipe N. Moura*
Web Developer, Google Developer Expert
<>, Founder of
BrazilJS <> and Nasc <>.

Website: /
Twitter:    @felipenmoura <>
*Changing  the  world*  is the least I expect from  myself!

On Tue, Sep 18, 2018 at 6:22 PM J Decker <d3ck0r at> wrote:

> (Thank you Rod Sterling)
> But seriously, I'd like to submit, for serious consideration, JSOX -
> JavaScript Object eXchange format.  It inherits all JSON syntax such that
> it is able to process any existing JSON.
> I'm, at this point, open to changing anything (or even omitting things),
> including the name.
> JSON is great.  JSON has some limits, and criticisms... JS/ES Grew , but
> JSON has to stay the same, similarly with whatever comes next I'd imagine.
> So a primary goal is to encode and decode ES6 objects for transport with a
> simple API such as JSOX.parse( object ), and JSOX.stringify( jsoxString ).
> But also keep with the simplicity of JSON,
> so it can be used in human readable circumstances.
> Types that are now (or soon) native to ES such as TypedArrays (binary
> data), BigInt types, and even the existing Date type, do not transport with
> JSON very well.  They become a non-identifable string, that requires extra
> code involving knowledge of the structure of the data being transferred to
> be able to restore the values to Date(), BigInt(), et al.
> So a few weeks ago I started considering what else, beyond these simple
> modifications might also be useful, or address criticisms of JSON.
> Handling the above types is really a trivial modification to most JSON
> parsers.  Each of the following modifications is really only a very slight
> change to behavior; although implementing typed-objects does initially
> involve changing error handling into identifer-fallback handling.
> I initially argued, that defining a object prototype
> 'card(name,address,zipcode,created)' which removes the redundant data for
> every following reference, (and is good, just for data reduction, which was
> argued 'gzip').  A JSON representation might be
> `{"name":"bob","address":"123
> street","zipcode":"55555","created":1537304820} where if have a large
> number of the same record the same 'name':,'address':, etc is repeated in
> every record.  Where a typed-object's value in JSOX could be
> `card{:"bob","123 street","55555",2018-09-18T21:07:00Z}`.  All objects that
> are revived as typed-objects share the same prototype, and before parsing,
> the prototypes to be used may be specified.  The amount of data to process
> is reduced, perhaps to a significant degree.
> So <Identifer> '{' is about typed-objects.  This construct is not allowed
> in JSON.  But that then leads to <Identifier> '['  - typed arrays, arrays
> don't really have redundant data potential like objects, but there are
> TypedArrays in ES.  There is no way to define a type of an array, but
> hardcoded types like 'ab', 'u8', 'ref' are used to revive binary data.  The
> bytes of the backing ArrayBuffer are encoded to base64, and included within
> '[' and ']' without quotes; using the brackets as quotes.
> A JSOX typed array is the 'ref' type.  A reference to another location in
> the current object can be specified, which allows encoding cyclic
> structures.
> (Initial public reaction was not very helpful, but probably that's the
> fault of how it was introduced?)
> There was plenty of 'why not [YAML/BSON/protobufs/(I don't think anyone
> said XML)/...]'  and the answer is simply, because none of those read JSON,
> or have as simple of an API. (amongst other reasons that JSON is already a
> solution for compared to those mentioned)
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list