
Goodbye Hjson - laktak
http://hjson.org/
======
laktak
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 :|

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

------
beaconstudios
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
ini is an underrated config format.

~~~
beaconstudios
I am definitely a fan of INI, but (AFAIK?) it doesn't support structured data
beyond simple sectioning.

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

------
ianbicking
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...](https://developer.mozilla.org/en-US/docs/Mozilla/Add-
ons/WebExtensions/manifest.json)). 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
Try TOML. It's like a better YAML, and seems to be getting some good adoption.

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

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

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

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

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

