> Let's be honest here: JSON5 solves no problem worth solving, at the expense of breaking compatibility.
The problem I have is, I need a configuration language that is human readable, familiar to developers without teaching (anybody who knows JS, or to some extent Python and PHP), is also machine writable, and supports comments. The only language that supports this is JSON+comments (next contenders would be INI (!) and then XML). JSON5 just helps by giving it a name, a consistent implementation, and packages for many languages. I've rolled my own JSON+comments (or "static subset of Python / JS literals") multiple times, and am glad there is a community standard now.
The trailing comma is really an issue, because it works in JS, and it is an arbitrary restriction in JSON. If you learn JSON on the job (and think of it as "JavaScript Object Notation" i.e. JS literals) then you will run into this, and it causes unneccessary frustration.
Since every JSON5 package I know produces valid plain JSON, compatibility is never an issue.
> The problem I have is, I need a configuration language that is human readable, familiar to developers without teaching (anybody who knows JS, or to some extent Python and PHP), is also machine writable, and supports comments.
I'd say if those were your criterias and you still stuck with a JSON-derived language, your decision-making process was a colossal failure in oversight, given the myriad of options around such as TOML or even YAML.
But let's pretend that adding comments and trailing commas to JSON makes any difference regarding those requirements.
TOML is basically INI. It adds nested sections, but it is not so obvious how to use them. And the data model is more complicated, with sections first, and in each section a key-value map.
YAML has a data model like JSON, but it is disqualified for me by the syntax ambiguities.
The easiest thing is if people could just write JS (or Python) object literals, but restricted to plain old data, and without the ability to call functions etc.. JSON5 gives exactly that.
The problem I have is, I need a configuration language that is human readable, familiar to developers without teaching (anybody who knows JS, or to some extent Python and PHP), is also machine writable, and supports comments. The only language that supports this is JSON+comments (next contenders would be INI (!) and then XML). JSON5 just helps by giving it a name, a consistent implementation, and packages for many languages. I've rolled my own JSON+comments (or "static subset of Python / JS literals") multiple times, and am glad there is a community standard now.
The trailing comma is really an issue, because it works in JS, and it is an arbitrary restriction in JSON. If you learn JSON on the job (and think of it as "JavaScript Object Notation" i.e. JS literals) then you will run into this, and it causes unneccessary frustration.
Since every JSON5 package I know produces valid plain JSON, compatibility is never an issue.