I believe the idea here was not to try execute these objects, but use (a subset of) the JS syntax to define the data structure with less double-quotes and with JSONC-like comments. It will still need an equivalent of JSON.parse() to become a real object in JS.
If JSON can be used everywhere, there is nothing preventing that js object could be used everywhere. If you can parse a JSON, why on earth wouldn't you be able to parse a js object? For the untrained eye, they are the same. For the trained eye, one has more quotes than other. Just because one syntax has more quotes doesn't make it unparsable by all other languages. Js object is much cleaner to read AND write than JSON. I am currently making a config file for a flow. This file has to be in json. I am currently using JSON.parse. I'd MUCH rather have it in js object. Cleaner to write, cleaner to read. Hence why I wrote "I'd love to be able to parse such a js object from file in NR". I would prefer to read a js file and parse it, not json.
I guess this is a prime example of the limitation of imagination I experienced earlier.
I think we are talking at cross purposes. A javascript object is something that exists in memory when running javascript. I realise now that you are talking about the syntax used in javascript code to describe an object. So in fact you are effectively talking about a 'better' JSON syntax.
On the trailing comma question inside an array, I agree that it is often convenient to allow the extra comma.
In your improved JSON how would you like to be able to define an object containing a property my-property?
1 Like
I can sacrifice that for a simple js oriented object notation improvement of JSON! I'll trade dashes in prop names all day for comments and trailing commas (and less quotes too). Of course it would break a gazillion existing schemas from people who enjoy such names... but I'd sacrifice that too haha 
Perhaps a middle ground is to allow quotes (like current JSON) for those pesky prop names?
Btw those quotes gave us several data points in db named "energy_consumption " (see the trailing space?) due to how fragile it is to write (in NR btw). Added a filter (also in NR) to prevent it (abort + log), so no more problem.
You realise that the way to handle special characters in properties in javascript is for example
let msg.payload = {"my-property": 7}
in other words it uses the JSON syntax. All that javascript does is to make the quotes optional if the property name does not contain special characters.
1 Like
Yup. That optionality makes me so much happier working with the syntax of objects in javascript compared to JSON (particularly the reading & writing part). So much so I've added nrlint rules to notify useless quotes (unless these pitfalls we discussed and more). And formatting to remove as much of it as possible. And if that's inadequate, I got a full eslint & prettier setup in vscode which can completely change JSON to js object syntax (+ preferred formatting). Thanks for pointing out my inaccurate wording, I should have used correct terminology as I have studied and learned these terms in my education.
Which syntax do you prefer? Or don't mind either or?
Preference doesn't really come into it. JSON is a standard interchange format that is used in a vast number of applications around the world. For the likes of you and I it is impossible to change that. Similarly we are not going to affect the syntax of object descriptions in javascript. So when writing JS code we have to use the javascript syntax and when passing data in text form out of javascript it would generally be foolish not to use JSON as it is so widely understood.
Thanks.
That explains a bit for me which I never fully understood.
And this is why I said:
Sorry, my brain is not working just now.
I'm not sure how to parse that.
My imagination is out there some/most of the time.
I just never saw/understood that.
But now I know. 
