JSON plus comments and python-style multi-line strings is great.<p>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.<p>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.<p>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.
- Someone saves data as text with a simple format<p>- It works great, lots of people start using it<p>- People start adding features to fix annoying things with the format, add support for binary data, comments, schemas, add more metadata etc..<p>- Many versions proliferate, people start writing converters and verifiers<p>- A standards committee is formed and write an 800 page spec and 80kloc reference implementation<p>- Eighteen different libraries wrap or reimplement the reference implementation<p>- Someone gets fed up with this nonsense and converts their app to save their data in a new simple text format.<p>- The circle of life continues.<p>I love this idea and wish json had comments, too, but if you start hitting the point where JSON is not expressive or fluid enough, that's a hint that it's probably not the right thing for what you're doing. This variant puts a lot of work into human-friendly json, but if you're doing a lot of hand-editing of a file, it should probably not be JSON.
This spec repeats one of the problems with using YAML as a configuration spec. To quote: "if your key includes a JSON control character like {}[],: or space, use quotes
if your string starts with { or [, use quotes"<p>JSON and YAML are interchange formats, not configuration formats. Rather than than hacking up an interchange format, it's probably better to use something designed for configuration formats, like TOML.
Rigidity and consistency are not always bad things. They can help prevent bugs, security vulnerabilities, and they drastically reduce complexity of implementation.<p>JSON might often be too rigid, but I think it's important to note that "easier" (in that you don't need to learn the syntax) isn't always better.
JSON5 [0] is better as unlike Hjson, it doesn't include non-ECMASCript syntax.<p>[0]: <a href="http://json5.org/" rel="nofollow">http://json5.org/</a>
I feel like HOCON fills the space pretty well, and has implementations in most languages now. <a href="https://github.com/typesafehub/config" rel="nofollow">https://github.com/typesafehub/config</a><p>But I'm a scala developer so I might be biased.
"Both HOCON and YAML make the mistake of implementing too many features (like anchors, sustitutions or concatenation)"<p>YMMV, but if you're aiming for a format that's edited / maintained by humans things like YAML's anchors and substitution are exactly the features I'd <i>want</i>...
Just the other day I commented complaining about JSON config files without comments, but now here I am complaining about _three_ ways to write a comment. OK, I can see two ways: block and line comments. But why two ways to write line comments? Why start off a new grammar with that added complexity?
Ah, yes, the trailing comma in a list, which I like to refer to as the "Silicon Valley Comma"<p>[ "a", "b", "c", ] // the silicon valley comma
Looks like a solution in search of problem, to me. JSON is designed to be machine-readable, and to the extent that I actually <i>need</i> to human-read JSON, which is not that much, I don't find it all that difficult.
Standards are better when they are followed. Chicken and egg problem, these alternatives are DOA because they are not going to be popular.<p>The only reason JSON is popular is because of Javascript. And the only reason Javascript is popular is because of the browsers and their history.
I've used with great results in my procedural planet generator[1]. It's very forgiving, so made writing a "UI" with lots of complicated controls very easy for me.<p>[1] <a href="http://wwwtyro.github.io/planet-3d/" rel="nofollow">http://wwwtyro.github.io/planet-3d/</a>
JSON parsers are not really slow. JSON is simple enough that allows multiple implementations for parsers and easy adoption. But HJSON additions have some serialization cost overhead.<p>Because of this eventually you will need to convert your HJSON to JSON prior to deploying, and that would make things slower. You will be dealing with 2 formats instead of one.<p>Then, do you really believe that adding all this syntactic "features" (overhead) will make it less error prone? It will make it more error prone because it has more things to consider!
Oy, someone loves yaml...<p>I'm quite happy using a preprocessor like [0], which keeps the great simplicity of JSON and just allows comments.<p>[0] <a href="https://www.npmjs.com/package/strip-json-comments" rel="nofollow">https://www.npmjs.com/package/strip-json-comments</a>
"Helps reduce errors" - you're really trading errors for other errors - your behavior is now more ambiguous with more edge cases, but look, you don't have to place quotes around strings! (except when you still do)
Can someone explain why people want to use a data-interchange format like JSON for configuration files, rather than using a configuration file format like TOML? I've never understood why people want to use JSON for config files.
This abandons a lot of principles of JSON that are there to avoid ambiguous situations. The small benefits don't seem to outweigh the snake pit you're jumping into.
To be honest: relaxed formats usually bring a lot of glitches to keep in mind. It's probably easier to use stricter specifications.<p>Take YAML, it looks pretty natural at first sight, but has a virtually infinite list of gotchas.
Shouldn't we keep our format specs simple and strict, and relegate aesthetic, and typo-correction stuff to the editor?<p>i.e. something with aspects of clang-format (which tries hard not to change the meaning of your code even if it's broken), and the aggressive autocorrection necessary to make typing on a touchscreen work?<p>I suppose there are converters from this to json, though, so maybe this is just a better specified way of converting keypresses from monkeys into something with well defined structure...
Hi! I like what you've made. I have been working on something similar, although the Github is <i>massively</i> out of date and was never complete to begin with:
<a href="https://github.com/narfanator/YAMLite" rel="nofollow">https://github.com/narfanator/YAMLite</a>
(Also, I'm renaming it nowish on the up-to-date version).<p>This parser handles YAML, JSON and XML. Interestingly, many of the features HJSON has, this has, by virtue of it being easier to implement during the parsing stage.<p>The part I'd draw your attention to - and the part that I think warrants the most discussion - is the resulting data structure. I mostly can't tell what the structure is of the HJSON C# object - it looks like it does most of what I wanted to change about the existing C# JSON parsers, but maybe not all?
This feels like a project that had a core idea that was good and justifiable (we'll take some of the common JSON mistakes such as extra commas and most asked for features sub as comments) and then felt the need to keep throwing in features to justify its existence, and now it's lost sight of its original goal.<p>This can't even be parsed natively by major JavaScript implementations, so is it really JSON at all? Actually, I think that's the root of my complaints, that it's associating itself with JSON while clearly diverging from what was important originally in JSON. At this point it's just some incompatible format leveraging the JSON name. I think most my criticisms would be ameliorated if it was just some other JSON-similar format with a different name.
This looks pretty great.<p>We've been looking for a replacement configuration format over our ancient ini files and had rejected JSON for TOML because TOML allows comments (and man, can comments be useful in configuration files). This looks like a nice medium-long term alternative.
I don't understand. doesn't commenting ruin the whole point of a human readable format? If you have to add comments, it means you need to communicate something that can be done in more concise way.
Human-readable json would've been a great idea, if it wasn't for the fact that json was NOT MEANT TO BE HUMAN READABLE.<p>It is meant to be generated by a machine and not created by hand, neither it should be readable by humans, only parse-able by a computer.<p>Treating your data interchange/serialization/configuration/markup formats as languages that should be human readable/writable is a cardinal sin of any person or company that engages in such practices.
Just wanted to bring libucl into the game in case you are exploring json-like syntax: <a href="https://github.com/vstakhov/libucl#improvements-to-the-json-notation" rel="nofollow">https://github.com/vstakhov/libucl#improvements-to-the-json-...</a><p>In my eyes pretty much the perfect configuration library and syntax. Nginx-alike, number suffixes (1min, 2gb, ..), macros, variables, includes with priority, etc. Boom! Problem solved.
And i should remember SDLang that now have a few years and reference implementations on Java, C# and Dlang . I don't see why we need reinvent the wheel again and again...<p><a href="https://github.com/Abscissa/SDLang-D/wiki/Language-Guide" rel="nofollow">https://github.com/Abscissa/SDLang-D/wiki/Language-Guide</a>
> Significant whitespace is a common source of mistakes that we shouldn't have to deal with.<p>...except you just made it significant.<p>This is JSON.<p><pre><code> {"a":1,"b":2,"c":3}
</code></pre>
This is Hjson after applying the mods:<p><pre><code> {a:1b:2c:3}
</code></pre>
....oh, it turns out Hjson actually <i>does</i> have significant whitespace.
Where is this drive to create dumb languages coming from? I dont mean dumb in the opinionated way, i mean, dumb in the way of "its hard to write proper code that follows rules, quoting and commas are hard" ... ... ... if quotes, commas and escaping is hard for you, you dont need to be an engineer....
This looks cool, but their characterization of YAML is disingenuous<p><pre><code> YAML expresses structure through whitespace. Significant
whitespace is a common source of mistakes that we
shouldn't have to deal with.
</code></pre>
since every code editor ever used will take care of this for you.
The Jaunt JSON parser (Java) was my solution to this problem. It can handle arbitrarily dirty data, including missing quotes or using semicolons instead of quotes, missing quotes, etc.<p><a href="http://jaunt-api.com" rel="nofollow">http://jaunt-api.com</a>
Grammars people! If you don't provide it / promote it, I assume your "nice simple thing" is neither obvious nor thought-through. Sorry.<p>Help me with my list of trendy things that took or are taking way to long to get a grammar: docopt, semver...
There is also HUTN already: <a href="https://epsilonblog.wordpress.com/2008/09/15/new-in-hutn-071/" rel="nofollow">https://epsilonblog.wordpress.com/2008/09/15/new-in-hutn-071...</a>
Comments, readability plus typabiliy where one of the main reasons I recently chose YAML for a configuration file. It seems YAML is a bit unloved these days, perhaps because it is more difficult to parse fully.<p>YAML references also proved useful in my use case.
There is also libucl[1] which is kind of json like. FreeBSD is apparently starting to use of it for a few things.<p>[1]: <a href="https://github.com/vstakhov/libucl" rel="nofollow">https://github.com/vstakhov/libucl</a>
Off topic, but related: I made a simple data-serialisation file format based on S-expressions, which may be of interest to some: <a href="http://loonfile.info/" rel="nofollow">http://loonfile.info/</a>
HONEY was my take at the same problem. Still brainstorming on this one and not used in production yet.<p><a href="https://github.com/honey/honey" rel="nofollow">https://github.com/honey/honey</a>
I'm not using a nonstandard JSON extension unless it implements a standard freaking date format. I also don't think bare strings are necessarily a great idea since they lose implicit type information.
Soon: Situation: there are 15 competing standards.[1]<p>[1]: <a href="https://xkcd.com/927/" rel="nofollow">https://xkcd.com/927/</a>
so in this language these all do the same thing:<p>abc
"abc"
abc,
"abc",<p>How does increasing the scope simplify things?
Defining correct as "crashing less often" is a really bad idea, data formats _should_ be strict.
Worst name ever. I'm not even joking... Perhaps it would be less offensive if the last three letters didn't spell the word "SON."<p>This seems pedantic, I agree, but thus is the world we live in...<p>Might I suggest "Human Readable JSON."