Why do so many websites use a framework?

The full story

The episode's narration, word for word. Numbers link to the sources below; timestamps play that moment.

The question 0:00

Open almost any app in a browser and things change while you watch: a message count ticks down, a cart fills up, a feed grows ¹. Behind many of those apps sits a framework, with names like React, Angular or Vue ¹. So why do so many websites use one? First, let's check how many really do. Then, what problem were they built to solve?

Check the premise 0:28

The web survey firm W3Techs tracks a sample of well over twenty million websites, and updates its figures every day ². On the seventh of October 2026, it found JavaScript on 98.9 percent of them ³. About three quarters used a JavaScript library of some kind ⁴. But the big one was jQuery, from 2006, on 65.4 percent of all websites ^4,5. React was on six percent, and Next.js, which is built on React, on 3.5 ⁴. Angular and Vue were each on less than one ⁴. So by that count, most websites don't use a modern framework at all ⁴.

Two ways to count 1:14

Now ask the people building things. In Stack Overflow's 2025 survey, 44.7 percent of developers who answered had done extensive work in React in the past year ⁶. Angular and Vue each came in around eighteen percent ⁶. The survey counts the old AngularJS separately, while the Angular figure from W3Techs may include it ^4,6. Both numbers are honest. W3Techs counts websites, so one huge app counts once, the same as a small blog ². And a lot of that jQuery comes bundled with WordPress sites ⁷. The better question is: why do so many new web apps use one?

A page that changes 1:59

Start with the problem. A web page isn't a printed poster any more. It's the DOM, the page held in the browser's memory, from episode three, and JavaScript can change it at any moment ¹. Meanwhile the app keeps its own data, which programmers call state: how many messages are unread, what's in your cart ¹. The two have to agree. As the Mozilla developer guide puts it, every time the state changes, you need to update the page to match ¹.

Facebook's unread count 2:30

Facebook's engineers hit this head on, as the docs for Flux, a pattern Facebook used alongside React, explain ⁸. They wanted to show a count of unread message threads, while another part of the page listed the threads, with the unread ones highlighted ⁸. Mark one thread as read, and that change had to reach the thread and the counter ⁸. In a large app, they wrote, knock-on updates like that lead to a tangled weave of data flow, with unpredictable results ⁸.

The bug, in real code 3:01

Here's that kind of bug in a few lines of real JavaScript, run for this episode. Two places on the page show the unread count. The function that marks a message as read updates the badge, but forgets the title. So the page now says two unread in one place and three in the other. Nothing crashed. The page just disagrees with itself, and in a big app, often nobody notices until a user does.

The jQuery years 3:31

In January 2006, a programmer named John Resig showed off a new library at BarCamp NYC, an informal tech get-together in New York ^9,5. He called it jQuery ⁹. Back then, browsers disagreed about how to do basic things to a page, and jQuery smoothed those differences away ⁵. Its motto was write less, do more ⁵. It made every change to the page shorter. But you still wrote each change yourself ^5,10.

Directions, not addresses 4:04

That style has a name: imperative, meaning you give the computer step-by-step instructions ¹¹. It's like giving someone turn-by-turn directions. Every direction has to be right, and one wrong turn, like that forgotten title, and you're lost. The alternative is declarative: you describe what the page should look like for the data you have, and let the framework work out the steps ¹. That's giving someone the address instead of the directions. React's own guide uses the same picture ¹¹. Where it breaks: someone still has to plan the route, and in a framework that planning is extra code that has to run ¹.

AngularJS: follow the data 4:46

One of the first big attempts came from Miško Hevery, who began AngularJS in 2009 ¹². It was released as open source in October 2010, and Google went on to maintain it ¹². Its headline idea was two-way data binding: keep the data and the page in sync automatically, in both directions ¹². Change the data, and the page follows. Type into the page, and the data follows.

React: describe it again 5:19

At Facebook, Jordan Walke built React, first used on the News Feed in 2011 and released to everyone in May 2013 ¹³. Its idea sounded almost reckless. Don't track which parts of the page to change. When the data changes, just describe the whole page again ¹⁰. As Pete Hunt put it on React's blog that June: when your data changes, the render method is called again ¹⁰. Render is simply the function that describes the page.

Declarative, in real code 5:51

Here's our inbox again, written that way, and run. One small function describes the badge and the title from a single number. Whenever the number changes, we describe the page again ¹⁰. There's no separate update for the title, so there's nothing to forget. The page says two unread, everywhere it looks.

Building blocks 6:14

Frameworks also split a page into components: small, reusable pieces that each describe one part of the page ¹. A list item is a component. A list built from list items is another. A whole page is components inside components, like building blocks ^1,10. The analogy breaks a little, because real components can also hold their own data and pass it to each other ^1,13. And they still follow episode one's rule: you write the pieces, and the framework calls them ¹⁰.

Tags inside JavaScript 6:49

React components are usually written in JSX, which lets you put tags that look like HTML right inside JavaScript ¹³. Plain JavaScript can't read it, so a tool translates it first ¹³. We ran this one through Deno, which does that translation itself, with a tiny stand-in for React, and it printed the paragraph. React itself wasn't run here, but the syntax is real.

Vue: the part he liked 7:18

