The lost art of XML

Original Article ↗ Hacker News Discussion ↗

Once the default choice for web-era data exchange, XML is now mostly sidelined by JSON and binary formats, and commenters debate whether that was a hard‑won lesson or a costly overreaction. Many argue XML’s complexity, ambiguous modeling (elements vs attributes), namespaces, fragile tooling, and overengineered ecosystems like SOAP and XSD made everyday use painful despite strong schema and transformation capabilities. Others counter that for complex, strongly typed B2B integrations and document-centric workflows, XML plus mature tooling still solves problems JSON is only now reinventing piecemeal, though few see a broad revival as likely or desirable.

Why XML Declined

  • Several commenters argue XML lost mainly due to complexity, awkward tooling, and poor developer experience, not bandwidth.
  • Verbosity was a frequent complaint, though with compression the on‑wire size was often similar to JSON; CPU and memory costs (especially on early mobile) and parsing complexity were more significant.
  • Attributes, namespaces, entities, CDATA, mixed content, and multiple modeling choices made simple data tasks painful and error‑prone.
  • The broader XML ecosystem (SOAP, WS-*, WSDL, complex schemas) became synonymous with over‑engineering and fragile integrations.

JSON’s Appeal and Limitations

  • JSON maps directly to ubiquitous data structures (maps and arrays) and matched the mental model of dynamic languages (JS, Python, PHP, Ruby).
  • Early JSON could be parsed in browsers with minimal tooling, which massively boosted adoption and improved developer experience.
  • JSON is criticized as “lobotomized”: no comments, weak typing, external schema standards, and fewer formal guarantees. However, its simplicity is viewed as a feature that avoids many XML footguns.
  • Some note we are gradually recreating XML‑like tooling around JSON (schemas, JSONPath, transformation tools).

XML’s Original Purpose and Strengths

  • Multiple comments stress XML was designed as a document/markup format, not initially as a data serialization format; data‑exchange use was layered on later.
  • XML shines for human‑authored, tree‑structured documents, configuration with comments, and domains needing strict validation and rich semantics.
  • Tooling like XSD, XSLT, XPath, and XQuery is remembered as powerful, especially for contracts and transformations, though often hard to learn.

Schemas, Namespaces, and Validation

  • Schemas are seen as both a killer feature and a major source of pain: XSD is widely called incomprehensible; RELAX NG praised but niche.
  • Namespaces divide opinion: some found them invaluable in large systems, others call them a “hell” that complicates every operation.
  • Strong schema‑validated XML is still favored in complex B2B/banking and enterprise scenarios where 1:1 type systems and precise contracts matter.

REST, RPC, and Ecosystem Shifts

  • Discussion notes that most so‑called REST APIs are really RPC over HTTP with JSON.
  • Some argue industry abandoned true REST and XML, then spent years reinventing schema/documentation layers on top of JSON RPC (OpenAPI, similar efforts).
  • Others maintain that for most web dev—small, internal, fast‑changing services—simple JSON APIs are entirely adequate.

Ongoing Niche Uses and Alternatives

  • XML remains in office document formats, some configuration setups, financial and banking interfaces, and XQuery‑based systems.
  • Many prefer binary or other typed formats (Protocol Buffers, ASN.1/DER, custom schemes) for machine‑to‑machine communication.
  • Several commenters think XML’s decline was justified; a minority argue we threw away a solid core technology because of fashion and bad ecosystems.