
Hjson, the Human JSON - chris-at
http://laktak.github.io/hjson/
======
coreymgilmore
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.

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.

~~~
tinco
No, the point of XML is to have a standard way for data-interchange. The point
of JSON is to have a lighter and simpler way of data interchange, where the
data is arrays and maps of strings and numbers. It also works well with
Javascript.

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)

~~~
otterley
> The point of JSON is to have a lighter and simpler way of data interchange,
> where the data is arrays and maps of strings and numbers. It also works well
> with Javascript.

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.)

~~~
gnaritas
No you can't, JSON is not JavaScript and eval is not capable of working on all
correct JSON documents. JSON requires a JSON specific parser. So this breaks
nothing, eval doesn't work now and JSON has never been JavaScript.

~~~
ninjaplease
Look, you're just wrong. The only exception to "eval" is some obscure unicode
bug others are mentioning. JSON is literally a JS object literal (with the
additional requirement that any key be a string). There's also no reason to
use eval when JSON.parse will do it safely.

~~~
gnaritas
No I'm not wrong and there mere fact that you mention the exception means
you've conceded my point; and those aren't bugs, they're in the spec which
means it was never a subset of JS.

> 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.

~~~
ninjaplease
What spec are you looking at?
[http://www.ietf.org/rfc/rfc4627.txt](http://www.ietf.org/rfc/rfc4627.txt)
specifically says in section 2.5 that all unicode characters are meant to be
supported.

So now you're wrong twice.

~~~
gnaritas
Try learning something jackass: [http://timelessrepo.com/json-isnt-a-
javascript-subset](http://timelessrepo.com/json-isnt-a-javascript-subset)

------
pdw
Well, that completely misses the point of JSON: simple and unambiguous syntax.

If you want something that's easier to edit for config files, you can use
YAML.

~~~
philjackson
It doesn't really miss the point - the point was a more human friendly JSON
and it hit that nail on the head pretty well if you ask me.

~~~
dangerlibrary
"a more human friendly JSON" is a goal that misses the point of JSON.

~~~
captainmuon
Yes, exactly. But it's not even meant to replace JSON. It's not for exchanging
data between computers, and its not for webservices etc.

Its 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.

~~~
angersock
Just use JSON, and add a key (which you can ignore!) for comments. Even
better, you get to use any of the dozens of already-tested JSON parsers out
there for this! There is absolutely _no_ reason you need to reinvent the wheel
here.

You know what's annoying? Having to remember a dozen-odd JSON-but-not-really
config file syntaxes instead of just JSON.

~~~
captainmuon
> 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
    

and to turn it into a safe

    
    
        // this is an important comment
        {'hello': 'world',
               'list': [1,2,3,4,5,]}
        ...
        obj = parser.loads("configfile.cfg")
    

It's not that I don't like JSON. Its just that I have a different
requirements. When I need JSON, I use JSON. When I need easily editable config
files that look like Python or JS (which I can easily remember), I use
something like HJSON.

~~~
angersock
Two of your issues go away:

    
    
      {
        "configOption": { 
                          "c": "This option is configurable.",
                          "val": 42
                        }
      }
    

And now, the comment is round-trip-safe _and_ exists!

------
danso
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?

~~~
chris-at
IMO yaml is too complex. Just take a look at the spec:
[http://www.yaml.org/spec/1.2/spec.html](http://www.yaml.org/spec/1.2/spec.html)

~~~
vlunkr
Sure YAML is more complex than JSON, but that's because it's more than just a
data structure. If you are using it only for things that JSON can do, it's
really not that complex.

~~~
thirdtruck
Agreed. I use a YAML file to track my daily agenda. It was easier to figure
out the format, and to leverage existing parser libraries for my reports, than
to write my own "agenda-optimized" file format. A good example of
[http://xkcd.com/1205/](http://xkcd.com/1205/).

------
drobilla
I will never understand the tendency, especially in the web community, to
consider complicated, ambiguous, inconsistent, and difficult to parse syntaxes
as "friendly".

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.

------
kator
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.

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/](http://xkcd.com/927/)

Maybe we need a HN bot that links that automatically?

------
draegtun
The more you try and push JSON along these lines the more it ends up looking
like Rebol.

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
      ]
    
    

Of course this shouldn't be a surprise because Douglas Crockford cites Rebol
as an influence on JSON.

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](https://github.com/humanistic/REN)

------
bsimpson
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.

~~~
skorecky
You can add comments but they won't be passed along and I don't think that's
the case for this either. They're just there for documenting.

~~~
bsimpson
Many implementations I've seen will raise a syntax error if you include a //
in JSON. Then, you have to do clever shit like make a key that you don't use
anywhere:

    
    
         "//": "my comment"

------
zimbatm
Selfish plug, here's another JSON derivative that's optimised for single-line
representations like log lines:
[https://github.com/zimbatm/lines](https://github.com/zimbatm/lines)

Ping me if you want to help out.

~~~
bsimpson
That:

a) has a lot more clear use case, and

b) doesn't really compete with JSON for data transfer (its primary use case)

------
dkyc
JSON is great. Please don't change JSON.

~~~
spacemanmatt
This is CoffeeScript for JSON. I don't think there's anything to worry about
unless browsers start to adopt this dialect.

~~~
likeclockwork
No, that would be CSON.
[https://github.com/bevry/cson](https://github.com/bevry/cson)

------
thom_nic
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.

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.

~~~
captainmuon
Sure, but messages in-fligt not what this is for. This is only for writing
"JSON" manually. I don't think there are many use cases where you have to
generate comments programmatically.

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.

------
donpdonp
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.

[https://github.com/edn-format/edn](https://github.com/edn-format/edn)

------
daigoba66
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.

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.

~~~
captainmuon
> 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.

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.

------
dfkf
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.

------
jgillich
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.

[1]: [https://github.com/bevry/cson](https://github.com/bevry/cson)

------
njs12345
Typesafe have something similar, HOCON:
[https://github.com/typesafehub/config/blob/master/HOCON.md](https://github.com/typesafehub/config/blob/master/HOCON.md)

------
mst
Having an ultra-relaxed JSON for config files is an excellent idea; ingy and I
called our take on it JSONY - see
[http://p3rl.org/JSONY](http://p3rl.org/JSONY) for some examples.

------
garrison
I see many mentions of YAML in the comments, but why not TOML?
([https://github.com/toml-lang/toml](https://github.com/toml-lang/toml))

~~~
mahmoudimus
Seconded. TOML is great.

------
Maken
I fail too see how this is a improvement over YAML.

------
jcromartie
So basically YAML?

------
harel
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.

~~~
captainmuon
Yes, there is a problem. Many programs use JSON for config files. You can't
really comment stuff in there, and if you change something programmatically,
you loose all comments and layout. A major example is Sublime Text, but I also
heard the package management in node.js uses JSON, and people complain about
not being able to include comments.

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.

~~~
harel
I still think that either said config files should use another format, or
people should adhere to the spec. For this to have massive adoption new
parsers will be required for all major languages. The problem it solves is not
that great to merit new parsers I don't think. Of course, I could be
completely wrong and this will become the next standard, but I doubt it.

------
drivingmenuts
[http://xkcd.com/927/](http://xkcd.com/927/)

------
rbobby
No support for dates... which I think is the most glaring problem with JSON.

------
mattybrennan
ew

------
iLoch
[http://xkcd.com/927](http://xkcd.com/927)

Cut it out. JSON is fine.

