Welcome to the world where everyone is wasting time and space on JSON encoding rather than using some sensible serialization protocol that can handle raw bytes.
We’ve squandered almost all of the advancements.
And the wire size is not that be - first, because most messages are small anyway (unless somebody is doing something stupid like sending files via json), and second, because HTTP compression is there and it works great for text formats like JSON.
And people are surprised software keeps being slow despite increase in compute resources. This is insane.
Yes, there is a little more effort needed for the engineers there. But ya know, if the inputs and outputs of a thing are actually DOCUMENTED and the schemas are available, it's not some massive reverse engineering feat :P
(Okay, maybe you're stuck doing something in a niche environment where handy protocol/format libraries aren't available to you; MATLAB for Microcontrollers or something. But if you're there, you're probably having fun dealing with all the nuances of implementing an efficient and safe recursive unicode text serialiser/serialiser for a format line JSON anyway :P)
Also if you're going the fairly standard route of "web API over HTTP", the protocols give us way more options readily available for much more efficient streaming of binary data.
It's not "wasting time" to teach devs that there are better ways of doing stuff. base64 encoding mp3s into JSON strings strikes me as "junior dev given 2 weeks to quickly implement something without somebody there to review and suggest alternative ways of doing stuff".
Everything you listed is an external dependency in Javascript/Python, base64 is baked in, everyone gets it, everyone's done it.
If you want better interchange you should be pushing it to be included along b64 at the language level not trying to get every dev to include extra dependencies at either side of the exchange.
Oh, absolutely. JavaScript Object Notation became a defacto standard purely because js could parse it natively. Then `json` was adopted as part of the standard python libraries, within PHP, etc... Once upon a time, even stuff like base64 encoding/decoding required someone to write the code for it. Agreed, it requires pushing to get useful stuff into "batteries included" stdlibs.
We're using JavaScript Object Notation because.... Isn't the name quite telling? :-)
Also, if any, an external JSON file should be parsed, not the files themselves.
In my country, no one of these 'self-called engineers' wouldn't even earn a trade/vocational degree. Legally they wouldn't even be engineers.
There's an alternative world where everyone is performance oriented and those Rabbit devices don't run for five hours but for five days on modern batteries. Let's be real the thing is basically a Tamagochi, it should cost 50 bucks and run on chips from 2010.
If we're really honest it should run on Tamagotchi-era hardware.
Like mp3s?
But that’s exactly the complaint the GP was making here: That mp3s are being base64 encoded rather than using a transmission protocol that handles raw bytes.
So despite your counter argument, you actually agree with the GP.
There seems to be a common trend of people writing "JSON APIs" thinking that every other part of HTTP is off-limits.
The elegant thing about MIME is it allows multiple encodings and cross-references, so you can have your HTML and the images displayed in the HTML both optimally encoded in the same document, which was handy back in the time when HTML emails were taking off and marketing insisted that the fancy image signature they designed had to show every time, even when the person was reading the email offline…
Of course back then we had to encode the image in base64 anyway because of non-8-bit-clean email servers. But I digress and will go back to my rocking chair.
I have no idea which is best. Frankly it seems like there are too many choices.
Probably MessagePack, since it is JSON-like and I've actually heard of it.
I'm not sure what Avro is doing, but as a rule schema enables you to have less overhead, rather than more. The main advantage of MessagePack over schema-based formats is that it's dead-simple and mostly compatible with JSON. Schema-based formats usually need either a code generator or maintaining an annotated version of your data classes and making sure they match the schema.
(Of course, with JSON or MessagePack you might still end up using a serialization library and something like JSON Schema).
Hopefully people come around but I doubt it.