JSON is wonderful because it is simple and unambiguous. It just works, and serialized data will always look the same.<p>This "JSON5" thing is an abomination. Use whatever quotes you like! More string escaping rules! Adding these things would make JSON worse, not better.<p>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.
Three things:<p>* Comments in JSON files are not a great idea because people might (will?) abuse them to add special instructions for their own serializers. As soon as this happens we'll have a format that is not compatible with other serializers.<p>* JSON today is a universal format. So, what are special characters? Should '1hello' be quoted? If no, then its not a subset of JavaScript anymore. If you're writing a new specification you have to define all those things. Same with multiline strings: space after backslash?<p>* Why? I know that hand-writing JSON can be annoying but is this really the biggest problem we have?
I won't begrudge someone a fun little personal project, however (almost) no-one will ever adopt this. It removes too many benefits of JSON/introduces drawbacks for very little pay off.<p>Yes, JSON is a pain to edit/write by hand at times, but that's an editing problem and therefore should be solved in the editor. In any halfway decent editor it should be trivial to extend it with helpers for editing JSON. Perhaps have it convert .json files to YAML(etc) on opening, and back to .json on save etc.<p>This is a problem that plagues many technical people (present company included). You had a good instinct, but then took a left turn somewhere. "JSON is hard to hand edit...let's undo all the speed/compatibility progress we've made with JSON in the last ~8 years and introduce flaws in the protocol with a new non-standardized format...all so it's superficially easier to edit by hand."
(young) people seem to always want to find ways to skirt the "rules" that Crockford sets up (see also, jslint). Just stop. The rules he lays out are there to make your _long term_ programing life easier. Yes you may have to remember to use semicolons and quote things, but when you have to live with an application you've been working on for years, hopefully you'll learn to appreciate the fact that putting in a little extra time now saves you tons of headaches down the road.
Please, don't call it JSON. There is only one JSON, and you didn't make it. It's cool that you made this, and that you made it open source, just please call it something else.
While we're at it, I felt it necessary to launch HTML7: <a href="https://github.com/mitchellh/html7" rel="nofollow">https://github.com/mitchellh/html7</a>
Author here.<p>This idea stemmed from long-running frustration every time I hand-wrote JSON (particularly common for Node/npm packages and test cases). After stewing on it for over a year, I bit the bullet today and made it a reality.<p>Feedback greatly welcome!
I think that it's really a shame to see people slamming aseemk here. He had an idea, worked on it, and released it. That's fantastic. There are a few constructive comments here explaining why his idea might not actually be that great, but there are also quite few comments that seem out of place for HN.
You know that something has gone very deeply wrong somewhere when people oppose your project because they are ideologically opposed to comments. In my own experience, finding out that many JSON parsers reject comments was a real WTF moment, and a deal breaker for my config-file application, so I ended up using JSON-plus-comments for it instead of JSON. At the same time, lack of support for trailing commas and unquoted member names have been a minor but persistent thorn in my side for no good reason.<p>The justification for not having comments in JSON is that in the great disaster that was XML, some projects would parse the comments and take them as semantically significant. However, the real problem there was that parser libraries would expose the comments, and that some generators would put important information only in comments. But I think that these mistakes are unlikely to be repeated, and that the proposed alternative - moving all comments into the markup, or eliminating them entirely - is just obviously worse.<p>One of the things that ruined the XML ecosystem was a persistent belief that XML was to be read and written by machines, combined with a reality in which it was mostly used for human-written config files, leading to a tolerance for awful syntax (like prefixing every single attribute with a namespace, and the ridiculous CDATA notation). I'm seeing the same thing with JSON: A significant fraction of its use is for human-written and human-read config files (which often desperately need comments) and people are pretending it's strictly a data interchange format that shouldn't be used for that.<p>It is sometimes said that JSON was discovered, rather than invented - that the syntax was already out there. So it is with JSON5: There is nothing <i>new</i> in this, it is simply return to JavaScript Object Notation and bringing in the rest of what Javascript has.<p>So, all you pooh-poohing ideologists: please seriously rethink whether disallowing comments, trailing commas, and quoteless member names is actually a good idea. Consider this in light of the fact that JSON is widely used, today, as a config-file language, and that {"--":"This is a comment"} is ridiculous enough that no one does it in practice, can't be inserted on any line, and invites consumers of your data to parse the comments.
This reminds me of I guy I met who was trying to build a clone of Twitter, but with messages of unlimited length. In his view this made it objectively "better". He understood the <i>what</i> of the software, but not the <i>why</i>.<p>If you really want ES5 for writing package.json files, then you could save the time and effort by just using ES5:<p><pre><code> var _ =
{
some: 'object literal',
// a comment
num: 3,
}
fs.writeFileSync(path.basename(__filename, '.js') + '.json', JSON.stringify(_))</code></pre>
JSON is great because it is simple basic cs types (string, numeric, boolean, object, list, date), a perfect middle ground between messaging and readability without going all XML/SOAP. And the unchanging simplicity is that way because it is so broadly accepted from Javascript to web services and beyond. It fits nicely into the system because of it's limitations but that also gives it standardized power.<p>Any changes to JSON should be fought til death. Use YAML or make a new format if you need more.
I have to agree with most of the criticism in this thread. The lack of comments, strict quoting, no trailing slashes - these aren't problems to fix they are features.<p>As others have noted this is not JSON and is not necessarily an improvement to JSON - so calling it JSON5 is presumptuous.<p>Embrace the criticism. Instead of JSON5 call it <i></i>NotJSON<i></i> - a standard that breaks the JSON rules for a few narrow use cases - namely when you want a hand-written, commented JSON-like syntax.
I don't think any of these suggestions make JSON easier to read, generate, or consume. What problem are you setting out to solve?<p>Opening paragraph: "JSON is strict. Keys need to be quoted; strings can only be double-quoted; objects and arrays can't have trailing commas; and comments aren't allowed."<p>If this represents a comprehensive list of the problems JSON5 solves I think you'll have a hard time rallying people around your cause.
Seems like you're getting a lot of criticism for this, a lot of which I have to agree with. Writing valid JSON is extremely simple and unfortunately it's hard to see how this project would do anything besides promote bad practices for a near-universal format.<p>Suggestion: turn these criticisms to your favor. Make this into something that <i>promotes</i> good form. Perhaps by acting as a compiler that transforms your forgiving JSON into valid JSON. Make a command line utility. Emphasize how the output passes JSONlint or something. In other words, I'm suggesting that you remake this into a sort of coffeescript for JSON.<p>In any case, the path you are on isn't gonna garner much support. Change up your stride a bit and you could be on to something rather nice, though.
Congratulations, you've made something which looks superficially like JSON, but most documents won't parse in 99.9% of JSON parsers. Interoperability is lost, nothing is gained!
If only it were this easy to extended JavaScript with a new serialization format! If the serialized text can't be assigned to a JavaScript variable, it's not JavaScript notion.<p>I also tried something similar a few years back when I was sick of dealing with XML and coming to terms with the required quotes.<p><a href="http://xjson.org/" rel="nofollow">http://xjson.org/</a><p>While it's certainly prettier to have native literals and optional quotes, it's simply not worth giving up the interoperability with JavaScript.
I don't think making JSON more human-writable and readable is a goal worth pursuing.<p>JSON has its flaws, but is a surprisingly robust and elegant solution to many data interchange problems. But it is not (and I don't think it was ever intended to be) a language for human-edited configuration and data.
I can't believe people are taking this seriously...<p>Lets write a python parser who accepts semicolons instead of indentation, just to fix when I forget that i am not writing Javascript; oh, and and make it accept the "function" keyword instead of def.