Hacker News Reader

Comment by rock_artist | Hacker News Reader

I feel few points weren’t addressed in the article.

1. Size, biggest problem with JSON can happen when things gets too big. So here other formats might be better. Yet, as a reminder JSON has the binary version named BSON.

2. Zero batteries. JSON is readable by humans but also almost self explanatory format. Most languages has built in or quick drop in for json. Still, it’s easy to implement a limited JSON parser from scratch when in need (eg. Pure on func in C on a tiny device).

Working with Protobuf and MsgPack in the past, You have much more tooling involved especially if data passes between parts written in different languages.

3. Validation, JSON is simple. But there are solutions such as JSON Schema.

View on HN

BSON is not simply a binary encoding of JSON.

It is a JSON superset with binary encoding, created by MongoDB. (And there is even a JSON encoding of BSON, called extended JSON.)

AFAIK there is no widely adopted binary pure adaptation of JSON. (There are application-specific storage formats, like PostgreSQL JSONB, or SQLite JSONB.)

——-

Moreover, JSON is relatively compact. BSON or other self descriptive binary formats are often around the same size of JSON. MessagePack aggressively tries to be compact and is, depending on the data. BSON doesn’t try to be compact, rather it improves the parse speed.

CBOR [0] is probably the closest to a widely adopted "pure" adaptation of JSON. It is still technically a superset of JSON, but it tries to be closely matched and frequently cross-references the JSON specs directly, especially because it is also an IETF tracked standard like JSON, and in so far as widely adopted is concerned is included in web standards like WebAuthn today. (For instance, you can't handle Passkeys without some amount of CBOR. The presumed next steps to wider adoption now that all browsers have internal CBOR encoders/decoders would be to add a web platform JS API for it as well.)

However, yes, JSON compresses extremely well even in ancient gzip, but especially in Brotli, and desiring compaction of your API responses alone isn't necessarily the best reason to prefer a binary encoding of JSON to just using JSON and letting compression do its thing.

[0] https://www.rfc-editor.org/rfc/rfc8949.html

> JSON compresses extremely well even in ancient gzip

Correct. MessagePack comes out significantly ahead for small messages, otherwise it's nearly a wash.

> CBOR is probably the closest to a widely adopted "pure" adaptation of JSON

It adds (1) binary data (2) numeric variants including big integers (3) timestamps (4) tagged/semantic types.

I.e. it adds quite a bit. That's not necessarily a bad thing. Browser implementation would be great, but I'm skeptical.

Compressed jsonlines with strong schema seems to cover most cases where you aren't severely constrained by CPU or small message size (i.e., mostly embedded stuff).

Reply on news.ycombinator.com