by 56k on 4/14/16, 4:06 PM with 213 comments
by simonw on 4/14/16, 4:30 PM
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.
by joeld42 on 4/14/16, 5:41 PM
- It works great, lots of people start using it
- People start adding features to fix annoying things with the format, add support for binary data, comments, schemas, add more metadata etc..
- Many versions proliferate, people start writing converters and verifiers
- A standards committee is formed and write an 800 page spec and 80kloc reference implementation
- Eighteen different libraries wrap or reimplement the reference implementation
- Someone gets fed up with this nonsense and converts their app to save their data in a new simple text format.
- The circle of life continues.
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.
by bryanlarsen on 4/14/16, 4:30 PM
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.
by JamilD on 4/14/16, 4:54 PM
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.
by nikolay on 4/14/16, 4:40 PM
[0]: http://json5.org/
by ninjakeyboard on 4/14/16, 4:48 PM
But I'm a scala developer so I might be biased.
by creshal on 4/14/16, 4:14 PM
by al2o3cr on 4/14/16, 4:33 PM
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 want...
by brandonbloom on 4/14/16, 4:33 PM
by jaybuff on 4/14/16, 9:02 PM
[ "a", "b", "c", ] // the silicon valley comma
by o_____________o on 4/14/16, 4:35 PM
by rhapsodic on 4/14/16, 7:36 PM
by xaduha on 4/14/16, 5:02 PM
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.
by wwwtyro on 4/14/16, 6:47 PM
by partycoder on 4/14/16, 10:58 PM
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.
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!
by zbjornson on 4/14/16, 4:56 PM
I'm quite happy using a preprocessor like [0], which keeps the great simplicity of JSON and just allows comments.
by DominoTree on 4/14/16, 9:59 PM
by mtalantikite on 4/14/16, 6:08 PM
by ebbv on 4/14/16, 4:49 PM
by kennell on 4/14/16, 4:09 PM
by tacone on 4/14/16, 9:17 PM
Take YAML, it looks pretty natural at first sight, but has a virtually infinite list of gotchas.
by fibo on 4/14/16, 4:50 PM
by jordache on 4/14/16, 4:37 PM
by drewm1980 on 4/15/16, 5:57 AM
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?
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...
by overcast on 4/14/16, 5:29 PM
by ant6n on 4/14/16, 9:05 PM
by RangerScience on 4/14/16, 10:24 PM
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.
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?
by kbenson on 4/14/16, 9:08 PM
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.
by aeturnum on 4/14/16, 5:02 PM
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.
by Gedrovits on 4/14/16, 5:56 PM
by sickbeard on 4/14/16, 6:20 PM
by erez on 4/16/16, 5:52 AM
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.
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.
by jbergstroem on 4/15/16, 6:13 AM
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.
by Zardoz84 on 4/15/16, 5:45 AM
by paulddraper on 4/15/16, 6:47 PM
...except you just made it significant.
This is JSON.
{"a":1,"b":2,"c":3}
{a:1b:2c:3}
by roosterjm2k2 on 4/15/16, 1:08 PM
by herpityderp on 4/15/16, 3:35 AM
YAML expresses structure through whitespace. Significant
whitespace is a common source of mistakes that we
shouldn't have to deal with.
by skybrian on 4/14/16, 4:28 PM
by blueadept111 on 4/14/16, 7:21 PM
by Ericson2314 on 4/15/16, 4:36 AM
Help me with my list of trendy things that took or are taking way to long to get a grammar: docopt, semver...
by dukoid on 4/14/16, 8:30 PM
by Murk on 4/15/16, 10:34 AM
YAML references also proved useful in my use case.
by joelthelion on 4/14/16, 5:52 PM
by stock_toaster on 4/15/16, 12:16 AM
by anthay on 4/15/16, 12:51 PM
by rymohr on 4/14/16, 5:56 PM
by emodendroket on 4/14/16, 5:39 PM
by draegtun on 4/15/16, 9:06 AM
by dasmith91 on 4/15/16, 12:41 AM
by teen on 4/14/16, 6:25 PM
by amelius on 4/14/16, 4:59 PM
by curryhowardiso on 4/15/16, 12:56 AM
by asb on 4/14/16, 6:19 PM
by pekk on 4/15/16, 5:31 AM
by joejev on 4/15/16, 5:08 AM
abc "abc" abc, "abc",
How does increasing the scope simplify things? Defining correct as "crashing less often" is a really bad idea, data formats _should_ be strict.
by educar on 4/14/16, 9:10 PM
by slantyyz on 4/14/16, 4:35 PM
by liotier on 4/15/16, 8:06 AM
This will end in tears.
by cammil on 4/14/16, 8:38 PM
by msane on 4/14/16, 10:03 PM
by pas256 on 4/15/16, 3:35 PM
by b34r on 4/15/16, 1:02 PM
by dorfsmay on 4/14/16, 4:53 PM
by OJFord on 4/14/16, 8:54 PM
> , less mistakes,
by throwaway2093 on 4/14/16, 7:04 PM
This seems pedantic, I agree, but thus is the world we live in...
Might I suggest "Human Readable JSON."