Evan You had worked with AngularJS at Google ¹⁴. In his words, he wondered what would happen if he could extract the part he really liked about Angular and build something really lightweight ¹⁴. Vue appeared in February 2014 ¹⁴. It also describes the page from the data, and it tracks which data each piece uses, so it knows what to update ^15,16. Google, meanwhile, rewrote AngularJS from scratch as Angular, released in 2016 ^1,12.

Isn't that wasteful? 7:49

Redescribing the whole page on every change sounds wasteful. React's trick is that the description is cheap: not the real page, just a lightweight sketch of it ¹⁰. It keeps a lightweight copy of the page in memory, often called the virtual DOM ¹³. After each change it compares the new description with the old one, and applies only the differences ^10,13. React calls that reconciliation ¹⁰. Think of a spot-the-difference puzzle: only repaint what changed.

A spot-the-difference, in real code 8:22

This toy version, run for this episode, compares two shopping lists and finds the one row that changed. Real pages are trees, not lists, and that's where the puzzle analogy breaks ¹⁷. React's own documentation says the best general method for comparing two trees would need around a billion comparisons for a thousand elements ¹⁷. So React uses two rules of thumb instead, which its documentation says hold for almost all practical cases ¹⁷.

The fair argument 8:54

Not everyone thinks the virtual DOM is a good deal ¹⁸. In 2018, Rich Harris, who created Svelte, wrote that diffing isn't free ^18,19. Svelte is a compiler instead: it works out the updates when the app is built, not while it runs ¹⁸. But even he agreed on the goal ¹⁸. Virtual DOM isn't a feature, he wrote, it's a means to an end: declarative, state-driven pages, with performance that is generally good enough ¹⁸. The frameworks disagree on how. They mostly agree on what.

The cost: weight 9:29

Now the fair criticism. Mozilla's guide is blunt: the convenience isn't free, because the framework has to run its own code, which makes the app larger and more work to run ¹. The median mobile page carried 359 kilobytes of JavaScript in 2019, and 558 in 2024, about fifty-five percent more ⁷. Not all of that is frameworks; ads and analytics count too ⁷. And for a site of a few simple pages, Mozilla says you may not need a framework at all ¹.

The cost: churn 10:05

The other complaint is churn: things change fast, and you have to keep up. The new Angular couldn't run old AngularJS apps, and support for AngularJS ended on the last day of 2021 ¹². React brought in a new way to write components in 2019, called Hooks ¹³. And old versions linger: among websites using React, by W3Techs's count, 71.3 percent are still on version sixteen ²⁰. Churn is real, and so is the old code that never moves.

So why? 10:39

So why do so many new web apps use a framework? Because the hard part isn't changing a page, it's keeping every part of it in step with the data, and that gets harder with every feature you add ^1,8. A framework lets you describe the page once, in pieces, and does the bookkeeping, at a price in weight and in change ^7,1,18. Meanwhile 40.1 percent of all websites run on WordPress, and WordPress is written in a very different language, PHP ^21,22. Why does a much-mocked language still run so much of the web?

Sources

Every factual claim in the episode is tied to one of these. Spotted an error? Tell us.

1. MDN Web Docs, "Introduction to client-side frameworks" — developer.mozilla.org
2. W3Techs, "Technologies overview" and methodology — w3techs.com
3. W3Techs, "Usage statistics of client-side programming languages for websites", 7… — w3techs.com
4. W3Techs, "Usage statistics of JavaScript libraries for websites", 7 October 2026 — w3techs.com
5. Wikipedia, "jQuery" (accessed 7 October 2026) — en.wikipedia.org
6. Stack Overflow Developer Survey 2025, Technology (web frameworks and technologies) — survey.stackoverflow.co
7. HTTP Archive, Web Almanac 2024, chapter 1: JavaScript — almanac.httparchive.org
8. Facebook Flux documentation, "In-Depth Overview" — github.com
9. John Resig, "BarCamp NYC Wrap-up", 16 January 2006 — johnresig.com
10. Pete Hunt, "Why did we build React?", React blog, 5 June 2013 — legacy.reactjs.org
11. React documentation, "Reacting to Input with State" (imperative vs declarative; the… — react.dev
12. Wikipedia, "AngularJS" (accessed 7 October 2026) — en.wikipedia.org
13. Wikipedia, "React (software)" (accessed 7 October 2026) — en.wikipedia.org
14. Wikipedia, "Vue.js" (accessed 7 October 2026) — en.wikipedia.org
15. Vue.js documentation, "Introduction" — vuejs.org
16. Vue.js documentation, "Reactivity in Depth" (effects track their dependencies) — vuejs.org
17. React documentation (legacy), "Reconciliation" — legacy.reactjs.org
18. Rich Harris, "Virtual DOM is pure overhead", Svelte blog, 27 December 2018 — svelte.dev
19. Wikipedia, "Svelte" (accessed 7 October 2026; created by Rich Harris) — en.wikipedia.org
20. W3Techs, "Usage statistics and market share of React", 7 October 2026 — w3techs.com
21. W3Techs, "Usage statistics of content management systems", 7 October 2026 — w3techs.com
22. Wikipedia, "WordPress" (accessed 7 October 2026) — en.wikipedia.org

Researched and scripted with AI assistance, fact-checked claim by claim, with synthetic narration and diagrams drawn in code. How we make episodes.