JSON5
Personally, I appreciate this idea. That's exactly how JSON should work. Sometimes I feel bad with current JSON specs: no comment, no trailing commas, double quotes, etc.
, Dong
My concern with single-lined comments is that json is often whitespace removed.
-Ryan Birmingham
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20170711/513d26ae/attachment
I believe that that's a reasonable solution, Sebastian.
-Ryan Birmingham
On Mon, Jul 10, 2017 at 10:04 PM, Ryan Birmingham <rainventions at gmail.com>
wrote:
My concern with single-lined comments is that json is often whitespace removed.
-Ryan Birmingham
On 11 July 2017 at 00:48, Dong Nguyen <ndaidong at gmail.com> wrote:
Personally, I appreciate this idea. That's exactly how JSON should work. Sometimes I feel bad with current JSON specs: no comment, no trailing commas, double quotes, etc.
their quoted line continuations kinda bother me too... they say just escape the end... but then that's \ \r \n -or- just \ \n and if the \r is just a whitespace it should silently be ignored or something anyway....
but ya, I can see single line comments being an issue depending on the parser too.
Seems like whitespace stripping is more of a serialization concern... and hence comments are moot.
Where comments are needed (and single line ones are handy) is human edited JSON and also not likely to be stripped.
Just my $2e-02
Best, Don
Don Griffin Sr Director of Engineering Sencha, Inc. www.sencha.com
JSON already has comments:
{
"foo": "the 'foo' field is for putting important stuff!",
"foo": "the real value for 'foo'"
}
@Jordan: I think that's just work-around, not official feature.
Dong
any significant degradation in json parsing-performance would impact the world wide web. can anyone knowledgeable on js engines comment on parsing performance?
On Tue, Jul 11, 2017 at 3:48 AM, kai zhu <kaizhu256 at gmail.com> wrote:
any significant degradation in json parsing-performance would impact the world wide web. can anyone knowledgeable on js engines comment on parsing performance?
I wouldn't expect to replace JSON.xxx but rather add JSON5.xxx for those that require absolute speed over maintainability/flexibility.
that said...
it's based on crockford's original
douglascrockford/JSON-js/blob/master/json_parse.js
and comparting with json5/json5/blob/master/lib/json5.js
it's essentialy the same (err maybe not; a diff shows lots of diff)
I found some test data.... RichardHightower/json-parsers-benchmark in data there's a handful of JSON files; I loaded these all into an array of strings and data.forEach( data=><JSON0/JSON5/JSON(node
native)>.parse(data ) );
50 iterations took
JSON(crockford ref): 2971ms JSON5: 4688ms JSON: 644ms
63.37% the speed of crockford refernce code (not quite half the speed) 13.7% the speed of Node's native JSON.parse(). -or- 1.57 times slower than crockford reference code. 7.32 times as slow as JSON.parse()
my own native code parser addon was about 1/2 as fast as node's, so I didn't flesh mine out to a great extent; but the modifications required to go from supporting no-quotes, single-or double quotes, comments, line continuation, Infinity/NaN values really shouldn't slow it down that much; (mine dies on the test data; so that's a thing for another day; and will be hard to tell JSON vs JSON5 because It won't do JSON only anymore (maybe) ).
Appreciate the benchmarks. 57% slower than reference javascript-implementation is iffy. Would still prefer comment from v8 / spidermonkey / chakra / etc implementers. A concern would be if 20-100mb json data that currently parses natively fine in browsers might cause UX-freezing issues due to extra parsing overhead. And again people rely on json in I/O protocols for its fast serialization / deserialization.
I’m against having separate JSON.xxx and JSON5.xxx extensions. 2 different json formats will lead to alot of confusion (like the current .js .mjs mess). Frankly, I just use regular js files when I need commented json data, e.g.:
// data.js file
module.exports = {
// comments
foo: “bar"
};
Its not sexy, but its maintainable code 2 years down the road, without extra tools and libraries.
For huge JSON/JSON5 files, I propose to add streaming support, with chunk per chunk parsing, and have a configurable size limit somewhere.
Claude Petit
From: kai zhu [mailto:kaizhu256 at gmail.com] Sent: Tuesday, July 11, 2017 9:05 AM To: J Decker <d3ck0r at gmail.com>
Cc: es-discuss <es-discuss at mozilla.org>
Subject: Re: JSON5
Appreciate the benchmarks. 57% slower than reference javascript-implementation is iffy. Would still prefer comment from v8 / spidermonkey / chakra / etc implementers. A concern would be if 20-100mb json data that currently parses natively fine in browsers might cause UX-freezing issues due to extra parsing overhead. And again people rely on json in I/O protocols for its fast serialization / deserialization.
I’m against having separate JSON.xxx and JSON5.xxx extensions. 2 different json formats will lead to alot of confusion (like the current .js .mjs mess). Frankly, I just use regular js files when I need commented json data, e.g.:
// data.js file
module.exports = {
// comments
foo: “bar"
};
Its not sexy, but its maintainable code 2 years down the road, without extra tools and libraries.
On Jul 11, 2017, at 7:37 PM, J Decker <d3ck0r at gmail.com <mailto:d3ck0r at gmail.com> > wrote:
On Tue, Jul 11, 2017 at 3:48 AM, kai zhu <kaizhu256 at gmail.com <mailto:kaizhu256 at gmail.com> > wrote:
any significant degradation in json parsing-performance would impact the world wide web. can anyone knowledgeable on js engines comment on parsing performance?
I wouldn't expect to replace JSON.xxx but rather add JSON5.xxx for those that require absolute speed over maintainability/flexibility.
that said...
it's based on crockford's original
douglascrockford/JSON-js/blob/master/json_parse.js
and comparting with
json5/json5/blob/master/lib/json5.js
it's essentialy the same (err maybe not; a diff shows lots of diff)
I found some test data....
RichardHightower/json-parsers-benchmark
in data there's a handful of JSON files; I loaded these all into an array of strings and data.forEach( data=><JSON0/JSON5/JSON(node native)>.parse(data ) );
50 iterations took
JSON(crockford ref): 2971ms
JSON5: 4688ms
JSON: 644ms
63.37% the speed of crockford refernce code (not quite half the speed)
13.7% the speed of Node's native JSON.parse().
-or-
1.57 times slower than crockford reference code.
7.32 times as slow as JSON.parse()
my own native code parser addon was about 1/2 as fast as node's, so I didn't flesh mine out to a great extent; but the modifications required to go from supporting no-quotes, single-or double quotes, comments, line continuation, Infinity/NaN values really shouldn't slow it down that much; (mine dies on the test data; so that's a thing for another day; and will be hard to tell JSON vs JSON5 because It won't do JSON only anymore (maybe) ).
On Jul 11, 2017 15:39, "Dong Nguyen" <ndaidong at gmail.com <mailto:ndaidong at gmail.com> > wrote:
@Jordan: I think that's just work-around, not official feature.
Dong
On Tue, Jul 11, 2017 at 12:31 PM, Jordan Harband <ljharb at gmail.com <mailto:ljharb at gmail.com> > wrote:
JSON already has comments:
{
"foo": "the 'foo' field is for putting important stuff!",
"foo": "the real value for 'foo'"
}
On Mon, Jul 10, 2017 at 10:16 PM, Don Griffin <don at sencha.com <mailto:don at sencha.com> > wrote:
Seems like whitespace stripping is more of a serialization concern... and hence comments are moot.
Where comments are needed (and single line ones are handy) is human edited JSON and also not likely to be stripped.
Just my $2e-02
Best,
Don
--
Don Griffin
Sr Director of Engineering
Sencha, Inc.
On Tue, Jul 11, 2017 at 12:13 AM, Ryan Birmingham <rainventions at gmail.com <mailto:rainventions at gmail.com> > wrote:
I believe that that's a reasonable solution, Sebastian.
-Ryan Birmingham
On 11 July 2017 at 01:12, Sebastian Malton <sebastian at malton.name <mailto:sebastian at malton.name> > wrote:
If that is a concern then allow C-style block comments or some other style of block comments
Sebastian
From: rainventions at gmail.com <mailto:rainventions at gmail.com>
Sent: July 11, 2017 1:04 AM
To: ndaidong at gmail.com <mailto:ndaidong at gmail.com>
Cc: es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
Subject: Re: JSON5
My concern with single-lined comments is that json is often whitespace removed.
-Ryan Birmingham
On 11 July 2017 at 00:48, Dong Nguyen <ndaidong at gmail.com <mailto:ndaidong at gmail.com> > wrote:
Personally, I appreciate this idea. That's exactly how JSON should work. Sometimes I feel bad with current JSON specs: no comment, no trailing commas, double quotes, etc.
,
Dong
On Tue, Jul 11, 2017 at 11:14 AM, J Decker <d3ck0r at gmail.com <mailto:d3ck0r at gmail.com> > wrote:
Since JSON is apparently part of the standard now, can JSON5 maybe be considered for addition? It's a very slight change, and simplifies conversions.
Why does JSON have quoted field names anyway (which I could understand if they included spaced).
I searched archives and only came up with this result....
json5/json5/blob/master/lib/json5.js
(although I would like to see the keyword 'undefined' also allowed as a value) which is just an 8 line addition.
Comments in JSON? Wonderful!
Unquoted field names? Wonderful!
On Tue, Jul 11, 2017 at 12:14 AM, J Decker <d3ck0r at gmail.com> wrote:
Since JSON is apparently part of the standard now, can JSON5 maybe be considered for addition? It's a very slight change, and simplifies conversions.
Why does JSON have quoted field names anyway (which I could understand if they included spaced).
To avoid intersecting the reserved identifier set in languages that wanted to provide a JSON-like syntax for producing values that serialize to JSON.
I searched archives and only came up with this result....
json5/json5/blob/master/lib/json5.js
(although I would like to see the keyword 'undefined' also allowed as a value) which is just an 8 line addition.
Comments in JSON? Wonderful! Unquoted field names? Wonderful!
I think ECMA-404 is the version referenced by the Ecmascript spec. That says in the preamble """ Because it is so simple, it is not expected that the JSON grammar will ever change. This gives JSON, as a foundational notation, tremendous stability. JSON was first presented to the world at the JSON.org website in 2001. JSON stands for JavaScript Object Notation. """ so you might find it tough to convince them, but if you can convince them that JSON needs exactly one more null value and that C++ comments are better than bash comments then updating JSON.parse shouldn't be hard.
You could also go the iETF route and try to obsolete RFC 7159 and then argue to TC39 that ECMA-404 should be dropped in favor of that.
Since people are listing things they'd like to see in the language. I tried to convince Doug Crockford to allow NaN/Infinities in JSON but he's philosophically opposed.
(combined a couple messages...) On Tue, Jul 11, 2017 at 6:12 AM, Mike Samuel <mikesamuel at gmail.com> wrote:
Why does JSON have quoted field names anyway (which I could understand if they included spaced).
To avoid intersecting the reserved identifier set in languages that wanted to provide a JSON-like syntax for producing values that serialize to JSON.
that justification makes no sense; 'serialize to json' kinda voids any keyword argument; although, I vaguely remember a mention that crockford had some single regex expression that could parse json simply, so maybe it's part of that.
(fixed error handling escaped quotes in strings that was causing mine to crash; so throwing in C++ Node Addon....)
delta JSON(c): 2929 delta JSON5: 4632 delta JSON: 683 delta JSON(svfs): 1640 (before JSON5 extension)
delta JSON(c): 2891 delta JSON5: 4581 delta JSON: 647 delta JSON(svfs): 1631 (before JSON5 extension)
delta JSON(c): 2859 delta JSON5: 4483 delta JSON: 642 delta JSON(svfs): 1764 (after JSON5 extension)
delta JSON(c): 2860 delta JSON5: 4536 delta JSON: 641 delta JSON(svfs): 1762 (after JSON5 extension)
native code 2.5x faster than JSON5 and 1.62x faster than crockford reference code.
what's going to be in the browser is going to be more like the Node internal than any of the JS versions or my C++ Node. addon version.
8% loss in mine; separated the test to test just native code, same test is 761ms; so think most of my loss is in the handoff between node and my addon.....
1.57 times slower than crockford reference code. 7.32 times as slow as JSON.parse()
it's obvious(to me anyway) that having a javascript version of either (reference code) or JSON5 is going to be slower than a builtin facility. Even a node Addon isn't really that effective, losing half the time just in interchanging between V8 and the outside world.
On Tue, Jul 11, 2017 at 12:57 PM, J Decker <d3ck0r at gmail.com> wrote:
(combined a couple messages...) On Tue, Jul 11, 2017 at 6:12 AM, Mike Samuel <mikesamuel at gmail.com> wrote:
Why does JSON have quoted field names anyway (which I could understand if they included spaced).
To avoid intersecting the reserved identifier set in languages that wanted to provide a JSON-like syntax for producing values that serialize to JSON.
that justification makes no sense; 'serialize to json' kinda voids any
I don't know that (serialize to json) does void that argument, but if you're using a function to serialize to JSON and gzipping message bodies, then unquoted keys offer no benefit.
One concern was that JSON was meant as a glue for networked systems, so to get adoption it should look familiar and also have consistent semantics to novice programmers trying to glue frontends and backends together.
Avoiding reserved keywords is one problem, but there are others in this vein.
Consider a novice programmer trying to glue together a Python backend and a JavaScript frontend. If you train novices by example to omit quotes then they will run into semantic differences between a = "b" myJson = { a: "v" } in those two languages, prompting them to give up and use XML.
keyword argument; although, I vaguely remember a mention that crockford had some single regex expression that could parse json simply, so maybe it's part of that.
Crockford did have such a regex. It is in section 6 of tools.ietf.org/html/rfc4627 """ This can be quickly determined in JavaScript with two regular expressions and calls to the test and replace methods.
var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
eval('(' + text + ')');
"""
That claim is suspect. It worked around an earlier claim which was bypassd. blog.mindedsecurity.com/2011/08/ye-olde-crockford-json-regexp-is.html by
+{ "valueOf": self["location"],
"toString": []["join"],
0: "javascript:alert(1)",
length: 1
}
Since JSON is apparently part of the standard now, can JSON5 maybe be considered for addition? It's a very slight change, and simplifies conversions.
Why does JSON have quoted field names anyway (which I could understand if they included spaced).
I searched archives and only came up with this result....
esdiscuss/2012-August/024479
json5/json5
json5/json5/blob/master/lib/json5.js
(although I would like to see the keyword 'undefined' also allowed as a value) which is just an 8 line addition.
Comments in JSON? Wonderful! Unquoted field names? Wonderful!