The frameworks that lost

Every framework that won is discussed endlessly. The ones that lost are more interesting, because losing was rarely about being worse.

Most of them were beaten by timing, by a company’s willingness to fund a developer relations team, or by betting on a standard that arrived four years late. Several were technically ahead of what beat them. And nearly all of their best ideas are in the framework you use now, uncredited.

Backbone — the one that made the argument

Before Backbone, front-end code was jQuery selectors all the way down. There was no shared vocabulary for “this part of the page is a thing with state”.

Jeremy Ashkenas shipped Backbone in 2010 at roughly 800 lines. It gave you models, collections, views and events, and then got out of the way. No templating opinion, no build step, no data binding. You wired it up yourself.

What killed it: exactly that restraint. Backbone told you what the pieces were and left the wiring to you, which meant every Backbone codebase was different, and most of them were held together with manual render() calls that you had to remember to trigger. React’s insight — stop wiring, just re-render and diff — made the entire category of Backbone bug disappear.

What survives: the idea that the DOM is a projection of state rather than the place state lives. That’s the whole premise now. Backbone made the argument first and got no credit for winning it.

Ember — the one that was right too early

Ember shipped a router, a build system, a data layer, an addon ecosystem and a strict set of conventions, at a time when the industry was still congratulating itself on unopinionated micro-libraries.

The reaction was that Ember was heavy and dictatorial. Convention over configuration was a Rails idea and the front end wasn’t ready for it.

What killed it: nothing, really — Ember is still maintained and still shipping. It just stopped being the default while everyone spent five years assembling React, a router, a state library, a build tool and a testing setup by hand, and then invented Next.js, which is a framework that ships a router, a build system, a data layer and a strict set of conventions.

Ember’s actual mistake was being correct before the audience had suffered enough to agree.

What survives: the entire meta-framework category. Also Tomster, who remains the most likeable mascot in front-end by a distance — and who earns his place in the field guide to language mascots.

Polymer — the one that bet on the standard

Google’s argument was that we shouldn’t need frameworks at all. The browser should have components natively, so Polymer was a thin layer over Web Components while the specs matured.

It was an honourable bet and it did not pay.

What killed it: the specs took years. HTML Imports were dropped. Browser support arrived in pieces and Safari held out on parts. By the time Web Components genuinely worked everywhere, React had won and nobody wanted to relitigate it. Google itself moved to Lit.

What survives: Web Components are real and shipping — inside design systems, inside enterprises that need framework-agnostic widgets. It’s the standard that succeeded while its flagship framework did not.

Aurelia — the one that was too quiet

Rob Eisenberg left the Angular 2 team and built the framework he thought Angular should have been. Aurelia was standards-first, unusually clean, and it had genuinely better ergonomics than most of what it competed with.

What killed it: nobody’s marketing department. React had Meta, Angular had Google, Vue had a genuinely remarkable one-man publicity effort. Aurelia had a good framework and a small team, and it turns out that isn’t enough.

This is the least satisfying entry on the list because there’s no technical lesson in it. It was simply better than its market share.

Inferno — the one that won on the benchmark

Inferno was React’s API with a hand-optimised rendering path, and for a while it topped every benchmark going. Faster than React, faster than most things, same mental model.

What killed it: performance stopped being the axis anyone cared about. React was fast enough, and everything else — ecosystem, hiring, documentation, the fact that your next colleague already knew it — mattered more. Being 30% faster does not overcome a network effect.

What survives: the pressure. React’s own performance work through that era was in part a response to being outrun by projects like Inferno.

The pattern

Line them up and the reasons for losing are almost never “the code was worse”:

• Backbone was too unopinionated, and lost to a better idea
• Ember was right too early, and watched its ideas win under other names
• Polymer bet on a standards process slower than the market
• Aurelia had no distribution
• Inferno optimised the thing that had stopped mattering

Only Backbone lost on the merits, and even then it lost to an idea it helped make thinkable.

The uncomfortable conclusion is that framework outcomes are decided mostly by timing and distribution, and only partly by engineering. Which is worth remembering next time a benchmark is used to settle an argument.

Wearing your losses

There’s a specific kind of credibility in a laptop with an Ember sticker on it in 2026. It doesn’t say you’re current. It says you were here, you made a call with the information available, and you’re not embarrassed about it.

Everyone has a React sticker. Almost nobody has an Aurelia one.