Goodbye Hjson(hjson.org)
hjson.org
Goodbye Hjson
http://hjson.org/
24 comments
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.
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.
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
> I learned to live with YAML :|
You might like StrictYAML[1].
1: https://hitchdev.com/strictyaml/
You might like StrictYAML[1].
1: https://hitchdev.com/strictyaml/
I still use HJSON as my preferred config format. It's more natural to me than YAML or TOML. Thanks for your service!
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.
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.
> 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.
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.
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.
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.
I guess I just don't see where this fills a gap.
ini is an underrated config format.
I am definitely a fan of INI, but (AFAIK?) it doesn't support structured data beyond simple sectioning.
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.
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.
> 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
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
> 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.
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.
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/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.
There are places with slightly relaxed JSON, like JSON + comments (e.g. 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.
Try TOML. It's like a better YAML, and seems to be getting some good adoption.
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.
> no multiline strings
I thought that the JSON way of implementing multiline strings was through an array of strings.
I thought that the JSON way of implementing multiline strings was through an array of strings.
How many folks are familiar with http://jsonnet.org/ - there are two implementations:
- One in go - https://github.com/google/go-jsonnet
- One in C++ - https://github.com/google/jsonnet
AFAIK, ksonnet is the primary user - 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/
- One in go - https://github.com/google/go-jsonnet
- One in C++ - https://github.com/google/jsonnet
AFAIK, ksonnet is the primary user - 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/
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
We used HJSON as the config file format for 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.
I've found HOCON to be pretty much exactly what I want for configuration.
Not sure why the author thinks it “deserved” to be more successful? Do they know something that everyone else does not?
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.
It's too bad I cannot suggest an alternative other than to say that I learned to live with YAML :|