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.
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.
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."
I'd love to understand what benefits this removes and what drawbacks this introduces, aside from the chicken-and-egg problem of having any new format. Apologies if I've missed that in the discussion so far.
You're definitely right that some of the hand-editing problems could in theory be solved by tools, but it unfortunately doesn't address documentation/comments.
I've heard the chorus on YAML though, and I'll definitely be looking into it. Thanks for the feedback!
JSON is supported natively (i.e. fast and correctly) in all modern JS environments. Yes, at one point we used Crock's parser but that's the past. Likewise, it currently is only used as a stop-gap measure to begrudgingly support older browsers.
If we're going to undo years of progress we should do it for a very good reason.
JSON has wide support in many languages. Some of them have fast low level parsers. All that work has to be duplicated. Again, this just doesn't seem sufficient reason.
Right now if I want to throw together a Python script to crawl a bunch of NPM packages and read their package.json (let's say to put together a chart or collect statistics), I can easily.
If NPM switches to JSON5, we lose compatibility without a lot of duplicated effort. Again, there's just not enough benefits.
I consider comments a flaw, because they add little benefit. JSON is a data serialization/interchange format and there shouldn't be much need to comment on it, it should be largely self explanatory. If you really need to tag things with info, you can in JSON. Adding comments is to tempting for people to abuse.
However, if you really need lots of comments, there are many existing formats which might be better suited for your task. JSON is ultimately for machines. It has a benefit that humans can read/edit it easily...but if you have data that is intended more for humans and needs lots of meta information like a complicated config file, you should either create a front end for it or use a format better suited to that purpose.
When you consider that writing a plugin for your editor, or just a stand-alone translator would solve all of the problems this does, there's no reason to put up with all the drawbacks.
What it comes down to IMHO, is this isn't suitable to replace JSON and for other uses there are already existing formats that are better.
That's the issue though. It doesn't introduce anything useful in terms of replacing JSON (it can even make things worse), and for other uses better solutions already exist.
The fact that in theory if it was magically supported everywhere, it might be serviceable is neither her nor there. It's not useful information. It's not gonna happen because there's no reason to switch from JSON to this, and many reasons not to. Likewise, for other applications there are better solutions.
People started using JSON even though at that point it wasn't standard because it had real benefits over what they were currently using. There isn't any situation where using this would provide a real benefit except to satisfy personal whims, and it would have the drawbacks listed.
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.
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."