Lesson 15
JSON in Today's Ecosystem
Strengths, limits, and when another format might fit better.
JSON won mindshare because it is simple, text-based, and maps cleanly to object models in mainstream languages. It is not the best choice for every problem—understanding tradeoffs helps you pick formats deliberately.
Where JSON fits well
- HTTP APIs with JavaScript, mobile, and server clients
- Config that tools parse at startup (
tsconfig, CI matrices) - Event streams when each message is a self-contained record
- Interoperability when you cannot ship a shared binary schema to all parties
Friction points
| Limitation | Practical impact |
|---|---|
| No comments | Document fields elsewhere or use JSONC locally only |
| No dates or decimals as native types | Encode as strings with agreed formats |
| Verbose vs binary | Higher bandwidth than Protobuf or MessagePack |
| Schema optional | Drift between producers and consumers |
None of these disqualify JSON—they define where extra discipline (schemas, tests, docs) is required.
Neighbors in the format landscape
- XML — Still strong in document-centric and legacy enterprise systems
- YAML — Human-authored configs; watch indentation and security on untrusted input
- CSV/TSV — Flat tabular data, not nested graphs
- Protobuf / Avro — Compact binary with strict schemas inside trusted networks
Teams often use JSON at the edge (public API) and binary formats internally.
Adopting JSON thoughtfully
Standardize on UTF-8, publish schemas or OpenAPI where possible, and version breaking changes explicitly. JSON’s ubiquity is a social convention as much as a technical one—your course knowledge lets you participate in that convention without treating the format as magic.