> [!thought] Once upon a time; JSON wasn't a thing. Can you believe it? JSON stands for "JavaScript Object Notation". One can deduce a lot from the name: - As the "Object Notation" states, this wasn't a standalone serialization format. It was a convention, a subset of the [[JavaScript]] syntax. - [[Coders at Work#Douglas Crockford|Douglas Crockford]] states that he *discovered* JSON. It's an interesting word choice that explains its birth - it was hidden in JavaScript all along! The very first "parser" of JSON used `eval()` - see [Douglas Crockford's implementation](https://github.com/douglascrockford/JSON-js/blob/master/json2.js#L552). Why was JSON special? * It resembles [[S-expression]], but for data. * Syntactically minimal for a human-readable data type. Sure, one can imagine more compact JSON (allowing unquoted strings like YAML) but its syntax is quite concise. * Python had almost the same syntax. * Traditional languages like C/C++/Java didn't have this at all. Creating a sample `HashMap` with dummy data was syntactically laborious. * **Built-in list type** * **Built-in `map` type** - Many serialization format ([[XML]], [[Protocol Buffers]]) decided against including a map type. This resulted in many ad-hoc map-like types defined throughout one's types. Protobuf eventually added the support for the `map`type. * **Native JavaScript support** (by the virtue of `eval` based implementation) meant that it could be used in many different places. Once many people were using it, more safe implementation of JSON were created. * Even when it first came out, it was "obviously" better than XML and everyone moved away from it. * Native support with JavaScript - unlike other serialization formats, one didn't need to define per-type serializer / deserializer (other than the global one). The lack of validation became difficult (that tools like JSON schema needed to solve over time). However, for a small integration where you have a full control of the caller and callee, this was very powerful as one didn't need to define any validation logic. * [[React]]'s native JSON serialization support, esp. regarding the *server actions* - https://react.dev/reference/rsc/use-server#serializable-parameters-and-return-values --- JSON is so simple that even [[Large Language Model|LLM]]s can generate it with sufficient accuracy. # Challenges ## Lack of comments - `json5` and `jsonc` tackles this. > [!warning] > I'm mostly annoyed by this in the [[Node.JS|NPM]] ecosystem; `package.json` cannot have comments, and it really drives me nuts; ## JSON serialization performance [[How we made JSON.stringify more than twice as fast · V8]] - challenge here is; dynamic behavior (custom `toJSON` hinders optimization). See [[Less is more]]. ## Key-order [[Nondeterminism]] > [!note] See also [[Dictionary Iteration Order]] ## float-to-string https://github.com/jk-jeon/dragonbox dragonbox is the state of the art when it comes to the float to string # JSONL An easy solution for the streaming problem (that also solves the [[Greppability]]). ```json {"user":"john"} {"user":"jane"} {"user":"smith"} ```