9 ms·

Goodbye Hjson

24 points by laktak 8y ago

beaconstudios 8y ago
JSON is a serialisation format. In cases where you're writing config, you'd surely be better pushing for something even more human-readable (I want to say YAML but it has some problems, so something along those lines) because the cost of switching from JSON to <anything> is the barrier to entry, so you might as well go for the ideal if you are committing to switch. I guess I just don't see where this fills a gap.
- philwelch 8y ago
  ini is an underrated config format.
  - beaconstudios 8y ago
    I am definitely a fan of INI, but (AFAIK?) it doesn't support structured data beyond simple sectioning.
    - philwelch 8y ago
      Constraints are a good thing ;) You can fake it by having say, dot-delimited keys, but a lot of the complexity of config file formats come from the desire to support arbitrarily structured data when sometimes it's just as easy to fake it, not have it, or even use some templating.
    - cmroanirgo 8y ago
      > it doesn't support structured data beyond simple sectioning Not exactly true (nor completely untrue). Look at your .gitconfig to see an example of how it can shoehorned in. Basically, it uses a .dot notation in a section header to distinguish levels. I wrote an little module a few years back that copes with structure support: https://www.npmjs.com/package/jsinf#the-format https://www.npmjs.com/package/jsinf#the-format
  - geezerjay 8y ago
    > ini is an underrated config format. I agree, but the problem with ini is that it isn't a format in the sense that it hasn't been formally defined in a consensual way. Thus the monumental success of TOML as it fills the void that ini left unfilled for decades.
ianbicking 8y ago
I always meant to use hjson somewhere, but never managed to. YAML is so complicated, and JSON is almost fine, except for: no comments, no multiline strings. Quoting keys is tedious but not terrible. Personally I don't mind quoting string values at all. There are places with slightly relaxed JSON, like JSON + comments (e.g. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...). But it's often not well documented, and because these relaxations lack a name there's no commonly accepted set of relaxations. But I guess we should just accept YAML, as it seems to be the standard-that-isn't-json.
- bosaisi 8y ago
  Try TOML. It's like a better YAML, and seems to be getting some good adoption.
- MrTonyD 8y ago
  Agree completely. I usually use YAML just so I can document my work using comments. If they added "heredoc" and comments, I think that I would be happy with JSON forever.
- geezerjay 8y ago
  > no multiline strings I thought that the JSON way of implementing multiline strings was through an array of strings.
zadler 8y ago
Not sure why the author thinks it “deserved” to be more successful? Do they know something that everyone else does not?
- laktak 8y ago
  Of course it's possible that Hjson was just bad and that is why nobody picked it up. My main mistake though was probably the name of the project. It made a lot of people think that this was supposed to replace JSON.
laktak 8y ago
Not sure how to correctly wind down a project. I just don't think it's worth to continue. It's too bad I cannot suggest an alternative other than to say that I learned to live with YAML :|
- Mizza 8y ago
  I still use HJSON as my preferred config format. It's more natural to me than YAML or TOML. Thanks for your service!
- pritambaral 8y ago
  > I learned to live with YAML :| You might like StrictYAML[1]. 1: https://hitchdev.com/strictyaml/ https://hitchdev.com/strictyaml/
- user5994461 8y ago
  Damn. You scared me with that title. You're wrong that it's not used by anything important. It's integrated at Major Investment Bank and developers are shipping hjson files every day. They don't actually have a choice to configure and ship their services. It's spreading slowly to more internal stuff as people realize they are better off with HJSON, rather than anything else. It will eventually reach the rest of the bulge bracket within a decade as people move around and pollinate the best stuff. HJSON could be running the global financial market by 2028 or 2038.
  - laktak 8y ago
    Well I'm glad it's useful to you. If you know someone who can help continue the project see https://github.com/hjson/hjson/issues/84 https://github.com/hjson/hjson/issues/84
