JSON5: modern JSON

[Aseem Kishore]

I love JSON, but writing it by hand has always been a pain.

Needing to (double-)quote keys, not being able to document the data with comments, and not having support for trailing commas or multi-line strings -- all of which are available and work perfectly well on modern ES5 engines, including Node.

After stewing on this for over a year, I bit the bullet today and made this idea a reality: a "JSON5" parser that supports these and other ES5 features in JSON.

https://github.com/aseemk/json5

It's built off of Douglas Crockford's own eval()-free JSON parser, and it's available now on npm as "json5".

I'd love to get your guys' thoughts and feedback on this. And it'd be a dream if package.json files could be written in this looser syntax one day. =)

Cheers,

Aseem

[Alan Hoffmeister]

Awesome idea!

Not sure about allowing commas on the last object / key but all the rest are good to go!

--
Att,
Alan Hoffmeister

2012/5/27 Aseem Kishore <aseem....@gmail.com>

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Axel Kittenberger]

Oh great! <3 I really looked for this a few weeks back!

see: http://stackoverflow.com/questions/9637517/parsing-relaxed-json-without-eval

[Vitaly Puzrin]

Why not to just use YAML :) ?

понедельник, 28 мая 2012 г., 6:32:23 UTC+4 пользователь Aseem Kishore написал:

[Aseem Kishore]

Great question. I actually didn't know until after I published this that YAML is a superset of JSON. Other than that, I didn't really consider YAML only because it doesn't seem to have very good uptake in JS-land.

Looking at it a bit now, though, I think there might be some value in incremental improvements to JSON, where the syntax is still valid JavaScript, rather than a different and much larger syntax.

Aseem

[Nuno Job]

While I appreciate your work I would like to ask if you think the advantages of these additions are enough to justify:

1) The added complexity

2) Changing the semantics of something already completely defined and with a very large tools ecosystems around it.

In other words, markups are cool but maybe this is not JSON? :) Funny that someone said it might be YAML (yet another markup language) :)

Anyway, kudos on great OSS work!

Nuno

[Angel Java Lopez]

Well, I see a value: compatibility with eval.

That should be the key for this project: it's not "another markup language". It's plain Javascript (wo/need eval)

Initially, I had the idea to suggest:

{

   mypage = 'loret

     ipsum...

    ...

   ....'

}

that is, multiline string, where the end of line (without \ at end) were preserved when loaded. But then I realized that feature would break eval semantic

[Aseem Kishore]

Definitely guys -- thanks for the feedback and for the discussion.

Chicken-and-egg problems are always hard. As an attempt to make JSON5 more feasible, I've purposefully made stringify() output regular (strict) JSON.

So existing tools could continue to write regular JSON; it's just my hope that for cases where JSON needs to be written or edited by hand, tools be flexible in reading JSON.

And yes, I thought a great guiding principle was to continue to be valid JS.

Aseem

[Arunoda Susiripala]

I like this.

Definitely I'll use this in my config file.

Hope nconf would add this into the core :)

Arunoda Susiripala

@arunoda

https://github.com/arunoda

http://www.linkedin.com/in/arunoda

[jason.桂林]

Like it.

2012/5/28 Arunoda Susiripala <arunoda.s...@gmail.com>

--
Best regards,

桂林 (Gui Lin)

guileen@twitter

桂糊涂@weibo

guileen@github

[Vitaly Puzrin]

I'd like like to separate 2 questions. Your work is great, and json really worth to be improved. For example, it's convenient, when
you need to keep things simple (for very small files), or keep speed very fast.

The second question, about bad yaml uptake, is ralated to lack of good libraries for node.js. Just because project is still young.
Some libs are quite complicated, and takes a lot of time to do. But we did pyyaml port, and you can play with it here
 https://github.com/nodeca/js-yaml (there is online demo). I can bet, that once you start use yaml, you will newer wish to return back :)

понедельник, 28 мая 2012 г., 18:13:40 UTC+4 пользователь Aseem Kishore написал:

Great question. I actually didn't know until after I published this that YAML is a superset of JSON. Other than that, I didn't really consider YAML only because it doesn't seem to have very good uptake in JS-land.

Looking at it a bit now, though, I think there might be some value in incremental improvements to JSON, where the syntax is still valid JavaScript, rather than a different and much larger syntax.

Aseem

[Alexey Petrushin]

There's also CSON https://github.com/bevry/cson - with very compact CoffeeScript syntax

[Matt]

The problem with YAML is it's a horrendously bloated spec, making it super complex to write a correct parser (unless you shim a C library). It started off as a really simple idea but then Ingy went a bit off the rails with things it could do, and the spec ended up about 10 times longer than the XML spec. Personally I don't like complex formats.

Matt.

[Axel Kittenberger]

