“Oh, Hooray!” I hear you all shout. “I’ve waited so long to hear Jerry to rant once more about esoteric technical standards!” I’m back, baby! You don’t have to thank me, it’s what I do. (occasionally)
If perhaps you were not looking forward to a technical rant, may I suggest you spend a little time at We Rate Dogs instead. They are awesome, and work hard to make life better for people and animals.
Back to the rant…
How to move information between systems that know nothing about each other is a challenge. The two sides have to agree on how that data is reduced to ones and zeroes to be pumped over a wire, and how the ones and zeroes are interpreted on the other end. In the biz, we call this a transport. It’s a way to move information from one place to another. As long as both sides understand the transport, all is well.
But “all is well” is relative. Some transports are more flexible and precise (and simply faster to encode and decode) than others.
The first serious contender in this space was XML. XML is really complicated, but allows sophisticated layering of the rules for encoding and decoding. But for everyday shifting of data XML is overkill. When you just want to move information between friends, XML imposes a lot of unnecessary overhead. JSON provided a simpler answer.
JSON exists because every web browser supports JavaScript, so a JavaScript-compatible transport made perfect sense. The “JS” in JSON is “JavaScript”.
When the kids were inventing JSON, they could have defined ways to pass arbitrary data as bytes, but they did not. They wanted a simple transport that Javascript could easily decode. JavaScript can’t handle really big numbers, so there was no reason to have JSON solve that. The transport was designed for a very narrow problem: getting data to browser apps written in JavaScript. The JSON builders could have looked past the immediate problem to make a more general transport, but that would have encumbered their own, very focussed standard.
But, like so many standards to fix a specific problem, that standard was embraced unquestioningly as a solution for many cases it was never designed for.
This is why web app development is twenty years behind modern software practices. There is a problem, and the first shitty solution to come along is embraced, and the whole “this is how things work” is promoted so loudly that any better solution is lost in the noise.
But JSON can’t handle really big numbers. JSON can’t handle image data in a compact format. JSON has to turn UUIDs from 16 bytes to a huge-ass string. JSON, actually, is not very good. And there are MUCH faster and more flexible ways to send your info over the wire. JSON is only useful for passing data to and from a browser.
And yet!
You know what makes no sense at all? Using JSON to pass data between cloud services. If there is not a browser on either end of the pipe, JSON is the wrong answer. And yet today I’m dealing with GraphQL, which could have chosen any transport at all to talk to its various parts, and chose JSON.
This is the lingering malignancy of past bad decisions. It never even occurred to the people who made GraphQL to use any transport other than JSON. They knew its flaws, but never considered an alternative. In fact, they never considered that there might BE alternatives; they wrote their specification directly around JSON.
So today I am trying to make my services become subgraphs, and I am grinding my teeth as my tight, well-considered data types are stretched and warped to fit JSON. Bigger, slower, and not type-safe. No modern system should use JSON. But here we are.
Well ! That was quite the education for me, as I squinted at your rant with my recently exfoliated right eye. I think I am moving on to We Rate Dogs! Love you! – Aunt Marie
I would argue it depends on the application, the value of the developer’s time, and the volume of end-user traffic. I used to sweat image optimization, but no client would now pay for my time to make their images “just right” for the application, because bandwidth has become basically N/A for anyone that doesn’t live in ruralia. If JSON is what the dev knows, and they need to learn a whole new transport just to put a calendar on a page more efficiently, I think you have the same problem. Or in server-to-server stuff, if you burn a few gazillion cycles doing something inefficiently but save 10 hours of dev time, because they’re rehashing what they already know and have done 100 times before, then the ROI is positive (presuming chip, cooling and other costs don’t skyrocket, which they could).
The solution to any bad set of standards is one additional standard. But that makes the word “standard” just about meaningless. See also xkcd.
Processor cycles vs. Dev hours is definitely the critical measure. Cycles are cheap. Opus 4.8 is probably setting the exchange rate (artificially right now, but the reckoning will come).
Although client-seconds is another measure. Faster transports between services makes happier customers.
The key in your comment is “on a page”. JSON is well-suited for moving data to a JavaScript client (a browser), where the holes in JSON line up exactly with the holes in JavaScript. That is as fast and as efficient as you are going to get.
Server-to-server, my team has absolutely burned more dev hours – no, dev weeks, trying to make JSON work where Protobuf is strict, well-defined, and type-safe. I won’t give you the litany here of the issues we faced (some absolutely avoidable).
Also with Protobuf the contract between services is clearly defined and documented, and most important of all, it keeps my boss from doing stupid shit.
For Protobuf, “what the dev knows” is “run this command and it will generate everything you need.” Human-readable data formats are very useful for diagnosing problems caused by human-readable data formats, but not much else.
There are alternates to Protobuf that might be better, but already we’re in a different Universe than JSON.