“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.