On Mon, May 28, 2012 at 7:28 PM, Matt <hel...@gmail.com> wrote:
> The problem with YAML is it's a horrendously bloated spec, making it super
> complex to write a correct parser (unless you shim a C library). It started
> off as a really simple idea but then Ingy went a bit off the rails with
> things it could do, and the spec ended up about 10 times longer than the XML
> spec. Personally I don't like complex formats.

Doesn't it sound familiar? (JavaScript ;-)

[Karl Tiedt]

How is javascript in any way similar to XML or any other markup
language.... thats like apple to beef comparisons.... (not oranges
because they are that different)

-Karl Tiedt

[Matt]

Not even slightly.

I've programmed in a lot of languages, and JS is definitely one of the least bloated I've ever used.

But anyway this is drifting off topic - JSON5 does indeed look useful.

Matt.

[Vitaly Puzrin]

Who cares about difficulty of writing parser, if it already exists for node? Who makes you use every yaml feature? Yaml is widely used in ruby/python. And i'm not sure, that it would be clever idea to invent another way for node. Every time i look into package.json, i remember about dying kittens.

понедельник, 28 мая 2012 г., 21:28:07 UTC+4 пользователь Matt Sergeant написал:

The problem with YAML is it's a horrendously bloated spec, making it super complex to write a correct parser (unless you shim a C library). It started off as a really simple idea but then Ingy went a bit off the rails with things it could do, and the spec ended up about 10 times longer than the XML spec. Personally I don't like complex formats.

Matt.

[Matt]

On Mon, May 28, 2012 at 3:29 PM, Vitaly Puzrin <vit...@rcdesign.ru> wrote:

Who cares about difficulty of writing parser, if it already exists for node?

I do just from a personal sense of smug satisfaction :-) I don't like complicated solutions.

 

Who makes you use every yaml feature?

The same argument gets used for Perl, but I still used to see people putting & in front of &function() &calls() when I coded Perl (among other horrible warts in the language being used every day). Sadly it's never just about you - it's about everyone around you.

(OK I swear I'll stop now - I still like the look of JSON5)

Matt.

[jason.桂林]

I hope JSON can support Date type serialization, but it not, now I hope JSON5 can do this Date serialization.

2012/5/29 Vitaly Puzrin <vit...@rcdesign.ru>

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Arunoda Susiripala]

Why do you need serialization for Date.

Just save the timestamp.

[Aseem Kishore]

Someone else made the same request:

https://github.com/aseemk/json5/issues/3

It seems that the right thing to do is what native JSON already does (at least in V8) -- serialize to an ISO 8601 string. Let me know if that's not right.

Aseem

[Dick Hardt]

On May 28, 2012, at 6:35 PM, Arunoda Susiripala wrote:

> Why do you need serialization for Date.
> Just save the timestamp.

Easier to hand edit which was one of the goals of this project.

[Dominic Tarr]

eval isn't evil, but it has potential for evil. using eval in for
configuration files is not bad, because you know what they contain,
after all, you are editing them by hand.

if you are sending JSON5 or eval'd js remotely that is probably a bad idea.

[Evgeny Bogdanov]

Thanks for it. Will start using it. Seems cool to me!

Concerning discussion about yaml. I've been using some configurations with ruby.

When started with node, changed to json because of its simplicity and direct mapping to JS,

less mental mappings for me. Maybe will change my mind in the future, but for now json works ok.

With json5 it'll be close to perfect.

[Oliver Leics]

On Tue, May 29, 2012 at 9:32 AM, Dominic Tarr <domini...@gmail.com> wrote:
> eval isn't evil, but it has potential for evil. using eval in for
> configuration files is not bad, because you know what they contain,
> after all, you are editing them by hand.

If you ever release a package to npm that makes that assumption, then
cross fingers and hope that nobody will ever write something from
users into the configuration files without validation. To cross
fingers is not reliable ;-)

[Marco Rogers]

FYI, not related to JSON5, but a nice simple solution for reviving dates that were serialized as ISO 8601.

https://gist.github.com/2504336#gistcomment-281565

:Marco

[Aseem Kishore]

Very cool and useful, thanks!

FWIW, since JSON5 is built off of Douglas Crockford's json_parse.js, its parse() function also supports a reviver argument -- so this'll work w/ JSON5 too. =)

Aseem

--

[Matt]

On Wed, Jun 13, 2012 at 4:46 PM, trans <tran...@gmail.com> wrote:

Well, the later statement isn't really true. YAML is certainly more complex than JSON. And that's b/c it 1) caters to human readability and editability and 2) is a full serialization format. But it's not more complex than XML by any means.

YAML Spec: http://www.yaml.org/spec/1.2/spec.html - 89 Pages.

XML Spec: http://www.w3.org/TR/REC-xml/ - 36 Pages.

You were saying?

[Oleg Efimov (Sannis)]

As I know, XML spec does not describe single format for arrays/maps representation. There is more other things in YAML that odes not exist in XML.

Especially for human-readable configs YAML looks pretty good.

