The Developer Who Fixed JavaScript Before Anyone

Every few years, a programming language becomes the thing everyone uses to build the internet. Right now, that language is JavaScript. It powers the interactive parts of almost every website you visit — the dropdown menus, the live search results, the buttons that do something when you click them. Roughly 98 percent of websites use it in some form, according to web technology surveys. JavaScript is, by most reasonable measures, the most widely deployed programming language on Earth.

It also used to be genuinely terrible.

A recent Fireship video makes this case with some enthusiasm, and it's worth taking seriously because the history it's telling is real, even if the framing is a bit breathless. The video profiles Jeremy Ashkenas, a developer who spent the years around 2009 and 2010 building a series of tools that addressed JavaScript's most serious problems — not by replacing the language, but by working around it. He never rebuilt JavaScript from the ground up. What he did was arguably more interesting: he built scaffolding around a collapsing structure and kept it standing long enough for the structure itself to be repaired.

To understand why that mattered, you need to understand what JavaScript actually was in 2009.

A Language Designed in Ten Days

JavaScript was created by Brendan Eich at Netscape in 1995, famously in about ten days. That origin story has become tech folklore, usually told to explain why the language has so many strange corners and inconsistencies. But in 2009, those inconsistencies were daily operational problems.

Consider: JavaScript had no standard library. A standard library is the set of built-in tools a language provides so you don't have to write everything from scratch — the way a kitchen comes with a stove, not just four walls. In 2009, JavaScript came with almost no stove. If you wanted to perform a basic operation on a list of items — say, filter out everything that didn't meet a condition — you might have to write that logic yourself, every time, in every project.

There were no classes. In most programming languages, a "class" is a template for creating objects — think of it like a blueprint for a house. JavaScript used a different, stranger approach called prototypal inheritance, where you'd manually attach properties to a hidden internal object and hope everything connected correctly. It worked, but it was the kind of thing that looked fine until it didn't, and when it didn't, the failure was confusing.

Variable scoping — the rules that determine which parts of your code can see which variables — worked in ways that surprised even experienced developers, because declarations got silently moved to the top of their containing function regardless of where you wrote them.

And then there was the browser problem. In 2009, Internet Explorer still commanded a huge share of web traffic. Firefox had added some useful features. But the two browsers didn't agree on what JavaScript should do, which meant that writing code that worked in both required workarounds called polyfills — patches you'd write to simulate a feature in a browser that didn't natively support it. Building a website meant constantly checking: does this work in IE? If not, you'd have to fake it.

Ashkenas, working at a company called DocumentCloud on a large JavaScript-heavy application — unusual at the time, when most web interactivity was still relatively simple — decided he'd had enough.

Three Tools, Three Problems

His first response was Underscore.js, released in 2009. Underscore was a utility library: a collection of dozens of pre-written helper functions for common operations. Need to sort a list? Filter it? Find the first item that meets a condition? Underscore had it. It was the stove the kitchen was missing.

That sounds modest. It wasn't. Underscore became one of the most downloaded JavaScript libraries of its era, and enough of its ideas were eventually absorbed directly into JavaScript that Underscore itself became largely unnecessary. The highest compliment you can pay a tool is that the thing it was fixing gets fixed. Underscore earned that compliment.

His second project was CoffeeScript, released the same year. This was more ambitious: a new programming language, designed to compile down to JavaScript. You'd write CoffeeScript, run it through a translator, and the output would be valid JavaScript that browsers could run. The point was to get all of JavaScript's capabilities while escaping its syntax — the specific way you have to write instructions for the computer to understand them.

CoffeeScript added classes written in a way that actually made sense. It introduced arrow functions — a shorthand way of writing a small function without typing out the full word "function" every time, the way you might abbreviate "et cetera" as "etc." It added string interpolation (the ability to drop a variable directly into a piece of text without awkward concatenation), default parameters (so a function could assume a value if you didn't provide one), and destructuring (a shortcut for pulling specific pieces out of a complex object).

CoffeeScript was adopted quickly and enthusiastically. David Heinemeier Hansson — the Danish programmer who created the Ruby on Rails web framework and is widely credited with making web development dramatically more accessible in the mid-2000s — embraced it almost immediately. In 2011, Rails 3.1 shipped with CoffeeScript as the default JavaScript preprocessor, meaning new Rails applications would use CoffeeScript by default, though developers could opt out. GitHub, Dropbox, and a wave of early-2010s startups followed.

CoffeeScript is essentially dead today. Every feature that made it worth using has since been added to JavaScript itself. That's not failure — that's the whole point. The language committee that governs JavaScript's evolution, watching what developers actually wanted, incorporated CoffeeScript's best ideas directly. Arrow functions, classes, default parameters, destructuring — standard JavaScript now. The Fireship video puts it plainly: every time a modern developer writes those features, "you can thank CoffeeScript."

His third tool was Backbone.js, released in 2010. This one addressed a different kind of problem.

Even with Underscore handling common operations and CoffeeScript providing better syntax, JavaScript applications still had no structure. If you were building something large — say, an interactive dashboard or a complex user interface — you'd end up with thousands of lines of code where your data, your page-rendering logic, and your event handling (what happens when a user clicks something) were all tangled together. Add a feature and you'd break something else. Fix that and break something new.

Backbone introduced a way of organizing JavaScript applications called MVC — Model, View, Controller — a pattern borrowed from server-side programming. The model is your data. The view is what gets displayed to the user. The controller is the logic that connects them. Keeping these three things separated means a change to your data doesn't automatically scramble your display logic. Backbone's implementation of this was compact — the library itself was only a few hundred to a couple thousand lines of code, depending on the version — but it was enough to prove the concept worked.

Trello, Airbnb, Hulu, and Pinterest all built early versions of their products on Backbone. For a few years, it was the default choice for any serious JavaScript application. Angular, then Ember, then React eventually offered more powerful approaches and pushed Backbone aside. But Backbone was the proof of concept. It demonstrated that you could build a serious, large-scale application in JavaScript on the client side — in the browser, rather than on a server somewhere — without the code collapsing into chaos.

The Question the Story Raises

Here's what I find genuinely interesting about Ashkenas's trajectory, and what the Fireship video gestures toward without quite landing on: all three of his tools succeeded by making themselves unnecessary.

Underscore's features went into JavaScript. CoffeeScript's features went into JavaScript. Backbone's ideas went into React and its successors. None of the tools survived in wide use. All of the ideas did.

Software history is littered with this pattern. The browser wars of the 1990s produced innovations in HTML and CSS that became standards. The blogging platforms of the early 2000s produced conventions that became the template for social media. The tool gets superseded; the insight it contained gets inherited by whatever supersedes it.

What makes Ashkenas's case worth examining is that he ran this cycle three times in roughly two years, across three different categories of problem, and all three outcomes held. That's not luck. That's someone who understood what was actually broken and fixed exactly that, without overbuilding.

The Fireship video frames this as a story about a forgotten hero. That's a reasonable frame. But there's another way to read it: this is what successful infrastructure work looks like. You solve a real problem clearly enough that the solution becomes so obvious in hindsight that people forget there was ever a problem. The JavaScript you use today — or that runs quietly behind every website you visit — works the way it does in part because of decisions Ashkenas made in 2009 and 2010.

He didn't save JavaScript. He bought it enough time to save itself.

By Bob Reynolds, Senior Technology Correspondent, BuzzRAG