4 ms·

"I don't understand JSON, what do you do if JSON doesn't cover all your use cases?" Uh, then don't use it. Nobody said JSON was the answer to everything.

derefr 10y ago
Often you're forced to use it, because the infrastructure you're working with only speaks JSON (e.g. databases whose wire protocol is JSON-based, like CouchDB.) And even if you get to pick your own infrastructure, a lot of development effort is "stolen" by JSON-focused tooling and infrastructure, such that there's very little development effort given to protocols that aren't as limited. Consider: how many languages that offer a "batteries-included" JSON parser+generator, also offer a "batteries-included" parser+generator for e.g. ASN.1?
- dickbasedregex 10y ago
  Clearly almost no one is asking for alternatives.
  - ajamesm 10y ago
    Off the top of my head -- protobuf, thrift, avro, XML, lua tables, properties files, yaml.
- wolf550e 10y ago
  ASN.1 is an abomination, nobody would choose to use it if they could use JSON instead. Protobuf, Thrift, Cap’n Proto, Msgpack, XML, etc. have tooling for many languages.
- tracker1 10y ago
  There are a few things that must be parsed to/from strings, but that is usually safer as a string, since implementation details may vary by environment anyway... short of using a binary representation (there are a few out there), which may or may not be faster in any given language. Also, much like shoving large blobs in most databases, maybe you shouldn't be shoving large blobs into JSON?
- SamReidHughes 10y ago
  RethinkDB's protocol became some bastardized serialization of Protobuf definitions over JSON. The reason is language support and the higher performance of native JSON implementations in dynamically typed languages.
ajamesm 10y ago
Heh, people sure to use it like it's the answer to everything, and "don't use it" stops being an option if you're writing to a JSON-based interface. JSON's fine if you don't have any requirements around data serialization and you want it to "just work" for your webapp, but there's a lot of tech debt inherent in it. So you dump a report in JSON format and back it up to S3. S3 costs are growing faster than you thought, so you gzip deflate all of it. Everyone has to go patch their JSON deserialization to detect gzip extensions. Whatever, just growing pains. Then another team tries to read the reports, and they're getting errors because your definition of an interface is "we'll just use JSON, the keys are human-readable". You define a formal API for your report format and in doing so you realize the need for versioning attached to your report schema, so you wrap all your JSON objects with types and version annotations. You could define a central repository for these schemas, but it's easier to just bake them into the top-level response. Everyone agrees that this is "lightweight" and not "centralized". Now you're storing reports where each sub-object has its own annotations, or you're defining an entire schema at the object level. Object deserialization is taking 200ms even for small payloads, because of all the validation callbacks you're firing, and developers are now "performance hacking" their components by disabling validation callbacks. Now you have all the space overhead of schematic annotations with none of the benefits. In order to adhere to the API, either teams are writing separate serialization libraries, or you form a team to maintain them as infrastructure, which is a great idea except that the horse already left the barn 2 years ago. Without even realizing it, you've reinvented XML and XSD. And I don't really like XML either but at least you have to be honest about what you're getting yourself into.
- tracker1 10y ago
  http://json-schema.org/ http://json-schema.org/
iLoch 10y ago
I think a lot of companies would like you to believe that though, because the novelty of their product depends on it.

derefr 10y ago

Often you're forced to use it, because the infrastructure you're working with only speaks JSON (e.g. databases whose wire protocol is JSON-based, like CouchDB.) And even if you get to pick your own infrastructure, a lot of development effort is "stolen" by JSON-focused tooling and infrastructure, such that there's very little development effort given to protocols that aren't as limited. Consider: how many languages that offer a "batteries-included" JSON parser+generator, also offer a "batteries-included" parser+generator for e.g. ASN.1?

dickbasedregex 10y ago
Clearly almost no one is asking for alternatives.
- ajamesm 10y ago
  Off the top of my head -- protobuf, thrift, avro, XML, lua tables, properties files, yaml.
wolf550e 10y ago
ASN.1 is an abomination, nobody would choose to use it if they could use JSON instead. Protobuf, Thrift, Cap’n Proto, Msgpack, XML, etc. have tooling for many languages.
tracker1 10y ago
There are a few things that must be parsed to/from strings, but that is usually safer as a string, since implementation details may vary by environment anyway... short of using a binary representation (there are a few out there), which may or may not be faster in any given language. Also, much like shoving large blobs in most databases, maybe you shouldn't be shoving large blobs into JSON?
SamReidHughes 10y ago
RethinkDB's protocol became some bastardized serialization of Protobuf definitions over JSON. The reason is language support and the higher performance of native JSON implementations in dynamically typed languages.

ajamesm 10y ago

Heh, people sure to use it like it's the answer to everything, and "don't use it" stops being an option if you're writing to a JSON-based interface. JSON's fine if you don't have any requirements around data serialization and you want it to "just work" for your webapp, but there's a lot of tech debt inherent in it. So you dump a report in JSON format and back it up to S3. S3 costs are growing faster than you thought, so you gzip deflate all of it. Everyone has to go patch their JSON deserialization to detect gzip extensions. Whatever, just growing pains. Then another team tries to read the reports, and they're getting errors because your definition of an interface is "we'll just use JSON, the keys are human-readable". You define a formal API for your report format and in doing so you realize the need for versioning attached to your report schema, so you wrap all your JSON objects with types and version annotations. You could define a central repository for these schemas, but it's easier to just bake them into the top-level response. Everyone agrees that this is "lightweight" and not "centralized". Now you're storing reports where each sub-object has its own annotations, or you're defining an entire schema at the object level. Object deserialization is taking 200ms even for small payloads, because of all the validation callbacks you're firing, and developers are now "performance hacking" their components by disabling validation callbacks. Now you have all the space overhead of schematic annotations with none of the benefits. In order to adhere to the API, either teams are writing separate serialization libraries, or you form a team to maintain them as infrastructure, which is a great idea except that the horse already left the barn 2 years ago. Without even realizing it, you've reinvented XML and XSD. And I don't really like XML either but at least you have to be honest about what you're getting yourself into.

tracker1 10y ago
http://json-schema.org/ http://json-schema.org/

iLoch 10y ago

I think a lot of companies would like you to believe that though, because the novelty of their product depends on it.