четверг, 14 июня 2012 г., 4:38:55 UTC+4 пользователь Matt Sergeant написал:

[Dominic Tarr]

if you really need a comment in JSON you can usually just use a ignored field:

{
"REM": "ugly, but this will be ignored",
"name": "modulename"
}

pays to have glanced at, or written the thing that reads this though.

[Alexey Petrushin]

> If you really need a comment in JSON you can usually just use a ignored field: 

Except if You iterate over it ;)

[Dominic Tarr]

that is what I meant by "usually"

[Samuel Paul]

Hi Aseem,

Is it possible to get the parsed tree of the json object having location information(line and character) for each property, value, comment,etc?

Thanks

Sam

[Felipe Gasper]

I’m not wild about the unquoted keys: too many exceptions to the rule.
(Are hard spaces allowed? etc.)

Also not a fan of single quotes. I don’t see what purpose that serves,
unless the format is to use them exclusively in lieu of double-quotes ..
which, for most of us, would indeed be easier to type.

IMO JSON should simply allow comments (// or /**/) and trailing commas.
These are SORELY needed in JSON for it to be really human-friendly.
Perl’s JSON::XS adds EOL comment support but using # instead of //. (wtf?!?)

-F

On 11.3.14, 7:38 AM, Samuel Paul wrote:
> Hi Aseem,
> Is it possible to get the parsed tree of the json object having location
> information(line and character) for each property, value, comment,etc?
>
> Thanks
> Sam
>
> On Monday, 28 May 2012 08:02:23 UTC+5:30, Aseem Kishore wrote:
>
> I love JSON, but writing it by hand has always been a pain.
>
> Needing to (double-)quote keys, not being able to document the data
> with comments, and not having support for trailing commas or
> multi-line strings -- all of which are available and work perfectly
> well on modern ES5 engines, including Node.
>
> After stewing on this for over a year, I bit the bullet today and
> made this idea a reality: a "JSON5" parser that supports these and
> other ES5 features in JSON.
>

> https://github.com/aseemk/json5 <https://github.com/aseemk/json5>

>
> It's built off of Douglas Crockford's own eval()-free JSON parser,
> and it's available now on npm as "json5".
>
> I'd love to get your guys' thoughts and feedback on this. And it'd
> be a dream if package.json files could be written in this looser
> syntax one day. =)
>
> Cheers,
> Aseem
>

> --

> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

> ---

> You received this message because you are subscribed to the Google
> Groups "nodejs" group.

> To unsubscribe from this group and stop receiving emails from it, send
> an email to nodejs+un...@googlegroups.com
> <mailto:nodejs+un...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Ryan Dahl]

https://github.com/aseemk/json5

I love this idea!

I'm not sold on the name though. I imagine there will be a need to use a different filename extension to distinguish it from JSON and .json5 is annoying long for a filename extension. What about calling it "javascript object" instead and using .jso?

[Berger Kennedy FOTSO]

OHOHOHOH

--

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "nodejs" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.

[Eric Devine]

Calling it a "javascript object" implies that a function should be a valid property type. However, this provides an interesting use case for the Function constructor since it allows the creation of functions without a closure context. Of course, this would severely limit the interoperability with other backends and open up a whole can of eval worms...

[Ryan Dahl]

On Tue, Mar 11, 2014 at 1:43 PM, Eric Devine <devi...@gmail.com> wrote:

Calling it a "javascript object" implies that a function should be a valid property type. However, this provides an interesting use case for the Function constructor since it allows the creation of functions without a closure context. Of course, this would severely limit the interoperability with other backends and open up a whole can of eval worms...

It's just a name - squint your eyes. I'm not suggesting to allow functions...

[Alex Kocharin]

 

Yes:

http://rlidwka.github.io/jju/tokenizer.html

 

 

Don't be confused with json on the demo, it's full-featured json5 parser underneath (https://github.com/rlidwka/jju#jjutokenize-function).

 

 

 

11.03.2014, 16:38, "Samuel Paul" <samue...@gmail.com>:

--

[Alex Kocharin]

11.03.2014, 18:55, "Felipe Gasper" <fel...@felipegasper.com>:

> I’m not wild about the unquoted keys: too many exceptions to the rule.
> (Are hard spaces allowed? etc.)

See ES5 spec. For example, hard spaces are not allowed because they are not unicode letters.

> Also not a fan of single quotes. I don’t see what purpose that serves,
> unless the format is to use them exclusively in lieu of double-quotes ..
> which, for most of us, would indeed be easier to type.

Single quotes are used to avoid escaping of double quotes and vice versa.

> IMO JSON should simply allow comments (// or /**/) and trailing commas.
> These are SORELY needed in JSON for it to be really human-friendly.

Nope. Guess what, JSON5 isn't human-friendly enough as is, and there are already some thoughts about JSON6 with template strings. :)

> Perl’s JSON::XS adds EOL comment support but using # instead of //. (wtf?!?)
>

> To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.