vorpalhex 8y ago
I hate YAML with a passion - I understand the goals of the project but the whitespacing and awkward syntax is really just too frightfully painful on large configs. JSON by itself is definitely lacking in human friendliness. HJSON and JSON5 were both solutions I liked. TOML is good too, and HCL is ok - but they don't quite serve as that nice drop in replacement that HJSON offered.
- geezerjay 8y ago
  > JSON by itself is definitely lacking in human friendliness. I can't agree with that assertion. As i see it, JSON is practically flawless wrt human friendliness. It's a self-documenting human-readable data interchange language that's even trivial to parse. A lot of people have plenty of ideas about what nice-to-have features they'd like to see but that's just YAML talk that only leads to YAML nowhere.
  - codefined 8y ago
    Not having comments is massively detrimental to most of our configuration use cases. Being forced to replace line-breaks with \n is also really painful for longer strings. HJSON was great at solving both of those.
malkia 8y ago
How many folks are familiar with http://jsonnet.org/ http://jsonnet.org/ - there are two implementations: - One in go - https://github.com/google/go-jsonnet https://github.com/google/go-jsonnet - One in C++ - https://github.com/google/jsonnet https://github.com/google/jsonnet AFAIK, ksonnet is the primary user - https://ksonnet.io/ https://ksonnet.io/ - which to any ex-googler be the more familiar way of dealing with the borg configs. HJSon seems nice, as once in a while how to put a comment in JSON comes, and everyone starts bike-shedding their favourite solution, that leaves lots questions... of compatibility. For example, we tend to use "_comment": "", but I know that's bound to break somewhere, soon or later. There is also https://json5.org/ https://json5.org/
- fajran 8y ago
  We use jsonnet at work to define almost all of our k8s config. With it we can write a base config and extend it to be more environment (prod, staging, integration test) specific. Very helpful to avoid copying and pasting configs to multiple places
ratherbefuddled 8y ago
I've found HOCON to be pretty much exactly what I want for configuration.
jonbodner 8y ago
We used HJSON as the config file format for https://github.com/capitalone/checks-out https://github.com/capitalone/checks-out and it worked out very well. It's a shame that it hasn't caught on, because it fixes the warts in JSON in an elegant way.

24 points by laktak 8y ago

JSON is a serialisation format. In cases where you're writing config, you'd surely be better pushing for something even more human-readable (I want to say YAML but it has some problems, so something along those lines) because the cost of switching from JSON to <anything> is the barrier to entry, so you might as well go for the ideal if you are committing to switch. I guess I just don't see where this fills a gap.

philwelch 8y ago
ini is an underrated config format.
- beaconstudios 8y ago
  I am definitely a fan of INI, but (AFAIK?) it doesn't support structured data beyond simple sectioning.
  - philwelch 8y ago
    Constraints are a good thing ;) You can fake it by having say, dot-delimited keys, but a lot of the complexity of config file formats come from the desire to support arbitrarily structured data when sometimes it's just as easy to fake it, not have it, or even use some templating.
  - cmroanirgo 8y ago
    > it doesn't support structured data beyond simple sectioning Not exactly true (nor completely untrue). Look at your .gitconfig to see an example of how it can shoehorned in. Basically, it uses a .dot notation in a section header to distinguish levels. I wrote an little module a few years back that copes with structure support: https://www.npmjs.com/package/jsinf#the-format https://www.npmjs.com/package/jsinf#the-format
- geezerjay 8y ago
  > ini is an underrated config format. I agree, but the problem with ini is that it isn't a format in the sense that it hasn't been formally defined in a consensual way. Thus the monumental success of TOML as it fills the void that ini left unfilled for decades.

ianbicking 8y ago

I always meant to use hjson somewhere, but never managed to. YAML is so complicated, and JSON is almost fine, except for: no comments, no multiline strings. Quoting keys is tedious but not terrible. Personally I don't mind quoting string values at all. There are places with slightly relaxed JSON, like JSON + comments (e.g. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...). But it's often not well documented, and because these relaxations lack a name there's no commonly accepted set of relaxations. But I guess we should just accept YAML, as it seems to be the standard-that-isn't-json.

