It's also right that JSON contains nothing regarding hypertext within its data type (ignoring JSON-schema) and is therefore a weird choice for the web and REST, where hypertext is fundamental.
It's easy to consume with Javascript, which is where most JSON probably ends up.
Ultimately though, something I've learned over the years is that you can either "go with the flow" and do things the way most people are, or you can try and do things your own way. Unless you're Microsoft or Google or something though, mostly, you don't have enough resources to do everything your own way, so you have to strike out on your own only where it really counts. Erlang does that in a number of places already, for sensible reasons - it's part of what makes the language so good at some things. However, fighting JSON is likely one of those Don Quixote battles that's not really going to get you much outside of some very specific contexts.
I don't disagree, but none of the comments given are otherwise false.
I've worked on real-time bidding software where the incoming protocol got changed from JSON to protobuffs. Just doing that made bandwidth costs go down majorly, CPU usage more than halved, and response times got cut.
When the question becomes "easy" vs. "good", always picking "easy" isn't very nice.
You were definitely working in a "very specific context"!
Also, I think that you have to consider how a company grows: JSON is simple to get started with. It's a good default - pretty much anyone can consume it very easily. As you explore your problem space and iterate and improve, you may realize it's not good enough. Fair enough - that's a good time to switch. But many people never reach that point, and will happily continue with JSON for a long time.
Comments
It's easy to consume with Javascript, which is where most JSON probably ends up.
Ultimately though, something I've learned over the years is that you can either "go with the flow" and do things the way most people are, or you can try and do things your own way. Unless you're Microsoft or Google or something though, mostly, you don't have enough resources to do everything your own way, so you have to strike out on your own only where it really counts. Erlang does that in a number of places already, for sensible reasons - it's part of what makes the language so good at some things. However, fighting JSON is likely one of those Don Quixote battles that's not really going to get you much outside of some very specific contexts.
I don't disagree, but none of the comments given are otherwise false.
I've worked on real-time bidding software where the incoming protocol got changed from JSON to protobuffs. Just doing that made bandwidth costs go down majorly, CPU usage more than halved, and response times got cut.
When the question becomes "easy" vs. "good", always picking "easy" isn't very nice.
You were definitely working in a "very specific context"!
Also, I think that you have to consider how a company grows: JSON is simple to get started with. It's a good default - pretty much anyone can consume it very easily. As you explore your problem space and iterate and improve, you may realize it's not good enough. Fair enough - that's a good time to switch. But many people never reach that point, and will happily continue with JSON for a long time.
That's not invalid and I don't debate that. JSON is obviously ubiquitous. It's just a bad format. A typical case of worse is better.
https://github.com/johnezang/JSONKit has a few interesting corner cases, for example.