Hacker News Reader

Comment by andrewstuart | Hacker News Reader

Nothing will ever unseat JSON because whilst it's crap, it's good enough.

The toughest competition in the universe is a "good enough" competitor.

JSON is fine for inter-machine communication (like APIs). It's IMO terrible for human-to-machine communication (like configs), which is why there are so many alternatives trying to improve in this space (TOML, YAML, RON, etc.).

For inter-machine communication TLV binary formats are far superior. Simplicity of parsing, efficiency. Can't compete.

JSON still wins because everything already has a JSON parser.

Only when various performance metrics are not important enough to consider alternatives.

If performance matters, TLV doesn't cut it either, you need fixed-offset fields. Self-describing binary formats like CBOR, BSON, bencode, DER, UBJSON, etc fall between two stools, being less hackable than JSON and slower than schema-driven binary formats, which is why they are all moribund today.

Everything has JSON because everything has a web browser with JS these days. Calculation can change if browsers stop shipping or stop shipping with JS.

Dhall is the most interesting alternative because it can be compiled to JSON easily

That's like the least interesting feature from Dhall, and also probably one of the most common features of any new format. Not sure I could mention any even semi-popular format that cannot easily be converted to JSON.

https://dhall-lang.org/

Cool indeed. I wonder how you can supply it with types from the program that consumes the config.

My Gradle config is in Kotlin these days. Kotlin, besides being a full blown prog lang, has nice features for config specs (map/list literals, typed, eDSL syntax). Though it is an enormous dependency (way to big for a project that just needs a config file format).

The bigger Dhall type libraries are usually generated from OpenAPI specs - there is a core package that consumes them.

If your language has an OpenAPI library, you can create a hello-world web app that exposes your configuration object as an HTTP endpoint, and generate Dhall types from that.

After trying both Dhall and Cuelang, I really prefer the latter.

But this turns out to support OP's point. JSON is good enough, and there are many alternatives that we are debating and don't agree on.

So if you have to pick something, and I have to pick something, since we don't agree, we will fallback on JSON.

man, nailed that

Worse is better, yet again.

This may be right for a big distributed open source project or something, but most things I work on are proprietary within companies, and in that case it's easy to just pick something better and standardize on that. My current company is pretty much standardized on yaml, which isn't my favorite, but it's fine and better than json and we don't argue about it much. Things get serialized to json pretty often, but most stuff that is checked in and intended to be human readable is not json. A different company could easily pick cue or whatever else and it would work just as well.

I think this is a neglected point. For application config, the scope over which standardisation pays off is smaller than for data. It can be company-sized. Or language-sized - if all Ruby library use YAML, that's great for Rubyists; if all Java apps use properties files, that's, believe it nor not, pretty great for Java programmers.

Huh, yaml is just all around the worst on any metric. I would much rather stick to xml even.

Like I said, yaml isn't my favorite either, but this is silly hyperbole; xml is way harder for a human to read and write.

JSON is perfectly human readable. Anyone claiming otherwise hasn't seen a binary format.

Where JSON mainly fails as config format is lack of comments. Comment provide help and structure when editing. While allowing to toggle functionality. Which is where trailing commas help.

Binary format is perfectly human readable. Anyone claiming otherwise hasn't seen an encrypted binary format.

Encrypted binary format is perfectly human readable. It's not my fault you weren't born a savant. Anyone claiming otherwise hasn't seen white noise. /cj

Lets spend months replacing a thing that actually currently works with a slightly nicer to read file format with new and exciting bugs?

Use a prettifier plugin in your editor or squint, silly human. Trailing-comma-on-write-annoyance-adjuster, bada-bing, bada-boom. Most of the peeves can be hidden with good tooling. This Ron thing makes sense because of Serde not because it is prettier.

Let's not forget KDL! : https://kdl.dev/

HOCON is a great human-readable alternative to JSON. It's a superset of JSON with lots of cool features that make it both more readable and easier to use.

Here's a rundown of HOCON's main features: https://github.com/lightbend/config#features-of-hocon

I have had great experience with HOCON. I miss it in non-JVM languages.

I would say I've mostly landed on JSON by default and TOML for configs when possible. Otherwise, that ends up being JSON too.

> Nothing will ever unseat JSON because whilst it's crap, it's good enough.

JSON is "secretly" being replaced by JSON5 in quite a lot of contexts. So I'm not sure that this is entirely accurate. The same was said about XML a long time ago and people claimed that XML will never be replaced. Yet today XML is barely used any more. Likewise TOML is showing up in more and more places were previously INI or YAML was the standard.

Of course, all of this depends on your context. It's possible that one's world is all about JSON5, while another person's world is all about XML (yes, still). It all depends on where you work, what FOSS you contribute to, what code you write, what language you use.

TOML for example is extensively used in the Rust world, but if you're doing PHP, you're much more likely to deal with XML or JSON than TOML on a daily basis.

XML had an aura of inevitability, but everyone hated it. That’s why JSON won, it isn’t vile like XML

