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.
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.