Worse is better: JSON versus XML

Mark Seemann · rss · 2026-07-06 source ↗ Reader 🖥️

Changeability & Optionality Modularity & Coupling Software Design Fundamentals Worse Is Better

Despite JSON's popularity, XML is the superior data-interchange format in most respects — because its mature ecosystem of standards (schemas, versioning, querying, streaming, even sum types) delivers real capability that JSON only reinvents piecemeal, while JSON's supposed advantages (informality, size, readability) are illusory, marginal, or equally achievable in XML — making JSON another case of 'worse is better'.

practical · Argumentative opinion essay (contrarian technical advocacy), part of the author's 'Worse is better' series — The article's END is practical — to change which data-interchange format the reader reaches for (prefer XML for interoperability; use JSON pragmatically). Its BODY, however, is a chain of evaluative-theoretical judgments ('XML is superior in most respects'). The structure is a sequence of objection-and-rebuttal: Seemann steel-mans each pro-JSON argument (ceremony, size, readability) and defuses it. Notably, the author's own stated practice (he'd 'pragmatically choose JSON in lots of cases') diverges from his thesis — 'worse is better' operating on the author himself.

Structure

Part	Role
Series frame + thesis	Opens with the bolded claim 'JSON is not a good data-interchange format', locates the piece in the 'Worse is better' series, and invokes the VHS-vs-Betamax analogy to prime the reader that popularity does not track technical merit.
Disentangling XML from SOAP/WS-*/XSLT	Pre-empts the reflexive anti-XML reaction by arguing the loathed enterprise standards were awkward on their own, not because of XML — separating the format from its historical abusers.
Lightweight XML	Rebuts the 'XML = ceremony' objection: XML can be as informal as JSON (no mandatory schema, namespace, or declaration) and supports gradual enhancement, adding formality only when needed. Notes the irony of JSON Schema's existence.
Sweet spots (interoperability + config)	Makes the positive case: XML's ideal domain is interoperability because of machine-readable schemas (invoking Alexis King on specification-without-static-types and Hyrum's law on implicit contracts), backed by a mature standards ecosystem — 'why reinvent the wheel?' Then argues JSON is a poor config format (no standard comments), while conceding neither format is ideal for config.
Readability concession	Concedes XML is less readable but argues the gap is marginal given syntax colouring and schema-aware editors.
Where JSON shines	Grants JSON's legitimate wins — SPAs/BFFs (JavaScript-native) and the pragmatic default choice — noting the etymological irony that AJAX's X once stood for XML.
Size objection	Addresses the strongest pro-JSON argument (verbosity) with a worked example, then defuses it: the size difference rarely dominates over latency/block-size, and when performance truly matters, JSON is too big too.
Conclusion	Restates that XML is superior in most aspects thanks to a rich, mature standards ecosystem (including sum types), and closes on the recurring rhetorical thrust: why reinvent the wheel?

Key terms

Worse is better Worse Is Better
Seemann's series category for 'technologies and techniques that became popular despite superior alternatives' — here casting JSON as the popular-but-inferior winner and XML as the superior loser, framed as a lament about unjust adoption.
Gradual enhancement
The property that lets you start with a plain, informal XML document and add formality (XSD schema, namespace, XML declaration) incrementally, only if and when a real need appears — you never have to pay the ceremony up front.
Implicit contract
Via Alexis King and Hyrum's law: the absence of a machine-readable schema does not mean there is no specification — the contract still exists, it is merely undocumented and implicit, so consumers couple to observed behavior.
Sweet spot
The ideal use scenario for a given technology — for XML, interoperability/data-exchange where machine-readable schemas pay off; for JSON, JavaScript-native SPA/BFF payloads.

Propositions