XML would have been so much more popular if it hadn't had A: namespaces and B: just about the worst imaginable syntax for same.

There is no end-state for formats where one "won" and others "lost". XML "won" in terms of it being used everywhere in the past, JSON "won" in terms of it being used everywhere right now and some other format will have "won" in terms of it being used everywhere in the future.

Formats come and go over time, surely JSON will as well.

JSON5 looks great! https://json5.org/

I wish. But not only this is not well supported, the parsers are usually very slow.

I have never come across anything that actually uses JSON5.

Postgraphile comes immediately to my mind. https://www.graphile.org/postgraphile/smart-tags-file/

JSON5 parsing is unfortunately slower than JSON. Not intrinsically, but JSON.parse/stringify are both natively implemented and highly optimized. If browsers started supporting it, it would take off overnight. I can't tell you how often I've wanted to put comments or not worry about removing the last trailing comma from a list.

It would win for some of the same reasons HTML5 beat XHTML. Ease of use and implicit rules beat pedantic strictness any day of the week. "Programmers are lazy."

You would be surprised how widespread it is across certain ecosystems. Even the apple JSON parser supports it. A lot of the .json config files in the JS/VSCode ecosystem are actually JSON5 files.

JSON5 is specifically for hand-written config files. So it can only be replacing JSON in that context, or?

I didn't know JSON5 existed until this post and from now on will use it everywhere.

Kudos to Asheem and all JSON5 team for building a great product while ignoring the haters [1]

[1] https://aseemk.substack.com/p/ignore-the-f-ing-haters-json5

That's why open source is not enough anymore, we need _lean_ open source, and that stable in time.

Big Tech is based mostly on 2 related scams: planned obsolescence and grotesquely and absurdely massive and complex open source software/standards/protocols.

To protect us against them, is to go to simple but able to do a good enough job and stable in time protocol/standard/open source software/etc. You will need lawyers.

This is common sense, but many seem to lose it... more or less sincerely...

I don't see this intended to unseat JSON. But it can be helpful for local testing and debugging of Rust projects. I wouldn't really expect this for general purpose serialization because JSON is more standard and for inner-app communication you can use something more compact.

I did actually use this in a project because it differentiates between nesting of Option. Particularly we were having some confusion of Some(None) and None and this helped our tests catch more issues. In production we used JSON. Serde makes it trivial for the same code to switch between formats.

While I think (and lament) that you are almost right -- that is, that ridding the world of the foul pestilence that is JSON it will take insanely longer than it should -- I do think it will come a bit sooner than the heat death of the universe.

The reason I think so is that so many JSON users are no longer actually using JSON. Although there are apparently several competing implementations still vying for the name "JSONC", one of those is the non-JSON format that allows comments used by VS Code (among many others), and it is spreading (often inadvertently).

This weakens JSON by diluting the meaning of the term (many users of this "JSON plus comments" think they are using JSON). The end result might be that we standardize on some "JSON+" type name, or that the meaning of "JSON" itself is diluted to include such superior mutations.

Either way is pain in the ass, though, because JSON is a human-readable format (I mean, not really, but in practice), but it is also a machine-to-machine format, so deviation from the spec is certainly unhelpful there.

But we got rid of Latin-1 and SJIS (for the most part), and I have hope that in the fullness of time, we'll get rid of JSON, too. (Probably not with RON, though.)

P.S. Nrwl guys, JSON config files are literally the most painful part of using Nx, and you should consider just using TypeScript, but if not, "VS Code style comments-enhanced JSON" would still be a massive improvement. :-D

I wouldn't be so sure about that, I thought the same about XML in 2005...

Thinking about it, it has 1% to do with the format at 99% to do with various lock-in mechanisms. The explosion of the web and JSON being the standard for JS definitely helped it alot! Protobuf has done pretty well on the backend based on the "won't get fired for copying Google". XML had it's own lock-ins, being the basis of XHTML at that time, and Microsoft had a big fetish for SOAP.

They thought that about XML, and ASN.1, and...

Agreed with this general notion however, I'd argue that unlike a standards body, a big driver for JSON's ascent to defacto standard were the legions of javascript developers working at every layer of a tech stack using it as a low-friction means to an end.

I think it will for config, simply because JSON doesn't support comments and that's really not an optional feature.

But I have tried lots of alternatives and none have as good tooling except maybe XML. Especially for schemas, which I think is really important.

I want JSON5 to succeed but there's no good IDE support really.

I also tried Dhall, which looks promising except they've imported all the super weird stuff from functional languages that are just going to put people off (e.g. the weird leading commas, and very odd way of declaring functions).

I just wrote a little cli that takes JSON input, deserializes it into rust structs, serializes it into my custom binary protocol, sends it to my server I'm developing, and then does the reverse with the reply.

This looks like a nice replacement because it looks like the debug logs of my types. Plus it lets me specify numbers as hex.

Startups competing against an existing, good enough competitor have this problem too.

Reply on news.ycombinator.com