Douglas Crockford became interested in programming in college, almost by accident. He took some computer programming classes to fulfill his science requirements, and quickly fell in love. His first experience was programing Fortran on punchcards, which required diligence and efficiency to do right. It was an experience and a methodology that would follow him his entire career. After bouncing around computer and video game companies, including Atari, in the early ’80’s, Crockford eventually ended up at Lucasfilm, where he met Chip Morngingstar.

Morningstar was working on something called Habitat, a predecessor to MMPORG games that networked computers together in a virtual world. At the time, there was nothing like it on the market, and Morningstar obsessed over making sure its underlying codebase was simple and robust enough to handle hundreds of simultaneous requests. Crockford helped out briefly on the Habitat project before the two left to form their own company, Electric Communities.

Their company was, ostensibly, a startup dedicated to creating virtual worlds on the Internet for people to meet up and chat. They acquired a piece of software called The Palace that enabled users to connect to graphical chat rooms and events, and acquired some buzz and venture capital in the ramp up of the dot-com boom.

But just like at Lucasfilm, Morningstar and Crockford got swept up in maximizing the efficiency and portability of the Palace codebase far more than anything else. They refactored the program to improve it as much as possible. When that wasn’t enough, they set about creating their own programming language known as E, spun off from Java, which relied on sending messages to execute programs.

Eventually, Electric Communities was parceled out into something else and Crockford and Morningstar were left looking for their next venture. It occurred to them that they had become pretty good at taking complex codebases and systems and refactoring and extending them into efficient, robust software. They started a new consulting software firm with that in mind, known as State Software.

While working at State Software, the duo began tinkering with the web and, more specifically JavaScript. They wanted to be able to pass data back and forth between a server and a browser (the kind of event-driven messaging that was trivial in E), without needing to fully refresh the page. There wasn’t a great way to do it. So Crockford took an idea that he had first learned from somebody over at Netscape, and embedded a JavaScript object inside of an HTML frame, which then passed a message along to the page.

It looked like this:

    document.domain = 'fudco';
    parent.session.receive(
        { to: "session", do: "test",
          text: "Hello world" }
    )

But that didn’t work. The word do was not allowed to be used because it was reserved by the JavaScript language. To get around that, Crockford put everything inside of quotes. Which looked like this:

    document.domain = 'fudco';
    parent.session.receive(
        { "to": "session", "do": "test",
          "text": "Hello world" }
    )

And that format, roughly speaking, eventually became known as JSON, a JavaScript based data exchange format that can be used to package and send messages from a web server. In 2001, Crockford put up a webpage to describe the format, so that others could use it too. Then, in 2002, he left State Software.

Crockford would spend the subsequent decade of his career in JavaScript, advocating for the language’s simple understandability. When he wrote a book, he called it plainly JavaScript: The Good Parts. When JavaScript has tried to layer complexity into its specification over the years, Crockford has often pushed back against that. JSON was another expression of that ideology.

Years later, when describing the history of JSON, Crockford stressed the simplicity of the format. “One of the key design goals behind JSON was minimalism. My idea was that the less we have to agree on in order to inter-operate, the more likely we’re going to be able to inter-operate well,” he began, “I had a goal of being able to put JSON standard on the back of a business card.”

JSON has a few rigid rules. It doesn’t allow for comments. All keys and values need to be quoted. There can’t be trailing commas. But with those requirements, the specification is concise, and parsers are relatively easy for programmers to implement. For the longest time, JSON didn’t even have a version number. There weren’t any extensions to it. But it worked. You really can print the standard on a business card. It looks like this:

For a while, JSON stayed relatively small, passed around and implemented as compatible parsers in various programming languages. Each time a new parser was released, Crockford would add it to his website. And slowly, a community began to form around the standard.

In 2005, Jesse James Garrett gave AJAX a name, an acronym for Asynchronous JavaScript and XML. It was a way to describe interactive web applications that leveraged the power of JavaScript. Citing work being done at Google with applications like Google Suggest and Google Maps, Garrett described websites that felt more like desktop applications, that refreshed data on the page and stayed dynamic by periodically requesting data from the server and using JavaScript to add it to the page.

A wave of Web 2.0 applications in the mid-2000’s rode on top of AJAX technology, bringing new feature sets and technologies to the web. Powered by JavaScript and seeded by the next wave of venture capital, more and more dynamic applications for sharing, storing, and creating on the web were launched.

In this new paradigm, applications used different formats to communicate data from servers to the browser: XML, JSON, and YAML. In his original post, Garrett conceded that XML wasn’t a requirement, any format that could communicate data simply and effectively would do. Since AJAX had started with XML—it was in the name after all—some believed it was the only true way to create dynamic applications on the web. Critics believed that as a simple format, JSON couldn’t scale to meet the challenges of high performance applications on the web.

But many people struggled with the complexity and often excessive demands of the XML format. JSON offered an alternative that, after years gradually growing across languages and frameworks, was relatively widespread and available. A half decade earlier, Crockford had bet on simplicity. And the increasing demands of web 2.0 applications made web developers eager for a simple way to glue them together. Over time, JSON gained more widespread adoption.

In 2007, Ruby on Rails added support for JSON serialization to their data retrieval API, automatically enabling JSON for thousands of applications. It was a turning point for the format. Years later, in 2014, JSON was adopted by the ECMA standards body and officially specified. By then, it was already the more popular choice among web developers.

And that’s how you got AJAX in every day use, without the X.