JSON plus comments and python-style multi-line strings is great.
The thing where you can leave quotes off strings makes me nervous, especially the example where the value is HTML with its own embedded double quotes for attribute values.
Not requiring quotes on strings like that looks like an obvious vector for injection attacks. I guess Hjson isn't designed to be generated automatically, but I'd prefer a format that is easy to generate safely.
What I really want is JSON plus comments plus multi-line strings plus relaxed rules on trailing commas... While maintaining as simple and unambiguous a parsing model as possible.
I came here to make the same comment. The ability to leave off quotes on strings is a misfeature which overly complicates the language. Also I see no need for three different comment styles.
Use what you want, ignore the rest. Like C++.
That might work for programming languages (C++'s bad rep nonwithstanding), but for data exchange formats you cannot cherrypick features, you have to support the whole spec, and nothing else.
I think it's more nuanced than that. You must be strict in what you emit, but can be liberal in what you accept. That liberalness can go too far though, and should not make parsing brittle, or encourage misuse of the spec. It's there more to allow someone's unambiguous mistakes to still parse.
- Accidentally left in a final comma on a list? That's okay, that only means one thing, we understand.
- Allow non-quoted keys on objects? Well, we understand JavaScript generally allows this, so we'll let it slide. This time.
- Make newline significant and define new items? Okay, are we just ignoring space efficient payloads now? Should making it space efficient mean changing formats from Hjson to json?
- Considering all terms in place of a object value a string until a newline? Are you just trolling me now? How is that more human readable? Does your spoken language not use quotes to distinguish distinct chunks of communication or something, and if so, does it use a Latin alphabet so it's off-putting when you see them?
Needless to say, I'm really confused by the reason this even exists.
I think the problem it is solving is that JSON is designed and best used as a data exchange format, but it also gets used for configuration files, which it does okay with but is not really so good. INI files don't have a clear standard. YAML is too complicated, and using turing complete javascript for configuration seems like you've just gone too far.
we just need JSON, but with a couple things fixed up to make it nicer to use for configuration files.