
Hjson, the Human JSON - 56k
http://hjson.org/
======
simonw
JSON plus comments and python-style multi-line strings is great.

The thing where you can leave quotes off strings makes me nervous, especially
the example where the value is HTML with its own embedded double quotes for
attribute values.

Not requiring quotes on strings like that looks like an obvious vector for
injection attacks. I guess Hjson isn't designed to be generated automatically,
but I'd prefer a format that is easy to generate safely.

What I really want is JSON plus comments plus multi-line strings plus relaxed
rules on trailing commas... While maintaining as simple and unambiguous a
parsing model as possible.

~~~
mamikonyana
how about yaml?

[http://www.yaml.org/start.html](http://www.yaml.org/start.html)

~~~
alanh
YAML is more complex that most people tend to realize. (This was brought up in
a 2011 discussion about possibly standardizing a metadata section for Markdown
documents which sadly went nowhere. [1])

Take a look at example 2.11 in the YAML spec [2], for example, and see if you
can make heads or tails of it.

[1]: [https://pairlist6.pair.net/pipermail/markdown-
discuss/2011-A...](https://pairlist6.pair.net/pipermail/markdown-
discuss/2011-August/002232.html)

[2]:
[http://www.yaml.org/spec/1.2/spec.html#id2760395](http://www.yaml.org/spec/1.2/spec.html#id2760395)

~~~
crdoconnor
You don't need most of those features. A pared down YAML with the cruft
removed (implicit typing, flow style, tag tokens, node anchor & references) is
actually pretty simple as well as less "gotcha-y".

~~~
__david__
Sure, but most language YAML parsers support all or most of the spec. That can
be a problem if you aren't expecting it.

~~~
alanh
I believe it has even created security issues. Didn’t Rails have at least one
YAML-based vuln?

~~~
rurban
You need to restrict YAML to SecureLoad, with manually adding allowed typed
and classes.

At least perl doesn't support this, so it's inherently insecure there, but you
can always use YAML::Syck which didn't go this way.

------
joeld42
\- Someone saves data as text with a simple format

\- It works great, lots of people start using it

\- People start adding features to fix annoying things with the format, add
support for binary data, comments, schemas, add more metadata etc..

\- Many versions proliferate, people start writing converters and verifiers

\- A standards committee is formed and write an 800 page spec and 80kloc
reference implementation

\- Eighteen different libraries wrap or reimplement the reference
implementation

\- Someone gets fed up with this nonsense and converts their app to save their
data in a new simple text format.

\- The circle of life continues.

I love this idea and wish json had comments, too, but if you start hitting the
point where JSON is not expressive or fluid enough, that's a hint that it's
probably not the right thing for what you're doing. This variant puts a lot of
work into human-friendly json, but if you're doing a lot of hand-editing of a
file, it should probably not be JSON.

~~~
streblo
Obligatory:
[https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...](https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr)

~~~
cwyers
> Suppose you are using JSON to keep configuration files, which you would like
> to annotate. Go ahead and insert all the comments you like. Then pipe it
> through JSMin before handing it to your JSON parser.﻿

And now you can't roundtrip the comments if for some reason your JSON parser
needs to change something.

~~~
dclowd9901
I would prefer not to inspect json for comments. Something is ambiguous, you
should have a model definition sent along with everything else.

------
bryanlarsen
This spec repeats one of the problems with using YAML as a configuration spec.
To quote: "if your key includes a JSON control character like {}[],: or space,
use quotes if your string starts with { or [, use quotes"

JSON and YAML are interchange formats, not configuration formats. Rather than
than hacking up an interchange format, it's probably better to use something
designed for configuration formats, like TOML.

~~~
stormbeta
JSON is an interchange format, but YAML is pretty obviously meant for
configuration, given the huge emphasis on human readability and editing.

As for TOML, it's a good replacement for mostly-flat INI-style files but the
syntax is really awkward for the kinds of places you'd normally use YAML,
especially nesting lists/maps.

~~~
bryanlarsen
Top line on yaml.org:

What It Is: YAML is a human friendly data serialization standard for all
programming languages.

------
JamilD
Rigidity and consistency are not always bad things. They can help prevent
bugs, security vulnerabilities, and they drastically reduce complexity of
implementation.

JSON might often be too rigid, but I think it's important to note that
"easier" (in that you don't need to learn the syntax) isn't always better.

~~~
IvanK_net
This "easier" format is actually more "complex". JSON can be described with
just a couple of simple rules ([http://json.org/](http://json.org/) ), while
this format adds many new rules (e.g. for doing same things in multiple ways).
The more rules you have, the more things you have to remember, the harder it
is to find the reason of the problem.

BTW. it is very simple to do comments in JSON :) You can just add "comment1" :
"This is my comment", to any object, it will be ignored by software that
processes your file.

~~~
mort96
I kind of like doing comments like this:

    
    
        "#": " my comment"

~~~
ZenPsycho
the problem with that one is that some parsers have a meltdown if they
encounter duplicate keys. _sigh_

------
nikolay
JSON5 [0] is better as unlike Hjson, it doesn't include non-ECMASCript syntax.

[0]: [http://json5.org/](http://json5.org/)

~~~
emodendroket
And yet again no date format. Am I the only person who is ever inconvenienced
by this? It seems like it's so obviously the most glaring flaw with JSON that
I'm surprised nobody wants to fix it.

~~~
rhinoceraptor
Just use ISO 8601?

~~~
emodendroket
Sure, that would be fine. They could also use a totally wacky format, I don't
care. The problem is that without a standard the JSON tools in different
languages don't all agree on how to serialize dates and you end up needing to
deserialize/serialize manually the smooth over the differences. The problem
isn't that you can't represent dates; it's that there is no standard way to do
it.

~~~
_kst_
> The problem isn't that you can't represent dates; it's that there is no
> standard way to do it.

ISO 8601?

~~~
emodendroket
That's not "standard." That's one of many ways that people represent dates in
JSON, because the JSON specification itself does not mandate that you use any
particular representation. If you use it there is no guarantee it will be
recognized as a date on the other end.

~~~
Kapow
What black hole are you sending JSON into where the only way they could know
something is a date is if you use a date type? Why can't that be part of the
data structure you agreed upon in order to communicate in the first place?

~~~
eknkc
Even if there is an agreed on schema, parsers can generate native Date objects
on the recipient if there is a date type. When you deserialize a nested graph
of objects, it's hard to convert each date to an actual date if what you get
is just a string. Makes it a lot easier during integration.

------
ninjakeyboard
I feel like HOCON fills the space pretty well, and has implementations in most
languages now.
[https://github.com/typesafehub/config](https://github.com/typesafehub/config)

But I'm a scala developer so I might be biased.

~~~
twic
I'm not a Scala developer, and I don't think I'd ever heard of HOCON. Has it
seen much adoption outside the Scala community?

------
creshal
What's the difference to / advantage over YAML? When I want a loose syntax
"JSON with comments", I can just use that instead.

~~~
burke
> YAML expresses structure through whitespace. Significant whitespace is a
> common source of mistakes that we shouldn't have to deal with.

> Both HOCON and YAML make the mistake of implementing too many features (like
> anchors, sustitutions or concatenation).

~~~
eterm
But this too has significant whitespace, acting as a comma in separating
properties. (It's not clear whether you can mix commas and whitespace here.)

Also this claims to not need escapes, but it's also not clear how this format
handles a comma or a newline in strings without escaping, do they act as a
comma to separate properties or do they act as natural commas/newlines?

~~~
PuerkitoBio
Only quoteless strings have no escapes, and according to the docs the rule is:

    
    
      > quoteless strings include everything up to the end of the
      > line, excluding trailing whitespace.
    

(edit: formatting)

~~~
eterm
So this

{

    
    
      foo:one,
    
      bar:two
    

}

Parses to "one," because it is a quoteless string?

What about true and false, is false the boolean constant or a unquoted string
"false".

~~~
PuerkitoBio
I posted this in another thread here, but it's documented in the linked page:

    
    
      > A value that is a number, true, false or null in JSON is parsed as a value.
      > E.g. '3' is a valid number while '3 times' is a string.

------
al2o3cr
"Both HOCON and YAML make the mistake of implementing too many features (like
anchors, sustitutions or concatenation)"

YMMV, but if you're aiming for a format that's edited / maintained by humans
things like YAML's anchors and substitution are exactly the features I'd
_want_...

------
brandonbloom
Just the other day I commented complaining about JSON config files without
comments, but now here I am complaining about _three_ ways to write a comment.
OK, I can see two ways: block and line comments. But why two ways to write
line comments? Why start off a new grammar with that added complexity?

~~~
drawkbox
Comments would be nice but it is also nice to keep JSON pure and simple. There
are some other json formats that use comments like jsoncpp but really not
needed.

But, if comments really are needed, another easy way to have comments is have
a file that rides to the side of any json files or docs. Sometimes we use a
markdown/text file next file.json -> file.json.md / file.json.txt to describe
overall or a file.meta.json that has comments per key. This is only needed
sometimes for physical files. If json is from the server, commenting can be
done there or in docs if needed.

~~~
brandonbloom
The notion that comments are neither simple nor really necessary is completely
bonkers to me, or anyone else who has implemented a lexer or tried to debug an
undocumented config file.

------
jaybuff
Ah, yes, the trailing comma in a list, which I like to refer to as the
"Silicon Valley Comma"

[ "a", "b", "c", ] // the silicon valley comma

~~~
function_seven
If that's the Silicon Valley Comma, what do you call this?

    
    
        [
           "an
         , "array"
         , "of"
         , "things"
        ]
    

Because I have an irrational hatred of that style. (Yes, I know the purported
benefits when diffing files, I don't care :P)

~~~
cheapsteak
That's not as good as the SVC because you'll still get unnecessary diffs when
prepending to the list

SVC allows you to both prepend and append without adding extra diffs

------
o_____________o
CSON?

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

\- [https://github.com/groupon/cson-parser](https://github.com/groupon/cson-
parser)

------
rhapsodic
Looks like a solution in search of problem, to me. JSON is designed to be
machine-readable, and to the extent that I actually _need_ to human-read JSON,
which is not that much, I don't find it all that difficult.

------
xaduha
Standards are better when they are followed. Chicken and egg problem, these
alternatives are DOA because they are not going to be popular.

The only reason JSON is popular is because of Javascript. And the only reason
Javascript is popular is because of the browsers and their history.

------
wwwtyro
I've used with great results in my procedural planet generator[1]. It's very
forgiving, so made writing a "UI" with lots of complicated controls very easy
for me.

[1] [http://wwwtyro.github.io/planet-3d/](http://wwwtyro.github.io/planet-3d/)

~~~
baq
nice little project you've got there :)

------
partycoder
JSON parsers are not really slow. JSON is simple enough that allows multiple
implementations for parsers and easy adoption. But HJSON additions have some
serialization cost overhead.

Because of this eventually you will need to convert your HJSON to JSON prior
to deploying, and that would make things slower. You will be dealing with 2
formats instead of one.

Then, do you really believe that adding all this syntactic "features"
(overhead) will make it less error prone? It will make it more error prone
because it has more things to consider!

~~~
true_religion
It's supposed to be used for config files like package.json and friends in the
javascript world.

It's going to be parsed essentially once---startup.

~~~
partycoder
In that regard I prefer HOCON.

------
zbjornson
Oy, someone loves yaml...

I'm quite happy using a preprocessor like [0], which keeps the great
simplicity of JSON and just allows comments.

[0] [https://www.npmjs.com/package/strip-json-
comments](https://www.npmjs.com/package/strip-json-comments)

~~~
creshal
> Oy, someone loves yaml...

I don't, actually, I use preprocessors too¹, but since they're not always an
option, I'd rather recommend yaml than have yet another pointless config file
language needlessly fragment the market.

¹: Thankfully it's rather trivial in python:
[https://github.com/creshal/yspave/blob/master/yspave/pave.py...](https://github.com/creshal/yspave/blob/master/yspave/pave.py#L33)

------
DominoTree
"Helps reduce errors" \- you're really trading errors for other errors - your
behavior is now more ambiguous with more edge cases, but look, you don't have
to place quotes around strings! (except when you still do)

------
mtalantikite
Can someone explain why people want to use a data-interchange format like JSON
for configuration files, rather than using a configuration file format like
TOML? I've never understood why people want to use JSON for config files.

~~~
stormbeta
I agree about JSON, but I can't say I understand the logic behind TOML.

I know it's supposed to be a config format, but it only seems to make any
sense for INI-like configs that are little more than a flat key-value map.

The places I see people using JSON/YAML/etc for config are much more likely to
have nested structures that would be extremely awkward to represent in TOML. I
think YAML was on the right track, and if you ignore the messier parts of the
spec it works pretty well.

~~~
mtalantikite
I was mainly using TOML as an example of a config format in contrast to JSON,
I wouldn't say it's definitely the answer. Nesting is possible with TOML, but
I'd agree that it could get pretty awkward depending on your needs:
[https://github.com/toml-lang/toml#array-of-tables](https://github.com/toml-
lang/toml#array-of-tables) for example.

I personally don't mind YAML all that much either, although the spec is pretty
large.

------
ebbv
This abandons a lot of principles of JSON that are there to avoid ambiguous
situations. The small benefits don't seem to outweigh the snake pit you're
jumping into.

------
kennell
It has always bothered me that the JSON standard does not allow for comments.
Especially when you want to annotate some sample response/request.

~~~
andreynering
It's just a hack, but you can write a comment in a key that is supposed to be
ignored:

    
    
      {
          "__comment": "The following config does...",
          "key": "value"
      }
    

But I agree that it is not much intuitive.

~~~
spriggan3
JSON isn't semantic so there is no need to put __ before comment, it's not
like it's meta or something. It will still be parsed and processed by the JSON
parser, which is a waste of computer cycle.

~~~
oconnor663
It's kind of a future-proofing thing. If you put a field called "comment" in a
JSON blob, especially one in a format you don't control, you run the risk that
future versions of the format will define the "comment" field and give it
actual meaning. A crazy prefix makes this at least slightly less likely.

------
tacone
To be honest: relaxed formats usually bring a lot of glitches to keep in mind.
It's probably easier to use stricter specifications.

Take YAML, it looks pretty natural at first sight, but has a virtually
infinite list of gotchas.

~~~
crdoconnor
>has a virtually infinite list of gotchas.

That's why I wrote this:

[https://github.com/crdoconnor/dumbyaml](https://github.com/crdoconnor/dumbyaml)

YAML is far better with explicit typing and flow style, tag tokens and node
anchors/references removed.

------
fibo
It already exists YAML. Also cson it is worth to look at.

~~~
rhinoceraptor
I find YAML/cson very difficult to read.

------
jordache
the json spec is pretty easy to follow, even for a human coder. this is
overkill imo

~~~
jordache
In fact, reading the doc for this takes longer than the reading the JSON spec.

------
drewm1980
Shouldn't we keep our format specs simple and strict, and relegate aesthetic,
and typo-correction stuff to the editor?

i.e. something with aspects of clang-format (which tries hard not to change
the meaning of your code even if it's broken), and the aggressive
autocorrection necessary to make typing on a touchscreen work?

I suppose there are converters from this to json, though, so maybe this is
just a better specified way of converting keypresses from monkeys into
something with well defined structure...

------
overcast
Honestly, I thought JSON was already very human readable/writable.

~~~
rymohr
JSON _is_ very readable/writable... to programmers. Most humans aren't
programmers though.

If you showed JSON to someone on the street they could probably understand the
gist of it (if pretty printed). Good luck asking them to write it.

~~~
orcasauce
Your argument is a layman can't puzzle out JSON easily, but do you think hjson
is any better? Syntactically it's core seems to just be QOL improvements over
writing JSON by hand. It isn't any more intuitive from my perspective. In
fact, in many cases it seems less intuitive by offering a greater number of
ways to do the same thing.

~~~
rymohr
I agree completely. If you're going for human, you need to go a lot further
(which is what I've tried to do with HONEY [1]).

[1]: [https://github.com/honey/honey](https://github.com/honey/honey)

------
ant6n
"Trailing commas are ignored." This is the most important :p

------
RangerScience
Hi! I like what you've made. I have been working on something similar,
although the Github is _massively_ out of date and was never complete to begin
with:
[https://github.com/narfanator/YAMLite](https://github.com/narfanator/YAMLite)
(Also, I'm renaming it nowish on the up-to-date version).

This parser handles YAML, JSON and XML. Interestingly, many of the features
HJSON has, this has, by virtue of it being easier to implement during the
parsing stage.

The part I'd draw your attention to - and the part that I think warrants the
most discussion - is the resulting data structure. I mostly can't tell what
the structure is of the HJSON C# object - it looks like it does most of what I
wanted to change about the existing C# JSON parsers, but maybe not all?

------
kbenson
This feels like a project that had a core idea that was good and justifiable
(we'll take some of the common JSON mistakes such as extra commas and most
asked for features sub as comments) and then felt the need to keep throwing in
features to justify its existence, and now it's lost sight of its original
goal.

This can't even be parsed natively by major JavaScript implementations, so is
it really JSON at all? Actually, I think that's the root of my complaints,
that it's associating itself with JSON while clearly diverging from what was
important originally in JSON. At this point it's just some incompatible format
leveraging the JSON name. I think most my criticisms would be ameliorated if
it was just some other JSON-similar format with a different name.

------
aeturnum
This looks pretty great.

We've been looking for a replacement configuration format over our ancient ini
files and had rejected JSON for TOML because TOML allows comments (and man,
can comments be useful in configuration files). This looks like a nice medium-
long term alternative.

------
Gedrovits
Congratulations, you've created something YAML-like, non-safe data structure.

------
sickbeard
I don't understand. doesn't commenting ruin the whole point of a human
readable format? If you have to add comments, it means you need to communicate
something that can be done in more concise way.

~~~
baq
what?

comments are the most important factor of 'human-readability' by far. without
them you can't e.g. explain what a particular key does, what is it's default
value (if any), or perhaps the most important thing - you can't even put a
link to the documation!

~~~
sickbeard
what does 'human-readability' mean? JSON is data-transmission format that is
human readable.. which is why it happens to be more popular than XML (or SOAP)
because you can read the data and see the data.

It's not meant to transmit context (i.e. it's useless and that's what
documentation is for).

------
erez
Human-readable json would've been a great idea, if it wasn't for the fact that
json was NOT MEANT TO BE HUMAN READABLE.

It is meant to be generated by a machine and not created by hand, neither it
should be readable by humans, only parse-able by a computer.

Treating your data interchange/serialization/configuration/markup formats as
languages that should be human readable/writable is a cardinal sin of any
person or company that engages in such practices.

------
jbergstroem
Just wanted to bring libucl into the game in case you are exploring json-like
syntax: [https://github.com/vstakhov/libucl#improvements-to-the-
json-...](https://github.com/vstakhov/libucl#improvements-to-the-json-
notation)

In my eyes pretty much the perfect configuration library and syntax. Nginx-
alike, number suffixes (1min, 2gb, ..), macros, variables, includes with
priority, etc. Boom! Problem solved.

------
Zardoz84
And i should remember SDLang that now have a few years and reference
implementations on Java, C# and Dlang . I don't see why we need reinvent the
wheel again and again...

[https://github.com/Abscissa/SDLang-D/wiki/Language-
Guide](https://github.com/Abscissa/SDLang-D/wiki/Language-Guide)

------
paulddraper
> Significant whitespace is a common source of mistakes that we shouldn't have
> to deal with.

...except you just made it significant.

This is JSON.

    
    
        {"a":1,"b":2,"c":3}
    

This is Hjson after applying the mods:

    
    
        {a:1b:2c:3}
    

....oh, it turns out Hjson actually _does_ have significant whitespace.

------
roosterjm2k2
Where is this drive to create dumb languages coming from? I dont mean dumb in
the opinionated way, i mean, dumb in the way of "its hard to write proper code
that follows rules, quoting and commas are hard" ... ... ... if quotes, commas
and escaping is hard for you, you dont need to be an engineer....

------
herpityderp
This looks cool, but their characterization of YAML is disingenuous

    
    
        YAML expresses structure through whitespace. Significant
        whitespace is a common source of mistakes that we
        shouldn't have to deal with.
    

since every code editor ever used will take care of this for you.

------
skybrian
Nice idea. A nit: making trailing whitespace significant (rather than
stripping it) seems like a bug.

------
blueadept111
The Jaunt JSON parser (Java) was my solution to this problem. It can handle
arbitrarily dirty data, including missing quotes or using semicolons instead
of quotes, missing quotes, etc.

[http://jaunt-api.com](http://jaunt-api.com)

------
Ericson2314
Grammars people! If you don't provide it / promote it, I assume your "nice
simple thing" is neither obvious nor thought-through. Sorry.

Help me with my list of trendy things that took or are taking way to long to
get a grammar: docopt, semver...

------
dukoid
There is also HUTN already: [https://epsilonblog.wordpress.com/2008/09/15/new-
in-hutn-071...](https://epsilonblog.wordpress.com/2008/09/15/new-in-hutn-071/)

------
Murk
Comments, readability plus typabiliy where one of the main reasons I recently
chose YAML for a configuration file. It seems YAML is a bit unloved these
days, perhaps because it is more difficult to parse fully.

YAML references also proved useful in my use case.

------
joelthelion
This is overkill, but someone PLEASE add comments to the next iteration of the
json spec.

------
stock_toaster
There is also libucl[1] which is kind of json like. FreeBSD is apparently
starting to use of it for a few things.

[1]: [https://github.com/vstakhov/libucl](https://github.com/vstakhov/libucl)

~~~
cyphar
I thought it looked cool when they said "nginx-like". But then I remembered
that nginx has annoying string semantics and converts things to arrays in odd
circumstances.

------
anthay
Off topic, but related: I made a simple data-serialisation file format based
on S-expressions, which may be of interest to some:
[http://loonfile.info/](http://loonfile.info/)

------
rymohr
HONEY was my take at the same problem. Still brainstorming on this one and not
used in production yet.

[https://github.com/honey/honey](https://github.com/honey/honey)

------
emodendroket
I'm not using a nonstandard JSON extension unless it implements a standard
freaking date format. I also don't think bare strings are necessarily a great
idea since they lose implicit type information.

------
draegtun
Here's a previous HN discussion on Hjson -
[https://news.ycombinator.com/item?id=8432678](https://news.ycombinator.com/item?id=8432678)

------
dasmith91
So it's YAML with all the cruft of JSON thrown back in?

~~~
rurban
Nope, just a readable JSON. YAML does much more, for many too much.

------
teen
It's almost as if you're reinventing protobufs. XD

------
amelius
Is "undefined" part of json? Imho it should be.

~~~
svachalek
If the key is not present, the value is "undefined" in JS. "null" is a
supported value in JSON, to explicitly mark something as nonexistent.

For me the biggest problem with JSON is lack of full floating point support,
i.e. NaN, +-Infinity, -0.

~~~
amelius
You can stringify an object containing a property with an undefined value.
Imho, parsing that back should give exactly the same data structure.

------
curryhowardiso
Soon: Situation: there are 15 competing standards.[1]

[1]: [https://xkcd.com/927/](https://xkcd.com/927/)

------
asb
Also in this space, Jsonnet is well worth a look
[http://jsonnet.org/](http://jsonnet.org/)

~~~
wstrange
+1

jsonnet gives all the benefits of hjson - but also provides more powerful
templating features

------
pekk
YAML's problem is not "significant whitespace" which really isn't a major
cause of mistakes.

------
joejev
so in this language these all do the same thing:

abc "abc" abc, "abc",

How does increasing the scope simplify things? Defining correct as "crashing
less often" is a really bad idea, data formats _should_ be strict.

------
educar
Possible bug: duplicate keys are not flagged as errors (in the demo atleast)

------
slantyyz
This looks a lot like like CSON but with better comment support.

------
liotier
> Let's make quotes for strings optional as well.

This will end in tears.

------
cammil
"less mistakes" -> "fewer mistakes"

------
msane
Seems like it would be slower to deserialize.

------
pas256
JSON for humans is called yaml.

------
b34r
I'd rather just use YAML.

~~~
rurban
YAML is insecure by default, JSON secure by default.

There are not many secure transportation formats, JSON being one of the few.
And JSON can be parsed much faster and easier than YAML, with its types,
cyclic references and classes.

------
dorfsmay
No include :-(

~~~
dorfsmay
Is there an include functionality I missed, or do people think config file
shouldn't have includes?

------
OJFord

        > , less mistakes, 
    

Does someone have a rather subtle sense of humour, or is that a genuine
mistake?! (fewer*)

------
throwaway2093
Worst name ever. I'm not even joking... Perhaps it would be less offensive if
the last three letters didn't spell the word "SON."

This seems pedantic, I agree, but thus is the world we live in...

Might I suggest "Human Readable JSON."

~~~
bshimmin
I must be having a stupid day - what is offensive about this name?

~~~
J_Darnley
I think it must be playing off the complaints about the Brotli compression
algorithm using "bro" as a file extension. "Bro" and in this case "son"
implying some sort of patriarchal dominance over computing.

In short: a joke.

