The point of JSON is to have a standard way for data-interchange. Adding the complexity of "sometimes you might have quotes, sometimes not" and "you can display multi-line strings in different ways" gets away from this.<p>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.
Well, that completely misses the point of JSON: simple and unambiguous syntax.<p>If you want something that's easier to edit for config files, you can use YAML.
All of these ideas are good (from a consumer perspective, it's too early in the morning to think about implementation issues)...but I have to ask out loud what I frequently just think...why don't we just start adopting YAML more? Or, at least, a subset of the "safe" kind of YAML, mostly restricted to what JSON can do?
I will never understand the tendency, especially in the web community, to consider complicated, ambiguous, inconsistent, and difficult to parse syntaxes as "friendly".<p>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.<p>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.<p>Missing the point of JSON? Yes, but missing much more, including lessons that should have been learned.<p>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.
Seems like a construed attempt to make JSON easier for "humans" (whatever those are) but in general JSON isn't something my mom worries about. I'm not sure why something like a simplified YAML couldn't be used for the intended use cases.<p>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.<p>Sorry just reminds me of: <a href="http://xkcd.com/927/" rel="nofollow">http://xkcd.com/927/</a><p>Maybe we need a HN bot that links that automatically?
The more you try and push JSON along these lines the more it ends up looking like Rebol.<p>Here are the examples in Rebol:<p><pre><code> [
; 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
]
</code></pre>
Of course this shouldn't be a surprise because Douglas Crockford cites Rebol as an influence on JSON.<p>For those interested have a look at REN (REadable Notation), a subset/dialect of Rebol, which is an attempt to produce a <i>standardised</i> format - <a href="https://github.com/humanistic/REN" rel="nofollow">https://github.com/humanistic/REN</a>
It would be nice if JSON accepted comments and Python/ES5 have proven the developer ergonomics of trailing commas, but I'm not convinced the rest of these are improvements.
Selfish plug, here's another JSON derivative that's optimised for single-line representations like log lines: <a href="https://github.com/zimbatm/lines" rel="nofollow">https://github.com/zimbatm/lines</a><p>Ping me if you want to help out.
Comments are nice when your JSON is at-rest (e.g. in a file) but more often than not it's in-flight and my code is probably not adding comments when building a message.<p>Come to think of it, what would an API look like that <i>writes</i> HJSON? Not pretty, probably.<p>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.
The 'next JSON' should be EDN. It addresses the shortcomings suggested by hjson and more. It has comments, all commas are gone, it has symbols (aka light-weight strings), it has built-in support for time and uuid objects.<p><a href="https://github.com/edn-format/edn" rel="nofollow">https://github.com/edn-format/edn</a>
Why do our machine data formats (JSON, XML, etc) need to be more human friendly? I don't build business processes that involve a human reading and manipulating JSON or XML.<p>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.<p>Also, both JSON and XML are terrible for config file intended to be manually edited.
Handling of strings is way too complex for very little gain, but the rest - trailing commas, comments and no quotes for alphanumeric keys - are actually quite useful. They complicate syntax only a little, yet make writing JSON by hand much nicer. These small additions merely take us back to Javascript object initialization syntax, straitjacketed version of which Crockford called JSON.
Something similar I've used in the past is cson [1]. It is like JSON but in CoffeeScript, which allows comments and multi-line strings as well.<p>[1]: <a href="https://github.com/bevry/cson" rel="nofollow">https://github.com/bevry/cson</a>
Having an ultra-relaxed JSON for config files is an excellent idea; ingy and I called our take on it JSONY - see <a href="http://p3rl.org/JSONY" rel="nofollow">http://p3rl.org/JSONY</a> for some examples.
I see many mentions of YAML in the comments, but why not TOML? (<a href="https://github.com/toml-lang/toml" rel="nofollow">https://github.com/toml-lang/toml</a>)
Sorry, was there a problem with JSON that I wasn't aware of? Oh, you mean, the problem of following the spec or not paying attention. Ok, in that case I see high adoption rates for this. Or, we can just make sure we do follow the spec and pay attention to what we're doing and stick with what works and is practically an industry standard.