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. =)
Two or three "improvements" like quotes, comments don't legitimate a new standard. BTW, you could also leave out the colons.
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.
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.
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.
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.
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.
JSON's strength and it's very reason for existing is its simplicity and unambiguity.