Hacker News Reader

Comment by shirro | Hacker News Reader

This brings barely anything useful to JSON and adds processing overhead. Almost all json is produced and consumed but software not people. Adding trailing commas or single quotes or optional quotes is a waste IMO and adds needless complexity for very little gain. Now if they were introducing some useful new types that would be a different matter.

View on HN

I often use a JSON file containing dummy content when I'm working on a web app, and I manually edit the JSON a lot during development (then, when I've settled on a structure, use the static JSON file as the design for a real API endpoint). Comments and ES5 niceties would be useful for those situations, at least. You could even assign JSON5 to window.JSON in your dev environment only, and still get the performance of real JSON in production.

One other thing to consider is that JSON was meant as a replacement to XML to be more concise and easier to use as well as being generally smaller in payload size. Adding comments, while good for people, is not really what it was developed for. It's really for machine to machine communication and adding human readable stuff like comments and dangling commas muddies the protocol.

Your comment doesn't seem to address what I was saying. I just described a situation where you might use JSON5 in development (so you can put comments etc in your dummy data) and JSON in production (so you get native performance).

Here's how I've solved the use-case you talk about. I built my development files in my own format, and then transformed them to JSON for the wire. In my mind, the hassle this involves is a down-payment I gladly make in order to be able to work with sharp tools.

For your particular scenario, where your file format is similar to json already, it's not a lot of work to parse the file, and remove lines which - when stripped - begin with '#'. That's five minutes' work.

Json is a wire protocol. We had XML before that, but XML tries to compromise between being a wire serialisation format, and lots of other features (e.g. human-editable, file serialisation, schemas).

Crockford's decisions are a picture of minimalism. He wanted to find a way to get a standard wire format, without making any changes to javascript to get it. Json isn't perfect as a wire format, but it remains effective as a balance of those priorities.

The original post says, "JSON's usage has expanded beyond machine-to-machine communication." This is the source of the problem - the author wants to compromise JSON's mission to serve a non-core functions, things that are unrelated to being an available-everywhere wire protocol.

If we do json5, pretty soon someone else will be pointing out that we need to encode json schemas. When we point out that it's a compromise on the mission, they'll say, "that's OK - we've already made the decision to make JSON a general purpose format. Look at the way we added comments, which goes against the mission."

We'll get into hassles with libraries and versions. This is the road to XML. We already have XML, it's a horror to work with, and the reason for that is that it tries to be all things to all people instead of being a sharp tool.

Before XML we had SGML. When XML was young, I was involved with projects that chose it because it was simpler than SGML. XML is now far more complicated than SGML, in different ways of course. Now people overlook XML (it's too damn complicated!) and use json.

Fortunately Crockford seems to have foreseen the problems here, and made hard decisions early (no comments) in order to entrench against a repeat of the pattern.

can't you just do

    _dontcare = {es5: syntax, /*with comments*/}
    data = JSON.stringify(_dontcare)

?

No, because syntax is undefined. Trailing comma and comment is removed when it is stringified.

Yeah, you can do that in your .js source, but not in a separate, non-executed file. It is useful IMHO to separate static data from code. Also, this is useful for configuration files.

It's interesting, the first thing I thought of when looking at this was CSON (https://github.com/bevry/cson) which essentially just provides some syntactic sugar on top of JSON like CoffeeScript to JavaScript. I haven't look at this enough to really see the difference between JSON5 and CSON but at the surface it looks like its just CSON rebranded as JSON5. I agree with you that in general most json is machine generated and in most cases should never be manually created by people. It's a language for machines to talk to machines not machines to people. Granted it's sort of against JSONs philosophy but I also would love to see some more types added to JSON rather than syntactic sugar. There will always be libraries like CSON or CoffeeScript to add sugar, its better to make the base more useful and extendable.

Note that CSON is used in Atom.io, Github's new text editor: https://github.com/atom/language-ruby-on-rails/tree/master/g...

I've used CSON before, main reason being that I wanted a config file with comments plus easy integration with a JS/CS project. YAML also works well.

"most json is machine generated and in most cases should never be manually created by people"

Except when sketching out a static JSON file that you'll eventually implement as a real API connected to a database, once you've experimented and arrived at a good structure. I do this a lot. I wouldn't output JSON5 from a live API, but I would use it for sample data in development.

That's fair. My argument is that you shouldn't muddy the implementation of a protocol for debugging purposes. It creates unnecessary complications that then have to be dealt with on either end in software. I think the problem that you are bringing up is more of a development environment around creating good data structures in JSON rather than a pitfall in the protocol itself.

I'm not saying JSON is perfect just providing a counter argument and stating a general belief I have about over complicating thing when a simple companion tool or something like CSON works just as well. CSON or CoffeeScript are good examples because they provide a more pleasurable environment for the developer but at the end up the day compile down to their native JSON or JavasScript respectively. I think we are in agreement in that I dont like the JSON5 syntax should necessarily be what's going over the wire.

It looks to me like a major difference between this and CSON is that this is safe and CSON is not.

Literally the only difference between coffeescript.eval and cson.parseSync is that the latter runs in a sandbox. You can't screw up so badly as to cause global side effects, and you can't require modules, but that's where the safety ends.

For example

    cson.parseSync("Math.sqrt")(4)

will return 2, and

    cson.parseSync("1 while true")

will cause an infinite loop.

That's very powerful for config files; I'd much rather have my config say "y: Math.sqrt 2" than "y: 1.4142135623730951". But it means that you absolutely must not parse CSON that comes from an untrusted source.

Now obviously JSON5 provides very little over JSON as a data-exchange format. In fact, the only practical advantage I see is that you can use Infinity as a value.

I can see two use cases for this:

1. You have a web service for developers, and you want human-editable config files that can be parsed safely on the server side. CSON won't work there, and JSON5 would be nicer to work with than JSON. It's a good thing that JSON5 is a strict superset of JSON, because this is one hell of rare scenario.

2. You want your exchange format to be more human readable for debugging and testing. This use case isn't realistic, however, so long as JSON5.stringify is aliased to JSON.stringify.

The unsafe eval of objects in CSON seems to be an implementation quirk rathet than a feature. They're working on a static parser.

Check out their WIP https://github.com/bevry/cson/issues/33

That's good. It would be nice if they'd document the spec before doing this. Right now it's pretty unclear what is and isn't valid CSON, since any CoffeeScript code will run.

If anything, trailing commas would actually be nice. It won't complicate parsing, but it does make the automatic generation of JSON much nicer as you no longer have to specially treat the first or last element of an array or object.

The rest of the changes I'm not so keen on.

> it does make the automatic generation of JSON much nicer

Are you generating JSON as freeform text? Because a call to JSON.stringify (or whatever JSON-dumping method exists in your language of choice) would not be "made nicer" by handling trailing commas.

How so?

Because the tool handles generation so you don't give a damn whether the final format uses trailing commas or not? And you can use trailing commas in your source language if that's supported?

Ah, I see. You are assuming a JSON encoder exists for a given language. I'm not.

I have hand written a fair amount of json in the last week including some json schemas and the trailing commas gets me coming from golang literals and back.

I don't mind the idea of alternate syntaxes that compile to json in the spirit of coffeescript or less/sass/haml etc.

Coffeescript makes it very clear that it is just an alternate syntax for javascript. If that is the aim of json5 that is cool. I just don't want to see public APIs producing and consuming json5 in the wild and breaking stuff.

If you're generating JSON with string concatenation instead of using a JSON serializer, you're almost certainly doing something wrong.

My thoughts exactly.

Reply on news.ycombinator.com