Yes, this is not too rare to see base64 images in JSON but I won't recommend that.
You gain back most of the base64 overhead when you compress it though. It's slower but probably often worth it if the alternative is few more async HTTP queries that you would only fetch once.
To answer seriously, my parent comment is a joke, JSON is a simpler format that maps better to most programming languages internal memory representations. Developers tend to prefer JSON’s simplicity over XML.
> most programming languages internal memory representations
Often heard wrt JSON but incorrect. It maps to the primitive types in JavaScript. But almost all programming languages treat floats and integers different, make distinction between char and strings and many have some form of date/time. JSON has neither.
In that direction, XML is much closer since every node is a triple (name, value, attributes) so can have type info, json is a tuple. And Protobuf, while not popular, gets this completely right.
I think it's too risky to treat numbers in JSON as something else than IEEE754 64bits floats. But yes, JSON is small and doesn't do datetimes, char, comments, and a million other things XML does.
But you don't need to think much about memory representation when you parse a JSON, and the developer experience is a lot more pleasing than browsing a XML tree. That what used to matter.
If this is intended for reading and writing by humans, then JSON doesn't cut it since you don't get comments (and perhaps also because of the weirdness of 64-bit floating-point values). Plus, XML is more "structurally nuanced". I suppose JSON is simpler to parse, but it's a trade-off of features, it's not like one is bad and the other is good.
So you compress a format that inflates binaries with 30%?
That not only ends up larger than "just the binary", it also eats a lot of extra CPU to (de)compress AND encode-decode.
This idea is novel, but wasteful.
(edit: I thought you were serious, so I answered serious. You were not ;)
Yes, this is not too rare to see base64 images in JSON but I won't recommend that.
You gain back most of the base64 overhead when you compress it though. It's slower but probably often worth it if the alternative is few more async HTTP queries that you would only fetch once.
Why would zipped JSON be fundamentally superior to zipped XML?
To answer seriously, my parent comment is a joke, JSON is a simpler format that maps better to most programming languages internal memory representations. Developers tend to prefer JSON’s simplicity over XML.
> most programming languages internal memory representations
Often heard wrt JSON but incorrect. It maps to the primitive types in JavaScript. But almost all programming languages treat floats and integers different, make distinction between char and strings and many have some form of date/time. JSON has neither.
In that direction, XML is much closer since every node is a triple (name, value, attributes) so can have type info, json is a tuple. And Protobuf, while not popular, gets this completely right.
I think it's too risky to treat numbers in JSON as something else than IEEE754 64bits floats. But yes, JSON is small and doesn't do datetimes, char, comments, and a million other things XML does.
But you don't need to think much about memory representation when you parse a JSON, and the developer experience is a lot more pleasing than browsing a XML tree. That what used to matter.
If this is intended for reading and writing by humans, then JSON doesn't cut it since you don't get comments (and perhaps also because of the weirdness of 64-bit floating-point values). Plus, XML is more "structurally nuanced". I suppose JSON is simpler to parse, but it's a trade-off of features, it's not like one is bad and the other is good.