It's text-based, meaning it's incredibly slow to parse.
This is precisely the reason it is used so heavily. Easily readable format to reason about. And incredibly slow is a pretty relative term, when you're waiting on database calls or doing other complex logic that is orders of magnitude slower, who cares how "slow" json parsing is.
It has to be valid UTF-8, meaning it's incredibly slow to validate.
I think being able to embed all sorts of different characters and languages is, again a plus. See argument above about performance.
Its numbers representation is double-precision floating-point, meaning it's incredibly imprecise and limited.
This argument I don't get. I'm pretty sure I might be missing something, but in my experience you can just put a plain old integer and any parser in any language will extract as an exact integer. Nobody is converting a "1" in json into a double/float. Maybe somebody can elaborate and what the author might have actually meant?
So, really, the argument all boils down to, it's slow and wasteful. Well, while that's true I think it's pretty much been established time and time again that Moore's law has made it possible to value programmer time over CPU overhead, to a reasonable extent (i.e. if the overhead you're adding overtakes Moore's law and makes infrastructure particularly expensive). If you have a format that is human readable, easy to understand, and simple, that helps tremendously in software development and it would take order of magnitude performance hits to really make it bad tradeoff (and even the, if you weren't getting a lot of traffic, who would care?), not just 2x or 3x.
We live in a web based world, and that world is fundamentally based on a text based protocol (http) and text based messaging formats. There are plenty of valid and good reasons why it happened the way it did.
*Final Note: I would like to see some empirical evidence to compare the wasted CPU cycles and energy that JSON uses compared to if all messages were sent with msgpack or something like it instead. While my own inclination is that number would be dwarfed by the overall energy used in computation I would prefer to see evidence rather then conjecture if you're going to make a point like that.
> Its numbers representation is double-precision floating-point, meaning it's incredibly imprecise and limited.
Maybe somebody can elaborate and what the author might have actually meant?
I think JSON numbers are not necessarily double-precision, at least I don't think I've ever seen them specifically described this way. In JavaScript, however, numbers are double-precision, there are no real integers in JavaScript. So maybe the author misrepresented JSON numbers because JavaScript numbers are double-precision. But that isn't necessarily the case AFAIK.
Comments
This is precisely the reason it is used so heavily. Easily readable format to reason about. And incredibly slow is a pretty relative term, when you're waiting on database calls or doing other complex logic that is orders of magnitude slower, who cares how "slow" json parsing is.
I think being able to embed all sorts of different characters and languages is, again a plus. See argument above about performance.
This argument I don't get. I'm pretty sure I might be missing something, but in my experience you can just put a plain old integer and any parser in any language will extract as an exact integer. Nobody is converting a "1" in json into a double/float. Maybe somebody can elaborate and what the author might have actually meant?
So, really, the argument all boils down to, it's slow and wasteful. Well, while that's true I think it's pretty much been established time and time again that Moore's law has made it possible to value programmer time over CPU overhead, to a reasonable extent (i.e. if the overhead you're adding overtakes Moore's law and makes infrastructure particularly expensive). If you have a format that is human readable, easy to understand, and simple, that helps tremendously in software development and it would take order of magnitude performance hits to really make it bad tradeoff (and even the, if you weren't getting a lot of traffic, who would care?), not just 2x or 3x.
We live in a web based world, and that world is fundamentally based on a text based protocol (http) and text based messaging formats. There are plenty of valid and good reasons why it happened the way it did.
*Final Note: I would like to see some empirical evidence to compare the wasted CPU cycles and energy that JSON uses compared to if all messages were sent with msgpack or something like it instead. While my own inclination is that number would be dwarfed by the overall energy used in computation I would prefer to see evidence rather then conjecture if you're going to make a point like that.
I think JSON numbers are not necessarily double-precision, at least I don't think I've ever seen them specifically described this way. In JavaScript, however, numbers are double-precision, there are no real integers in JavaScript. So maybe the author misrepresented JSON numbers because JavaScript numbers are double-precision. But that isn't necessarily the case AFAIK.