bosaisi 8y ago
Try TOML. It's like a better YAML, and seems to be getting some good adoption.
MrTonyD 8y ago
Agree completely. I usually use YAML just so I can document my work using comments. If they added "heredoc" and comments, I think that I would be happy with JSON forever.
geezerjay 8y ago
> no multiline strings I thought that the JSON way of implementing multiline strings was through an array of strings.

zadler 8y ago

Not sure why the author thinks it “deserved” to be more successful? Do they know something that everyone else does not?

laktak 8y ago
Of course it's possible that Hjson was just bad and that is why nobody picked it up. My main mistake though was probably the name of the project. It made a lot of people think that this was supposed to replace JSON.

laktak 8y ago

Not sure how to correctly wind down a project. I just don't think it's worth to continue. It's too bad I cannot suggest an alternative other than to say that I learned to live with YAML :|

Mizza 8y ago
I still use HJSON as my preferred config format. It's more natural to me than YAML or TOML. Thanks for your service!
pritambaral 8y ago
> I learned to live with YAML :| You might like StrictYAML[1]. 1: https://hitchdev.com/strictyaml/ https://hitchdev.com/strictyaml/
user5994461 8y ago
Damn. You scared me with that title. You're wrong that it's not used by anything important. It's integrated at Major Investment Bank and developers are shipping hjson files every day. They don't actually have a choice to configure and ship their services. It's spreading slowly to more internal stuff as people realize they are better off with HJSON, rather than anything else. It will eventually reach the rest of the bulge bracket within a decade as people move around and pollinate the best stuff. HJSON could be running the global financial market by 2028 or 2038.
- laktak 8y ago
  Well I'm glad it's useful to you. If you know someone who can help continue the project see https://github.com/hjson/hjson/issues/84 https://github.com/hjson/hjson/issues/84

vorpalhex 8y ago

I hate YAML with a passion - I understand the goals of the project but the whitespacing and awkward syntax is really just too frightfully painful on large configs. JSON by itself is definitely lacking in human friendliness. HJSON and JSON5 were both solutions I liked. TOML is good too, and HCL is ok - but they don't quite serve as that nice drop in replacement that HJSON offered.

geezerjay 8y ago
> JSON by itself is definitely lacking in human friendliness. I can't agree with that assertion. As i see it, JSON is practically flawless wrt human friendliness. It's a self-documenting human-readable data interchange language that's even trivial to parse. A lot of people have plenty of ideas about what nice-to-have features they'd like to see but that's just YAML talk that only leads to YAML nowhere.
- codefined 8y ago
  Not having comments is massively detrimental to most of our configuration use cases. Being forced to replace line-breaks with \n is also really painful for longer strings. HJSON was great at solving both of those.

malkia 8y ago

How many folks are familiar with http://jsonnet.org/ http://jsonnet.org/ - there are two implementations: - One in go - https://github.com/google/go-jsonnet https://github.com/google/go-jsonnet - One in C++ - https://github.com/google/jsonnet https://github.com/google/jsonnet AFAIK, ksonnet is the primary user - https://ksonnet.io/ https://ksonnet.io/ - which to any ex-googler be the more familiar way of dealing with the borg configs. HJSon seems nice, as once in a while how to put a comment in JSON comes, and everyone starts bike-shedding their favourite solution, that leaves lots questions... of compatibility. For example, we tend to use "_comment": "", but I know that's bound to break somewhere, soon or later. There is also https://json5.org/ https://json5.org/

fajran 8y ago
We use jsonnet at work to define almost all of our k8s config. With it we can write a base config and extend it to be more environment (prod, staging, integration test) specific. Very helpful to avoid copying and pasting configs to multiple places

ratherbefuddled 8y ago

I've found HOCON to be pretty much exactly what I want for configuration.

jonbodner 8y ago

We used HJSON as the config file format for https://github.com/capitalone/checks-out https://github.com/capitalone/checks-out and it worked out very well. It's a shame that it hasn't caught on, because it fixes the warts in JSON in an elegant way.