explicitJSON is not a good data-interchange format.conf: high
explicitXML is superior to JSON in most respects.conf: high
explicitThe cumbersomeness of SOAP, WS-*, and XSLT was not caused by XML — those standards were awkward on their own, and re-expressing them in JSON would be even more verbose.conf: high
explicitXML does not have to be heavy or formal — you can write an informal XML document with no schema, namespace, or declaration, just as in JSON.conf: high
explicitXML supports gradual enhancement — you can add a formal, machine-readable schema (XSD) later, only if and when you need it.conf: high
supportsApplying Best Simple System for Now for Software Design · p4 — XML's gradual enhancement — start with plain nesting, add a schema only when a real need appears — is BSSN applied to data-format design: defer formalization and let simplicity carry adaptability. On this proposition Seemann is Beck-aligned, even as p9 pulls the other way.
implicitThe existence of JSON Schema is ironic, because it shows JSON reinventing the formal-specification capability XML already provides.conf: high
explicitXML's ideal use is interoperability, and its main advantage there is the ability to define machine-readable document schemas.conf: high
explicitThe absence of a machine-readable schema does not entail the absence of a specification; it only makes the contract implicit (Hyrum's law).conf: high
explicitcontestedXML offers a mature ecosystem of standards — a schema language, document versioning, a query language (XQuery), streaming parsers (SAX) — that JSON must reinvent piecemeal, so there is no reason to reinvent the wheel.conf: high
contradictsApplying Best Simple System for Now for Software Design · p3 — Seemann treats XML's latent, ready-to-use standards (schema/versioning/XQuery/SAX) as a positive reason to prefer the richer format; BSSN holds that speculative extension points and unused capacity make future change harder, not easier — an unaddressed worldview tension, not a rebuttal Seemann makes.
explicitcorroboratedJSON is a poor configuration-file format, most obviously because the standard has no support for comments, whereas XML has a standard for comments.conf: high
supports ←JEP 540 Proposed to Target JDK 28 with a Simple JSON API · p4 — JEP 540's own authoritative, spec-first parser confirms JSON's lack of comment/lenient-syntax support is a real, unresolved weakness for configuration-style use — even the JDK's own new implementation doesn't add a permissive mode to compensate.
explicitNeither XML nor JSON is a good configuration-file format, and perhaps no perfect one exists.conf: high
explicitXML's lower readability relative to JSON is real but marginal given good tooling such as syntax colouring and schema-aware editors.conf: high
explicitJSON is the right choice for SPAs and BFFs because it is native to JavaScript.conf: high
explicitPragmatically, JSON is the right default in many cases today, because it is the expected format and defending a less popular choice is rarely worth it.conf: high
explicitXML is more verbose than JSON — sometimes by more than a factor of two — but the size difference rarely matters in practice, because factors like network latency and storage block size dominate, and when size truly matters JSON is also too big.conf: high
explicitXML's schema language even supports sum types (tagged unions), a type-system capability JSON lacks natively.conf: high
implicitcorroboratedTechnical superiority does not determine adoption; a technically inferior format can become dominant ('worse is better').conf: high
extends ←JEP 540 Proposed to Target JDK 28 with a Simple JSON API · p1 — JEP 540 instantiates the worse-is-better thesis inside the JDK's own standard library: it deliberately ships a less complete JSON API than Jackson/Gson, betting that narrow interface simplicity (plus zero external dependency) beats completeness for the common case.
supports ←Worse is better: C# versus F# · p2 — Second installment of the same series reinforcing the general 'technical superiority does not determine adoption' claim with a new, ecosystem-controlled example (F# vs. C# within .NET) rather than merely restating it.

Arguments

XML is a superior data-interchange format to JSON in most respects, and should be preferred for interoperability. strength: medium

Explicit premises:

XML has a mature ecosystem of standards — schema language, versioning, query language, streaming parsers, sum types (p9, p16).
XML can be as lightweight and informal as JSON, adding formality only through gradual enhancement (p4, p5).
JSON's apparent advantages — informality, smaller size, readability — are illusory, marginal, or achievable in XML too (p4, p12, p15).
The historical case against XML actually indicts SOAP/WS-*/XSLT, not the format itself (p3).

Implicit premises:

Maturity and standardization of an ecosystem are the decisive criteria of a format's 'superiority' — a value judgment that privileges latent capability and optionality over minimalism and ubiquity.
Adoption and popularity are not evidence of technical merit ('worse is better'), so JSON's dominance can be discounted rather than read as revealed preference.
The reader values the option to add schemas, queries, and streaming later — i.e., latent needs justify paying an ecosystem-maturity premium now, even for systems that may never need XSD or XQuery.
'Why reinvent the wheel' assumes reinventing is pure waste — yet the fact that the ecosystem deliberately reinvented a SIMPLER wheel is evidence that JSON's simpler interface is a feature, not a bug (this is Gabriel's actual worse-is-better thesis, which Seemann's framing implicitly contradicts).
The costs of XML (verbosity, historical baggage, developer unfamiliarity, ecosystem complexity) are small relative to its benefits — asserted rather than demonstrated.

Inferences:

From 'XML has richer standards' + 'those standards are worth having' to 'XML is superior' — the middle premise (that the richer standards are worth their cost for the common case) is the load-bearing, unargued step.
From 'each individual pro-JSON point can be rebutted' to 'XML is superior overall' — an aggregation move that never weighs the rebutted advantages against XML's costs, and ignores network effects entirely.

JSON is a poor configuration-file format, and XML is the better (though still imperfect) choice there. strength: medium

Explicit premises:

The JSON standard has no support for comments (p10).
XML has a standard for comments (p10).

Implicit premises:

Standard, portable comment support is a decisive requirement for a config format.
The only realistic contenders for configuration are XML and JSON — YAML, TOML, and HCL, the formats that actually displaced both, are never considered.

Inferences:

From a single missing feature (standard comments) to a format-level verdict — a narrow basis for the conclusion, which the author then partly retracts ('neither is a good config format').

JSON's smaller size is not a decisive advantage over XML. strength: low

Explicit premises:

XML is more verbose (sometimes >2x), shown by the die-roll example (p15).
Other factors — network latency, storage block size — usually dominate the size difference (p15).
When performance really matters, JSON is also too big (p15).

Implicit premises:

Marginal per-message size rarely aggregates into a decisive cost at typical scale.
The relevant alternative when size matters is not a compact text format but a binary one — so text-format verbosity is moot at the extreme.

Inferences:

From 'size rarely dominates' + 'binary wins at the extreme' to 'verbosity is not a real JSON advantage' — a pincer that skips the large middle band of high-throughput text APIs where JSON's compactness and parse cost genuinely matter.

Narratives

VHS versus Betamax — the videotape format war, offered as the emblem of the whole 'Worse is better' series.
→ Analogy that primes the reader to accept that the popular option (JSON) can be the technically inferior one, borrowing the settled intuition that Betamax was 'better' but lost.
The same book record written first as JSON ({"author":"Peter Watts","title":"Blindsight"}) and then as equivalent informal XML (<book><author>Peter Watts</author>...).
→ Concrete side-by-side that demonstrates XML need not carry any more ceremony than JSON, defusing the 'XML is heavyweight' objection (supports p4).
The die-roll example: <die><roll>4</roll></die> (25 characters) versus {"roll":4} (10 characters).
→ Worked example that quantifies and concedes the verbosity gap while bounding it ('a factor of two... or a small percentage'), setting up the rebuttal that size rarely matters (frames p15).
The AJAX etymology — the X in AJAX originally stood for XML, and today's SPAs grew out of it even though they now use JSON.
→ Historical irony that both concedes JSON's legitimate SPA home (JavaScript-native) and subtly reasserts XML's foundational primacy — the SPA world was born from XML (supports p13).
The 'irony' of JSON Schema existing at all.
→ Rhetorical exhibit that recasts JSON's tooling growth as reinvention of capabilities XML already had, reinforcing the 'why reinvent the wheel' thrust (supports p6, p9).
Appeals to Alexis King (types are not required for a specification) and Hyrum's law (every observable behavior becomes a dependency).
→ Borrowed authority that converts a positive claim ('schemas are good') into a negative one about JSON ('schemalessness only hides the contract, it does not remove it') — supports p8.

Questions addressed

✅ Is XML obsolete legacy/enterprise technology we are well rid of?
No — the loathing is unfair; XML is superior in most respects. What people actually hated was SOAP/WS-*/XSLT, which were awkward independently of XML.
✅ Isn't XML too heavy and ceremonious compared to JSON?
No — XML can be written as informally as JSON; schemas, namespaces, and declarations are optional and can be added later via gradual enhancement.
✅ When should you actually choose JSON over XML?
For SPAs/BFFs (JavaScript-native) and, pragmatically, whenever JSON is the expected default and defending a less popular choice is not worth it.
✅ Doesn't JSON's smaller size make it the better interchange format?
Rarely — the size difference is usually dominated by latency and block size, and when size truly matters, JSON is too big too.
⭕ If XML is superior, why did JSON win?
Named but not explained: it is 'worse is better'. The causal mechanism (why the inferior option wins) is deferred to the series introduction, so within this article the answer is asserted rather than argued — and, ironically, Gabriel's actual thesis holds that the simpler option wins because simplicity is a virtue, which would make JSON's win deserved.

Gaps

incompleteThe article asserts that ecosystem maturity/standardization makes XML 'superior' but never defines the criteria of superiority or weighs them against JSON's decisive real-world advantages — network effects, JavaScript-ecosystem gravity, and cognitive simplicity — which are the actual reasons formats win adoption. 'Superiority' is treated as a property of the format in isolation rather than of the format-in-its-ecosystem.
Read next: Read Richard Gabriel's original 'The Rise of Worse Is Better' — it argues that the 'worse' option's simplicity of interface is itself the deeper virtue, directly challenging the 'why reinvent the wheel' framing — alongside the network-effects and standards-adoption literature.
illogicalThe recurring 'why reinvent the wheel?' treats JSON's re-implementation of XML capabilities as pure waste, but the very fact that the ecosystem chose to reinvent a SIMPLER wheel is evidence that XML's richer wheel was mis-sized for the common case. The argument thus assumes what it needs to prove — that XML's heavier standards are worth their cost — and this directly contradicts the Gabriel 'worse is better' thesis Seemann himself invokes as his framing device (a tension the article never acknowledges).
Read next: Engage Gabriel's actual claim that simplicity of the common case can rightly dominate completeness, and read the design-fundamentals argument that unused capability is a cost, not a latent asset.
incompleteThe size argument is dismissed too quickly — 'when performance really is a consideration, JSON may be too big, too' waves away rather than engages the large middle band of high-throughput text APIs (aggregate bandwidth, parse cost, streaming) and the schema-driven binary formats that are actually chosen when neither text format fits.
Read next: Read the schema-driven binary serialization literature — Protocol Buffers, Apache Avro, Cap'n Proto, MessagePack — to see where the real interchange-format frontier lies beyond the XML-vs-JSON text axis.
incompleteThe Hyrum's-law/implicit-contract point is used only against JSON, but it cuts both ways: XML with an XSD still couples consumers to undocumented behaviors, and a schema is not a free lunch — XSD complexity, schema evolution, and versioning cost are never weighed against the benefit claimed.
Read next: Read on schema evolution and compatibility (e.g. Avro/Protobuf compatibility rules, and API-versioning practice) to see the ongoing cost side of the schema ledger the article omits.
incompleteThe configuration-file case rests almost entirely on JSON's lack of standard comments, yet never mentions YAML, TOML, or HCL — the formats that actually displaced both XML and JSON for configuration — which makes the 'XML for config' recommendation weaker and more dated than presented.
Read next: Compare TOML and YAML directly on the same criteria (comments, readability, schema tooling) to see why the config-format question was largely settled without either XML or JSON winning.

Worse is better: JSON versus XML

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents