7 ms·

Hjson, the Human JSON

50 points by chris-at 12y ago

danso 12y ago
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?
- skorecky 12y ago
  Yeah, while this is a neat idea, it doesn't add much value. I rather have structure to my data.
  - mahmoudimus 12y ago
    Wait, what? Can you elaborate? YAML is used as serialization data format. Are you implying, perhaps, that YAML does not impose structure?
    - doodpants 12y ago
      I think skorecky was agreeing with danso, and implying that Hjson is lacking adequate structure.
      - mahmoudimus 12y ago
        Ah, was confused there for a sec. Thanks for clarifying.
- chris-at 12y ago
  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 12y ago
    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 12y ago
      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/.
  - peteretep 12y ago
    Which is why the original poster said "the safe version". Simple YAML is simple.
- richthegeek 12y ago
  As a JS developer, I use JSON because I can just put it directly in my code as a variable. 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.
- shkkmo 12y ago
  As I understand, the advantage is that you can then use a hjson processor to process both json and hjson config files.
pdw 12y ago
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.
- zobzu 12y ago
  HJSON seems a lot simpler and closer to JSON than 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.
  - ngcazz 12y ago
    But YAML is a superset of JSON.
    - dazmax 12y ago
      But if you start leaving commas out of your JSON, it's no longer valid YAML.
      - pdw 12y ago
        Not only can you omit the commas, you can even omit the braces. JSON: { 'one': 1, 'two': 2 } YAML: one: 1 two: 2
  - iLoch 12y ago
    I don't know about your comma statement. I never have a problem writing symantically correct JSON by hand - though there are limited use cases where you should need to do so anyway. If your IDE isn't marking invalid JSON syntax you need a better IDE.
    - zobzu 12y ago
      I dont think syntax highlighting should excuse an unnecessarily complex syntax
bsimpson 12y ago
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 12y ago
  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 12y ago
    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"
mattybrennan 12y ago
ew
harel 12y ago
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 12y ago
  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 12y ago
    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.
dkyc 12y ago
JSON is great. Please don't change JSON.
- spacemanmatt 12y ago
  This is CoffeeScript for JSON. I don't think there's anything to worry about unless browsers start to adopt this dialect.
  - likeclockwork 12y ago
    No, that would be CSON. https://github.com/bevry/cson https://github.com/bevry/cson
coreymgilmore 12y ago
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 12y ago
  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)
  - angersock 12y ago
    I'd say that JSON proved that having a standard for data-interchange was important, especially because as a standard it was both straightforward to implement and limited a lot of the crazy feature creep that made/makes XML annoying. It not only was a standard, it was a strictly better standard. 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 Anything else is gravy, and JSON managed to nail that core supporting set of features right on the head, without adding other bogus stuff. 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.
kator 12y ago
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?
thom_nic 12y ago
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 12y ago
  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.
iLoch 12y ago
http://xkcd.com/927 http://xkcd.com/927 Cut it out. JSON is fine.
daigoba66 12y ago
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 12y ago
  > 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.
jgillich 12y ago
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
rbobby 12y ago
No support for dates... which I think is the most glaring problem with JSON.
jcromartie 12y ago
So basically YAML?
njs12345 12y ago
Typesafe have something similar, HOCON: https://github.com/typesafehub/config/blob/master/HOCON.md https://github.com/typesafehub/config/blob/master/HOCON.md
garrison 12y ago
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 12y ago
  Seconded. TOML is great.
donpdonp 12y ago
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
zimbatm 12y ago
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 12y ago
  That: a) has a lot more clear use case, and b) doesn't really compete with JSON for data transfer (its primary use case)
Maken 12y ago
I fail too see how this is a improvement over YAML.
dfkf 12y ago
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.
mst 12y ago
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.
draegtun 12y ago
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
drivingmenuts 12y ago
http://xkcd.com/927/ http://xkcd.com/927/
drobilla 12y ago
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.

50 points by chris-at 12y ago

danso 12y ago

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?

skorecky 12y ago
Yeah, while this is a neat idea, it doesn't add much value. I rather have structure to my data.
- mahmoudimus 12y ago
  Wait, what? Can you elaborate? YAML is used as serialization data format. Are you implying, perhaps, that YAML does not impose structure?
  - doodpants 12y ago
    I think skorecky was agreeing with danso, and implying that Hjson is lacking adequate structure.
    - mahmoudimus 12y ago
      Ah, was confused there for a sec. Thanks for clarifying.
chris-at 12y ago
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 12y ago
  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 12y ago
    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/.
- peteretep 12y ago
  Which is why the original poster said "the safe version". Simple YAML is simple.
richthegeek 12y ago
As a JS developer, I use JSON because I can just put it directly in my code as a variable. 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.
shkkmo 12y ago
As I understand, the advantage is that you can then use a hjson processor to process both json and hjson config files.

pdw 12y ago

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.

zobzu 12y ago
HJSON seems a lot simpler and closer to JSON than 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.
- ngcazz 12y ago
  But YAML is a superset of JSON.
  - dazmax 12y ago
    But if you start leaving commas out of your JSON, it's no longer valid YAML.
    - pdw 12y ago
      Not only can you omit the commas, you can even omit the braces. JSON: { 'one': 1, 'two': 2 } YAML: one: 1 two: 2
- iLoch 12y ago
  I don't know about your comma statement. I never have a problem writing symantically correct JSON by hand - though there are limited use cases where you should need to do so anyway. If your IDE isn't marking invalid JSON syntax you need a better IDE.
  - zobzu 12y ago
    I dont think syntax highlighting should excuse an unnecessarily complex syntax

bsimpson 12y ago

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 12y ago
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 12y ago
  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"

mattybrennan 12y ago

harel 12y ago

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 12y ago
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 12y ago
  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.

dkyc 12y ago

JSON is great. Please don't change JSON.

spacemanmatt 12y ago
This is CoffeeScript for JSON. I don't think there's anything to worry about unless browsers start to adopt this dialect.
- likeclockwork 12y ago
  No, that would be CSON. https://github.com/bevry/cson https://github.com/bevry/cson

coreymgilmore 12y ago

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 12y ago
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)
- angersock 12y ago
  I'd say that JSON proved that having a standard for data-interchange was important, especially because as a standard it was both straightforward to implement and limited a lot of the crazy feature creep that made/makes XML annoying. It not only was a standard, it was a strictly better standard. 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 Anything else is gravy, and JSON managed to nail that core supporting set of features right on the head, without adding other bogus stuff. 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.

kator 12y ago

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?

thom_nic 12y ago

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 12y ago
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.

iLoch 12y ago

http://xkcd.com/927 http://xkcd.com/927 Cut it out. JSON is fine.

daigoba66 12y ago

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 12y ago
> 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.

jgillich 12y ago

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

rbobby 12y ago

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

jcromartie 12y ago

So basically YAML?

njs12345 12y ago

Typesafe have something similar, HOCON: https://github.com/typesafehub/config/blob/master/HOCON.md https://github.com/typesafehub/config/blob/master/HOCON.md

garrison 12y ago

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 12y ago
Seconded. TOML is great.

donpdonp 12y ago

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

zimbatm 12y ago

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 12y ago
That: a) has a lot more clear use case, and b) doesn't really compete with JSON for data transfer (its primary use case)

Maken 12y ago

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

dfkf 12y ago

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.

mst 12y ago

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.

draegtun 12y ago

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

drivingmenuts 12y ago

http://xkcd.com/927/ http://xkcd.com/927/

drobilla 12y ago

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.