The Forgotten Developer Who Saved JavaScript: Douglas Crockford and the Story of JSON

Everyone knows Brendan Eich created JavaScript in ten days, back in 1995. That's the famous story. But here's the part nobody tells you: for about a decade after JavaScript was born, serious developers thought of it as a toy. A joke. Something you used to make text blink on a webpage, not something you built real software with.

So what changed? It wasn't an upgrade to the language. It was one person. His name is Douglas Crockford — and if you've never heard of him, that's kind of the point of this story.

Let me set the scene. Crockford was an engineer who'd been writing software since the 1980s, and in the 2000s he became the JavaScript Architect at Yahoo!. He did not create JavaScript. But he's arguably the reason anyone takes it seriously today.

And back in the early 2000s, that was a hard sell. JavaScript had a genuinely terrible reputation, and honestly, some of it was earned. The language was full of landmines. You had the confusion between double-equals and triple-equals for comparison. You had the keyword "this," which behaved in ways that could surprise even experienced programmers. Everything leaked into one giant global namespace. There was no module system at all. Backend developers looked at all that and said, "Yeah, that's a beginner's language. I'll pass."

Crockford did three things that pulled JavaScript back from the dead. Let's walk through them.

The first one is JSON — and you use it every single day, whether you realize it or not.

Rewind to 2001. Crockford needed a way for browsers and servers to send data back and forth. The standard approach at the time was XML combined with SOAP, and if you never had to work with that, count yourself lucky. It was heavy. It was verbose. Writing the code to build it and then parse it on the other end felt, to Crockford, frankly absurd for what should be a simple job.

Then he noticed something clever. JavaScript already had a way to write objects — you know, curly braces, a key, a colon, a value. That little bit of syntax was, all by itself, a perfect data format. It was human-readable. It was lightweight. And every JavaScript environment on Earth could already parse it natively, for free. So he took that idea, registered the domain json.org, wrote up a complete specification for the format, and started promoting it. By 2006, JSON had become an official internet standard — RFC 4627.

Now here's the honest nuance. Crockford didn't invent the syntax. It was just JavaScript object literals, sitting there the whole time. What he did was formalize it, name it, document it, and convince the entire industry to adopt it. And they did. Today, JSON is the default data format for basically every web API on the planet — REST APIs, config files, frontend-to-backend communication, all of it. Think about that: without Crockford, we might all still be wrestling with XML.

The second thing he did was JSLint, in 2002.

JSLint was a static analysis tool — meaning it reads through your JavaScript and flags potential errors and bad habits before you ever run the code. And Crockford described it with a line that became legendary. He said, "JSLint will hurt your feelings." And he meant it. The tool was brutally strict. You could write code that worked perfectly fine, run it through JSLint, and get back a wall of complaints.

But that harshness was the whole point. Before JSLint, JavaScript had no static analysis tools, no agreed-upon style standards — the entire ecosystem basically ran on the philosophy of "eh, if it runs, ship it." JSLint was the first tool to plant a flag and say: no, JavaScript can have quality standards. If you've ever used ESLint — and if you write JavaScript today, you have — that's the direct descendant of Crockford's idea.

And the third thing, in 2008, was a book. A slim one — 176 pages — called *JavaScript: The Good Parts*.

The central argument of that book was, in Crockford's own slightly grandiose words, "one of the most important discoveries of the 21st century." His claim was this: buried inside JavaScript, underneath all the bad design decisions, there was actually a beautiful, well-designed language trying to get out. If you deliberately restricted yourself to only the good parts — things like prototypal inheritance, closures, its functional programming features — JavaScript was genuinely elegant.

And you have to understand how heretical that was at the time. The mainstream opinion was simple: JavaScript is a bad language, top to bottom, end of story. Crockford stood up and said, no — the language isn't the problem. You're using it wrong. That book reframed how an entire generation of developers saw JavaScript. It was, culturally, the moment the tide started to turn.

So let's put this in perspective against Brendan Eich. Eich created JavaScript — that's not in dispute, and it's a remarkable feat for ten days of work. But his contribution got buried under a decade of criticism. Crockford's contribution came at exactly that low point. He used tools and arguments to redefine what "good JavaScript" even meant, and in doing so he laid the cultural foundation for everything that came later — Node.js, the V8 engine, the entire npm ecosystem. That explosion needed the ground to be prepared first, and Crockford is the one who prepared it.

So here are the takeaways I want you to walk away with.

First: the technologies you use every day often have a hidden second author — not the person who invented them, but the person who made them usable and respectable. For JavaScript, that person is Douglas Crockford.

Second: JSON, JSLint, and *The Good Parts* weren't upgrades to the language. They were an act of curation — pulling out the good, quarantining the bad, and writing it all down. Sometimes clarity is the innovation.

And third, the bigger lesson: a technology's success often has very little to do with its original design. It depends on whether someone takes the time to organize how it's used, establish the best practices, and stand up to say, "This actually deserves to be taken seriously." Crockford isn't in JavaScript's origin story. He's in its redemption story. And honestly, those are sometimes the stories that matter more.