Feels like a CBOR ad to me. I agree that most techs are familiar with XML and JSON, but calling CBOR a "pivotal data format" is a stretch compared to Protobuf, Parquet, Avro, Cap'n Proto, and many others: https://en.m.wikipedia.org/wiki/Comparison_of_data-serializa...
The fact that the long article misses to make the historical/continuation link to MessagePack is by itself a red flag signalling a CBOR ad.
Edit: OK, actually there is a separate page for alternatives: https://cborbook.com/introduction/cbor_vs_the_other_guys.htm...
Notably missing is a comparison to Cap'n Proto, which to me feels like the best set of tradeoffs for more binary interchange needs.
I honestly wonder sometimes if it's held back by the nameā I love the campiness of it, but I feel like it could be a barrier to being taken seriously in some environments.
> I feel like it could be a barrier to being taken seriously in some environments.
Working as intended. ;)
Have to agree. I've heard of every format you mentioned, but never heard of CBOR.
I first heard of it while developing a QR code travel passport during the Covid era... the technical specification included CBOR as part of the implementation requirement. Past this, I have not crossed path with it again...
I would agree their claim is a bit early, but I think a key difference between those you mentioned and CBOR is the stability expectation. Protobuf/Parquet/etc are usually single-source libraries/frameworks, which can be changed quite quickly, while CBOR seems to be going for a spec-first approach.
CBOR is just a standard data format. Why would it need an ad? What are they selling here?
If I adopt a technology, I probably don't want it to die out. Widespread support is generally good for all that use it.
A lot of people (myself included) are working on tools and protocols that interoperate via CBOR. Nobody is selling CBOR itself, but I for one have a vested interest in promoting CBOR adoption (which makes it sound nefarious but in reality I just think it's a neat format, when you add canonicalization).
CBOR isn't special here, similar incentives could apply to just about any format - but JSON for example is already so ubiquitous that nobody needs to promote it.
Love or hate JSON, the beauty and utility stem from the fact that you have only the fundamental datatypes as a requirement, and that's it.
Structured data that, by nesting, pleases the human eye, reduced to the max in a key-value fashion, pure minimalism.
And while you have to write type converters all the time for datetime, BLOBs etc., these converters are the real reasons why JSON is so useful: every OS or framework provides the heavy lifting for it.
So any elaborated new silver bullet would require solving the converter/mapper problem, which it can't.
And you can complain or explain with JSON: "Comments not a feature?! WTF!" - Add a field with the key "comment"
Some smart guys went the extra mile and nevertheless demanded more, because wouldn't it be nice to have some sort of "strict JSON"? JSON schema was born.
And here you can visibly experience the inner conflict of "on the one hand" vs "on the other hand". Applying schemas to JSON is a good cause and reasonable, but guess what happens to JSON? It looks like unreadable bloat, which means XML.
Extensibility is fine, basic operations appeal to both demands, simple and sophisticated, and don't impose the sophistication on you just for a simple 3-field exchange about dog food preferences.
Odd that the XML and JSON sections show examples of the format, but CBOR doesnāt. Iām left with no idea what it looks like, other than ābuilding on JSONās key/value formatā.
There's an example in the "Putting it Together" section, showing JSON, a "human readable" representation of CBOR, and the hexidecimal bytes of CBOR.
https://cborbook.com/part_1/practical_introduction_to_cbor.h...
I'm assuming, since it's a binary encoded, the textual output would not be something you'd like to look at.
Why? Iām comfortable reading 0x48 0x65 0x78 0x61 0x64 0x65 0x63 0x69 0x6D 0x61 0x6C
With a table explaining what the byte codes mean? Absolutely I want to see that.
People look at TCP packets all the time.
In which format? As a list of 1s and 0s; in hex? TCP or IP if I just pasted the textual version of any binary data id captured without some form of conversion it's not good to look at. Especially if it's not accompanied by the encoding schema so you can actually make sense of it.
Erlang / Elixir has amazing support for ASN.1! I love it.
https://www.erlang.org/doc/apps/asn1/asn1_getting_started.ht...
https://www2.erlang.org/documentation/doc-14/lib/asn1-5.1/do... (https://www2.erlang.org/documentation/doc-14/lib/asn1-5.1/do...)
I am using ASN.1 to communicate between a client (Java / Kotlin) and server (Erlang / Elixir), but unfortunately Java / Kotlin has somewhat of a shitty support for ASN.1 in comparison to Erlang.
ASN.1 while complex has really seems to be a step up from those (even if older) in terms of terseness (as binary encoding) and generality.
Yes, but that comes from the telecom world. Hence thanks to NIH, that wheel must be reinvented.
I wish browsers would support CBOR natively so I could just return CBOR instead of JSON(++speed --size ==win) and not have to be concerned with decoding it or not being able to debug requests in dev console.
JSON + compression (++speed --size ==win)
your server can do this natively for live data. your browser can decompress natively. and ++human-readable. if you're one of those that doesn't want the user to read the data, then maybe CBOR is attractive??? but why would you send data down the wire that you don't want the user to see? isn't the point of sending the data to the client is so the client can display that data?
That is true. Basic content encoding works very well with json but that still means there is the compression step, which would not be necessary with CBOR as it is already a binary payload. It would allow faster response and delivery times natively. Of course, we are talking few ms, but I say why leave those ms on the floor?
I guess i'm just shouting at the clouds :D
It's still not attractive to hide data from the user. Unless it's encrypted, the user can read it.
CBOR is when you need option for very small code size. If you can always use compression, CBOR provides no significant data size improvement over JSON.
With small code size it beats also BSON, EBML and others.
Or compute. Compression isn't free, especially on power constrained devices. At scale power and compute also have real cost implications. Most data centers have long been using binary encoding formats such as protobuf to save on compute and network bandwidth. cbor is nice because it's self describing so you can still understand it without a schema, which is a nice property people like about json.
Doesn't capn proto win hands down on compute?
I haven't used it, but I thought that was the big claim.
This is a link to just one section of a larger book. The next section compare CBOR with a number of other binary storage format, such as protobuf.
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.