Hjson, the Human JSON
laktak.github.io
laktak.github.io
JSON is great already. I don't really see this as necessary. I could understand the comments (but use // instead of # as per Javascript comments) to increase clarity to people who don't know the original design syntax. But the others do not seem really useful.
If there's one thing JSON has proven it's that having a standard way for data-interchange is not very important. Having a format that's easily parse- and usable is much more important, being accessible to human inspection is a good advantage as well.
(if having a standard was important we'd all still be using XML)
At the end of the day, in a data format, you need the following things:
+ Some way of associating records with keys
+ Some way of storing records in a particular order
+ Some way of nesting records within records
+ Some simple way of pathing through a record
+ Some way of delimiting the start and end of a record
+ Some way of storing numbers and strings
XML picked an overly verbose way of nesting and delimiting records, as well as presenting three options for storing data: attributes, body, and CDATA sections when one would have sufficed.
The comments thing in HJSON really annoys me, because comments are not needed in an interchange format--and if you need them because you're using it as a config file format, you can just add a comment key and name your variables better. Moreover, the temptation to use comments for, say, type annotations, is huge, and an antipattern (which is why Crockford left them out).
EDIT:
For everyone talking about a "simpler" JSON...the parser for this is about twice as long as the json2 parser from Crockford, with arguably worse comments.
One could argue "But it parses JSON anyways and lets me write sloppy^H^H^H^H^H^Hfriendly JSON", but that's not the point. People complaining about having to put their keys in quotes and leave off trailing commas are also missing the point.
And it is precisely this rigidity that led to its success. There's a tons of other things that existed before JSON, and JSON won, and it's hard not to read the fact that the very looseness of its competition, which the designers of those formats perceived as strengths, were also weaknesses. Any slight little corner in a spec where there can be a divergence of opinion, there will be divergence of opinion when being implemented dozens of times. So having the spec be rigidly precise was a key advantage for JSON.
Which, incidentally, means HJSON's competition isn't JSON. This is why everyone here is talking about YAML, and the other such languages. And that's a rich, established field with probably no room for a new language to emerge.
HJSON's only hope would be to have a mode where it could be trivially compiled to real JSON, where it could work like a dialect. Unfortunately it's promise to round-trip comments wrecks that ability.
I contend there's no "point" to JSON at all. JSON is simply JavaScript (in fact, you can eval it) that was discovered could be used to send data from servers to browsers. It became a standard out of sheer convenience.
By breaking Javascript's ability to execute the code, you're eliminating an important feature of JSON. (I'll admit that nobody should be eval'ing JSON, but the fact that you can makes its existence better understood.)
> JSON is literally a JS object literal (with the additional requirement that any key be a string).
Which makes it not a JS object literal but a near subset with slightly different rules with unicode strings that make it not even a subset.
So now you're wrong twice.
If you want something that's easier to edit for config files, you can use YAML.
And.. yeah, for human processing/reading/writing, ignoring trailing commas and having comment does improve JSON IMO.
I don't know why JSON is so strict in fact. Virtually everyone forgets to NOT have the last comma of a list all the time.
Now then again HJSON is +1 standard and incompatible with JSON so im not sure how that'll take off.
JSON:
{ 'one': 1, 'two': 2 }
one: 1
two: 2Its for when you need a quick config file, and you think "Gosh, I wish I could just put some sloppy JSON/Python-like code in here, with a few comments.", and you don't want to use XML, INI, or YAML, or roll your own format.
I guess most people here are in the web development business. Which is fine, but I am not currently. I don't need JSON for what JSON is made for, but I often need something almost like JSON for my use cases.
You know what's annoying? Having to remember a dozen-odd JSON-but-not-really config file syntaxes instead of just JSON.
That's why YAML is out of the question for me. But JSON is too restricted to write it manually (no trailing commas, no comments, no round-trip-safety). What I'd ideally like is to take this Python/JS5 file (differ only in the comment indicator # vs //)
# this is an important comment
obj = {'hello': 'world',
'list': [1,2,3,4,5,]}
...
from configfile import obj
// this is an important comment
{'hello': 'world',
'list': [1,2,3,4,5,]}
...
obj = parser.loads("configfile.cfg")
{
"configOption": {
"c": "This option is configurable.",
"val": 42
}
}
It's a human friendly (to some. It's ambiguous, so I don't think it's very friendly) , but it's not JSON and doesn't offer any of the advantages of JSON.
I like the idea of a slightly simpler JSON but still keeping just the primitive data types yet not being able to say, include arbitrary files into the document.
They just want to be able to write sloppy JSON and have code handle all the strict requirements of real JSON.
Some people are pushing for TOML as an alternative but I'm not sure if that's going to happen.
Annoyingly, "x = some_json" is much less strict than "JSON.parse(some_json)".
Whilst YAML is less ambiguous, the significant whitespace and not being able to just cut and paste an argument into usefuleness (without wrapping it in a parser) means the effort is too high for what little pay-off it provides.
It might seem like a good idea at first, but over time it just results in a culture that publishes horrifically broken markup, and increasingly baroque implementations that try to work around every possible screw-up instead of simply flagging errors. This is, in my opinion, the biggest screw-up of the web: if early browsers simply flagged errors and pointed out where and what they are clearly, the web would be a much nicer place. Instead, actually writing a parser for web markup is a nearly impossible task, and not the weekend hack it should be.
One of the, if not the, great thing(s) about JSON is its beautifully simple syntax. 5 images on json.org precisely explain what it is, and that's that. You can write a parser for it in basically any language without any fancy libraries or frameworks in a few hours. That is a good thing, regardless of whether you personally would ever have to do such a thing, because it keeps the barrier of entry low and trickles through the ecosystem in positive ways.
Missing the point of JSON? Yes, but missing much more, including lessons that should have been learned.
That said, a few of the ideas are good ones (comments and such), but the bad ones (making crucial delimiters optional) are so bad they more than outweigh the benefits.
I've been doing a lot of ansible work recently and YAML feels fairly reasonable and I can show it to my wife and she "gets" what is happening.
Sorry just reminds me of: http://xkcd.com/927/
Maybe we need a HN bot that links that automatically?
Here are the examples in Rebol:
[
; comments
;; specify rate in requests/second
rate: 1000
; quoting
key: 'value
text: "Look ma, some quotes!"
; path & HTML
path: %\c\windows
inject: <div class="important"></div>
; no need for escapes
space: %\c\windows\foo%20bar.txt
space2: %"\c\windows\foo bar.txt"
; no commas
one: 1
two: 2
; multiline string
haiku: {
Line 1
Line 2
Line 3
}
; array/list/block
fav-numbers: [1 2 3 6 42]
; and finally...
name: 'hjson
desc: "Rebol data format"
main: %./lib/rebol.reb
version: 1.0.1
tags: [
json
hjson
rebol
]
; and really finally...
light-switch: on
useful: yes
boolean: true
co-ords: 10x100
ip: 192.168.100.1
date: 1-Jan-1970
]
For those interested have a look at REN (REadable Notation), a subset/dialect of Rebol, which is an attempt to produce a standardised format - https://github.com/humanistic/REN
"//": "my comment"Ping me if you want to help out.
a) has a lot more clear use case, and
b) doesn't really compete with JSON for data transfer (its primary use case)
Come to think of it, what would an API look like that writes HJSON? Not pretty, probably.
I like the unquoted strings and trailing comma, but the rest I don't think is unnecessary. I'd be happy with the standard ECMAScript map literal format.
I haven't looked at HJSON in detail, but JSON5 which is very similar has exactly the same writing API as JSON. Namely just `stringify`, which produces plain compliant JSON.
HJSON additionally seems round-trip safe, which means if you start with comments, they are preserved, which is nice for config files.
I don't think anybody sane considers sending out non-standard HJSON over the wire where plain JSON is expected.
I don't choose a data format for readability. In fact I think that's one of the least important factors. I choose JSON when the producer or consumer is JavaScript code. That's pretty much the only reason, I think, to pick JSON over XML or anything else.
Also, both JSON and XML are terrible for config file intended to be manually edited.
I do.
JSON is a great format for config files. For example, Sublime Text's config files are in JSON. You configure the editor by editing those files. I think they additionally support comments, but if you edit something in the GUI you loose them. The round-trip-safeness of this seems like a really good addition for this use case (e.g. you change a value programmatically, and only that place in the file changes - all comments and whitespace stay where they are).
I currently use a lot of Python and some XML as "glue" code, and to configure other programs. Definitions for plots, settings for batch jobs, and so on. XML is overkill, and hard to parse. Python scripts are limited to python, and you have a full interpreter, so people can put logic in your config files, which is usually not what you want. YAML is too non-standard and has too many varieties and edge cases. JSON is really great for this case - even better, leninent JSON+comments. And accidentially, JSON is not only Javascript, but almost valid Python, and a couple of other languages. I think the sweet spot is hit by JSON5, which is JSON extended with some ECMAScript5 features, and additional comments.
I agree of course that plain JSON is the best when you write webservices, or consume or produce with JavaScript. I wouldn't use any non-standard thing on the wire. But if you just want to set a few variables from outside in your program, its great to be able to put a JavaScript/Python/PHP object literal in a file with a few comments, and it just works.
Actually, all the JSON I produce at work is per hand. It would be a major productivity increase if I had a more lenient parser. You don't have to call it JSON if it offends you, call it "Object literals that look like JavaScript or Python" if you like.
Cut it out. JSON is fine.