Hacker News Reader

Comment by enneff | Hacker News Reader

JSON is wonderful because it is simple and unambiguous. It just works, and serialized data will always look the same.

This "JSON5" thing is an abomination. Use whatever quotes you like! More string escaping rules! Adding these things would make JSON worse, not better.

Here's another idea: why not write a tool that tidies up your hand-written JSON files? You could even re-use your "JSON5" parser to do it. That way you can be as lazy as you like when writing files, but not expect the rest of the world to learn your new dialect.

View on HN

Thanks for the feedback. It certainly would be great if there existed tools to let me write and update JSON with nicer syntax like this; any ideas how that might be possible?

My motivation for this was actually hoping that this gets adopted in some environments that use JSON. Node relies on package.json files, for example, which frequently need to be hand-edited. Maintaining a sibling file in a different format feels equally wrong to me as it seems JSON5 seems to you. =)

That's npm, not node itself, that relies on package.json. When its creator chose it, he knew exactly what JSON is. He's maintained on HN and elsewhere that he made a good decision. So even if you stop calling this JSON, he's not buying it.

The package.json files, by and large, don't have a multiline string problem. For trailing and missing commas, I think you could make something that automatically fixes them, if that's the only problem, and run it before npm is run, perhaps using a shell alias.

You seem to be implying that making an effort to seek change in the format that npm uses is a bad idea. I'm not sure I understand why that is. Surely the status quo isn't always perfect?

In the software world in general, and in Node/npm land especially, code talks. I thought it'd be more productive to build and share a working ES5-style JSON parser than to simply ask Isaac if npm would support ES5-style JSON. =)

Yes, you're right about trailing commas. One motivation that such an approach couldn't address is documentation: I've frequently wanted comments in my package.json files, e.g. explaining a particular dependency version, or a script command.

  { 
    "name": "My fancy package",
    "comment": "I include both versions here for compatibility with package x",
    "scripts": ["script1.js","script2.js"],
    "comment":"to run the build script",
    "comment":"cd to the bin directory and type:",
    "comment":"node build.js",
    "build": ["bin/build.js"]
  }

  {
    "name": "My fancy package",
    "--": [
      "I include both versions here for compatibility with package x",
      "to run the build script",
      "cd to the bin directory and type:",
      "node build.js"
    ],
    "scripts": [
      "script1.js",
      "script2.js"
    ],
    "build": [
      "bin/build.js"
    ]
  }

  That's npm, not node itself, that relies on package.json.  When its creator chose it, 
  he knew exactly what JSON is.  He's maintained on HN and elsewhere that he made a good
  decision.  So even if you stop calling this JSON, he's not buying it.

Going along with this, there are other formats that lend themselves extremely nicely to being human readable/writable/parsable. I've seen YAML (http://en.wikipedia.org/wiki/YAML) used out in the wild to support these sorts of use cases, often in systems which also leverage JSON.

Edit: Not saying the author of npm is wrong for picking JSON, just that there already viable serialization alternatives expressly designed with human factors in mind.

Go and read why Crockford designed JSON like it is. E.g.: He omitted comments on purpose in order to avoid that people used them for additional directives.

Two or three "improvements" like quotes, comments don't legitimate a new standard. BTW, you could also leave out the colons.

Crockford on omitting comments: https://plus.google.com/118095276221607585885/posts/RK8qyGVa...

It's not JSON, so why does it need to look like JSON? If you want a complicated human read-writable config format, it exists already: YAML.

As for your question: of course it's possible. Write a tool that translates between your preferred format and JSON. Set up your development environment to automatically convert between the two formats when editing JSON files.

> It certainly would be great if there existed tools to let me write and update JSON with nicer syntax like this

The syntax is not necessarily nicer, it has only a few changes in the lexical structure and the syntactic structure is pretty much the same. If it's a little nicer for a human writing it, it's a little hairier for a parser to parse it.

But how much you spend time writing JSON anyway? Most of the time JSON is read and written by tools. Human intervention is rare.

In addition to that, the native JSON parsers in the browsers are probably implemented in native code, and this parser of yours is written in JavaScript. So it wouldn't be a surprise if this was an order of magnitude slower than a native JSON parser.

Instead of using your parser in the app that consumes the file, use your app in the preprocessor and have it enmity standard JSON. (You'll have to start using a preprocessor.) Don't maintain both formats, only the original (that's how preprocessors should always be handled).

JSON's strength and it's very reason for existing is its simplicity and unambiguity.

A thousand times this! Stop attempting to fragment a working standard for no benefit!

Reply on news.ycombinator.com