Why frameworks exist

A framework such as React, Vue, Svelte or Angular builds an interface from components and derives the view from state. This is called reactivity.

When hand-written code starts to crumble

Over four lessons you wrote quite a lot for your page: a summary, quick links, a menu, search, loading the list. Every piece worked. But did you notice that in the fetch lesson the quick links had no place for the new item? The script built them when the page opened, then the list changed, and nobody told them.

This is the main difficulty of interfaces. State (which items exist, what is typed in the search, whether the menu is open) lives in one place, but it’s shown in several: in the list, in the counter, in the links, in the aria-expanded attribute. Every time the state changes, you must update every place that shows it. While there are two, that is easy. When there are five, and three ways to change the state, the number of combinations grows, and somewhere something is sure to be forgotten. You get a page that says “3 items” in the counter and shows five cards in the list.

In hand-written code it looks like this:

function addItem(item) {
  items.push(item);
  list.append(makeCard(item));            // 1: the list
  counter.textContent = items.length;     // 2: the counter
  badge.textContent = items.length;       // 3: the menu badge
  quickNav.append(makeLink(item));        // 4: the quick links
  // …and nothing reminds you if you forget the fifth
}

What was invented instead

Different teams arrived at one idea: the view is derived from state. You don’t write “find the counter and rewrite it”. You declare: “the counter equals the length of the list”. The library takes care of the rest: when the list changes, it finds what needs updating. This approach is called reactivity.

A second idea almost always comes with it: the component. A piece of interface (a card, a menu, a form) is made a unit of its own, with its own data, markup and styling, and the page is assembled from such pieces. You met this in the design systems lessons, and here it becomes code.

With these two, frameworks usually bring routing (which page at which address), management of shared state, a build and a ready-made ecosystem of plugins and components.

Who is who

There are many frameworks, and they differ in how they carry out the same idea.

• React (Facebook, 2013) describes an interface with function components and JSX, a notation that looks like HTML inside JavaScript. The idea: you “draw” the interface again each time, and the library compares it with the previous one (the so-called virtual DOM) and changes only the differences. Today it’s the most widespread.
• Vue (Evan You, 2014) likes templates close to HTML, and reactive data. It’s considered the gentlest to start with.
• Angular (Google; the first one, AngularJS, in 2010, rewritten completely in 2016) is a full framework in TypeScript with its own project structure. It’s common in large corporate systems.
• Svelte (Rich Harris, 2016) solves the same task differently: it’s a compiler. It analyzes your component at build time and produces minimal plain JavaScript that updates the right nodes directly, so there’s almost no heavy library in the browser. This textbook itself is written in Svelte 5.
• Above them stand the meta-frameworks: Next.js (over React), Nuxt (over Vue), SvelteKit (over Svelte) and Astro. They add routes, rendering on the server and delivering ready HTML, which we discuss in the part on site generators and Jamstack.

Around 2016 the phrase “JavaScript fatigue” appeared: new tools came out faster than people could learn them. It helps to remember that they all share one root: the view is derived from state.

See where the complexity grows

One counter of items is shown in several places on the page. Choose how many places depend on it, and add items. Compare the manual version, where the programmer must remember every place, with the reactive one, where the number is derived from state:

list.textContent = items.length;
counter.textContent = items.length;
menuBadge.textContent = items.length;
quickNav.textContent = items.length;

let items = $state(3);
list: {items}
counter: {items}
menuBadge: {items}
quickNav: {items}

The price

A framework isn’t free, and it isn’t only the developer who pays.

• Weight. The library and your code arrive in the browser as JavaScript. A kilobyte of script costs more than a kilobyte of image: an image only has to be shown, while a script must first be downloaded, then parsed, then run. Until it has run, the page may look fine but be dead: the buttons don’t respond.
• Weak devices. A budget phone parses the same script many times slower than your laptop. The Web Almanac report in the sources shows how much JavaScript pages usually weigh.
• Complexity. A build, dependencies, version updates, ways to store state: that is separate work, and it has to pay for itself.
• Search engines and the first paint. A page drawn entirely by a script is empty until the script has run. Modern search engines can cope with that, but at a higher cost and less well. That’s why meta-frameworks send ready HTML at once and “bring it to life” with a script later.

When you need a framework and when you don’t

Honest criteria you can apply to any project.

Probably not needed: a business card site, a landing page, a blog, a services page. There’s little interactivity (a menu, a form, search), three or four places to keep in step, and it all fits in your head. Plain JavaScript and a few modules keep the page light.

Probably needed: an account area, a store with a cart, an editor, a dashboard with charts, anything with many screens, shared state and data that changes by itself. Hand-written code drowns in synchronization here, and a framework pays off.

And a third point, the most important: the decision can be revisited. Starting with plain JavaScript and moving to a framework when you reach the tenth place to keep in step is a normal path.

Practice

You’re on a 2019 site, where frameworks have long been the norm. But let’s look not at frameworks in general but at your own page: how many places on it are kept in step by hand, and does it need a framework?

The table has three columns: what is kept in step with what, how it is done now and how it would work in a reactive way. At least three rows: anything you wrote in the earlier lessons will do. Then the verdict, “needed” or “not needed”, with numbers from your brief (how many sections, how many items). And the weight of your scripts: estimate it roughly from the Network tab or from the size of the code.

“Not needed” is a correct answer too, and often the right one. What matters more is that your page supports it.

What was wrong before

When there were no frameworks, everything was written by hand, and later with jQuery, and big pages turned into spaghetti: dozens of handlers that change each other’s elements, and nobody remembers what depends on what. In 2010 the first frameworks appeared (Backbone, AngularJS), then React with the idea “an interface is a function of state”. But the new era had its excess too: a five-page business card site was built as a heavy single-page application that took tens of seconds to open on a weak phone, while search engines saw an empty page.

What remains true is the essential: the view is derived from state, and an interface is assembled from components. And what is superfluous is a heavy tool where a light one would do.