JSON VIEW PARSER

Before JSON: The XML Era

Around the turn of the millennium, structured data on the web meant XML. It was powerful, extensible and backed by an enormous ecosystem — schemas, transformations, namespaces, query languages. It was also heavy. A simple record required substantial ceremony:

<?xml version="1.0" encoding="UTF-8"?>
<user>
  <id>101</id>
  <name>Alice</name>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
</user>

The weight was not only in bytes. To read a value in a browser you had to traverse a DOM — walk nodes, check types, extract text content — and then convert the result into whatever structure your code actually wanted. For applications beginning to make background HTTP requests, that overhead was paid on every single call.

Discovery, Not Invention

In 2001, Douglas Crockford was working on applications that needed to pass data between a server and a browser without a plugin. He noticed that JavaScript's own object literal syntax was already a serviceable data format — compact, human-readable, and requiring no parsing library at all in a browser, because the language could evaluate it directly.

{
  "id": 101,
  "name": "Alice",
  "roles": ["admin", "editor"]
}

Crockford has been consistent that he discovered JSON rather than inventing it — the notation already existed; his contribution was recognising it could serve as a language-independent interchange format, giving it a name, and writing down the rules. He registered json.org in 2002, publishing the grammar on a single page with the famous railroad diagrams that still sit there today.

The name itself was a deliberate piece of positioning. "JavaScript Object Notation" borrowed credibility from a language every browser already ran — though the acronym has aged awkwardly, since JSON is now used far more outside JavaScript than within it.

The Decisions That Made It Win

JSON's success came from what Crockford left out rather than what he put in. Each omission was argued for at the time and each turned out to matter:

• No comments. Removed after Crockford saw people using them to carry parsing directives — which would have made the same document mean different things to different parsers, destroying the interoperability that was the whole point. His advice was to strip comments in a pre-processing step if you needed them.
• No version number. A deliberate commitment to never changing the format. Crockford's reasoning was that a version field invites incompatible revisions; without one, every JSON document written in 2002 still parses correctly today.
• No schema in the format. Structure validation was left to a separate layer, which eventually became JSON Schema. Keeping it out kept parsers small.
• A minimal type set. Seven value types and no more — no dates, no binary, no references. Every addition would have been another thing implementations could disagree about.

The result is a grammar small enough to implement correctly in an afternoon in any language. That, more than any feature, is why JSON spread: the cost of supporting it was almost zero.

AJAX and the Tipping Point

JSON's timing was fortunate. In 2005 the term AJAX was coined to describe the technique — already in use at Google Maps and Gmail — of fetching data in the background and updating a page without reloading it. Suddenly a great many applications were making frequent small data requests from JavaScript.

For that workload JSON's advantages were decisive. A response arrived as a structure the language already understood, needing no DOM traversal and no conversion step. The acronym said XML, but the payload increasingly was not.

// XML: parse, traverse, extract, convert
var name = xmlDoc.getElementsByTagName("name")[0].childNodes[0].nodeValue;

// JSON: it is already the structure you wanted
var name = data.name;

Early code used eval() to turn JSON text into objects, which was fast but executed whatever the string contained. JSON.parse was standardised in ECMAScript 5 (2009) precisely to close that hole, and native implementations made it faster than eval as well as safer — as covered on the parser page.

Standardisation

The 2006-to-2014 change explains a lingering inconsistency: under RFC 4627 a bare "hello" or 42 was not a valid document, and under RFC 8259 it is. Occasional older parsers still enforce the stricter rule, which is why some style guides advise wrapping everything in an object regardless.

What Came Afterwards

JSON's deliberate minimalism left gaps, and the ecosystem filled them with layers rather than by changing the format — exactly as Crockford's no-version-number decision intended:

• JSON Schema for validating structure, since JSON itself defines only syntax.
• JSON5 and JSONC for human-edited configuration, restoring comments and trailing commas. Notably, both are separate formats rather than revisions to JSON.
• JSON Lines for streaming and logs, where one document per line allows constant-memory processing.
• Binary encodings such as MessagePack, BSON and CBOR, trading human readability for size and parse speed.

Meanwhile XML did not disappear — it remains entrenched in document formats, enterprise messaging and publishing, where its namespaces and transformation tooling earn their complexity. What changed is that it stopped being the default for web APIs. As of today, an API that returns XML by default is the exception and usually the older system.

Frequently Asked Questions