The Puppeteer: What Frameworks Actually Solve

Take the to-do list you built by hand in the DOM article, and add ordinary things to it.

A counter of unfinished items. A filter for all, active and done. A "clear completed" button. An edit mode for a single row. A "select all" checkbox that reflects whether everything is ticked.

Nothing there is difficult. But now the same fact — this item is done — is displayed in four places, and every action must update all four in the right order. Ticking a box means: change the data, change the row's class, recompute the counter, re-evaluate the filter, update the "select all" state, and enable or disable "clear completed". Add one feature and you add a handful of new pairs to keep in agreement.

The code isn't hard. It's endless bookkeeping, and the bugs it produces are all the same bug: something on screen quietly disagrees with the data behind it.

A framework doesn't draw your screen. It removes the job of describing every transition between one screen and the next.

The one idea

Every modern framework rests on a single equation: the interface is a function of state.

You stop writing "when this is clicked, find that element and change its class." You write "for this state, the screen looks like this" — and separately, "this event changes the state." The framework works out the difference and applies it.

That's the whole shift, and it's worth stating in the two vocabularies people use. The old way is imperative: a sequence of instructions for getting from the current screen to the next one. The new way is declarative: a description of the destination, with the route left to the machine. It's the same difference as between giving directions turn by turn and giving an address.

What you gain is that the number of things to keep in your head stops growing with the number of features. You never write the transition from "three items, filter active, one selected" to "two items, filter all, none selected" — and there are hundreds of such transitions in even a small application. That's the job being removed.

How they do it

The implementations differ, and it's worth knowing they differ, because people mistake one implementation for the idea.

React re-runs your component function to produce a lightweight description of the desired output, compares it with the previous description, and applies the minimal set of real DOM changes. That comparison step is the virtual DOM.

Svelte does the work at build time: a compiler reads your component and generates code that updates exactly the right nodes, so there's no comparison at runtime.

Vue, Solid and modern signal-based approaches track dependencies precisely: each piece of state knows which bits of the interface use it, so a change updates only those.

Three different strategies, one identical promise: you describe the result, the machine finds the difference. Which means the concepts you learn — state, props, components, derived values, effects — transfer between them, while the syntax doesn't. Learn the concepts and your second framework costs a week.

Components, and a separation people misunderstand

The other half of the idea is the component: a piece of interface that owns its markup, its behaviour and its styles, exposes a small interface to its parent, and can be used in many places.

This looked wrong to a generation raised on "separate structure, presentation and behaviour into different files." But that rule was separation by technology, and it produced three files that could only be understood together and changed together. Components separate by feature: everything about a search field lives in one place, and you can delete it without archaeology.

Two things follow directly. A component should be small enough that you can hold its whole behaviour in your head — that's not aesthetics, it's the working memory limit from the How to Learn sphere applied to code. And the boundaries should follow the interface's real seams, which are usually the same seams a designer would name.

JSX in one paragraph

If you learn React you'll meet JSX, and it causes a specific confusion worth clearing up immediately: it is not HTML inside JavaScript. It's syntax that compiles into ordinary function calls that produce objects. That's why class becomes className, why attribute names are camel-cased, and why you can put any JavaScript expression inside it — you're building a data structure, not writing markup.

Understanding that one sentence prevents a category of confusion that otherwise lasts months.

What it costs

The honest list, because frameworks are usually sold without one.

Weight and complexity. A framework is code shipped to every user, plus a build step, plus a set of conventions to learn. For a page of static content it's pure cost.

Churn. The ecosystem moves. Answers online may describe a version three years out of date, and the tutorial you learned from may already teach a discouraged pattern. This is inconvenient, and it makes reading the official documentation a genuine skill rather than a fallback.

Learning it in place of the language. This is the expensive one. Someone who learned React first can build a page and cannot explain what map returns, why their array didn't trigger a re-render, or what to do when the framework isn't the answer. The How to Learn sphere has a name for the shape of that failure — the jammed key, the method drilled so thoroughly that alternatives stop being visible. Everything becomes a React problem, including the problems that aren't.

Which is exactly why the previous stage came first. The framework is a layer on top of the DOM, and it leaks: sooner or later you'll integrate a library that expects a real element, debug something the framework did to your event, or need a plain script. The layer beneath is not optional knowledge.

When you don't need one

Worth saying plainly, because it's unfashionable: a great many pages don't need a framework.

Static content, a marketing site, a documentation page, a form, a small widget on an existing page — the platform now handles these well, and a hundred lines of plain JavaScript will be faster to build, faster to load, and still working in five years with no maintenance.

The signal that you do want one is shared state that appears in several places and changes over time. Dashboards, editors, anything with a cart, anything with live data. That's the bookkeeping problem, and that's what the framework earns its weight against.

Choosing, and what actually transfers

React has the largest ecosystem and the most jobs, and is therefore the default answer if you're learning to be employed. Vue is famously approachable. Svelte is the smallest thing to hold in your head. Solid and the signal-based generation are where a lot of the recent thinking has gone. Angular remains the standard in a certain kind of large organisation.

The important advice isn't which. It's: learn one properly and don't sample. Building four small applications in four frameworks teaches you four sets of syntax and one shallow model. Building four applications in one teaches you the model, and the model is the transferable part — components, state, derived values, effects, lists and keys, lifting state up, rendering strategy. Those words mean the same thing everywhere.

And a warning that follows from the same place: after learning one, deliberately look at how another solves the same problem, once. Not to switch — to see the shape of the idea separately from one implementation of it. Understanding is being able to view the same object from more than one angle, and a single framework viewed from inside is precisely one angle.

In practice

Feel the problem first. If you haven't built something by hand where the same value appears in three places, do it before continuing. Twenty minutes, and everything below has a reason.

Convert that same hand-built thing into a framework version. Same feature set, same evening. The comparison is the lesson, and it's far more instructive than a fresh tutorial project.

Say the state out loud before writing a component. What does this piece of interface need to know to draw itself? That question is nine-tenths of the design, and the next article is entirely about answering it well.

Read the official documentation, not the tutorials. Framework documentation is unusually good these days, and it's the version that isn't three years out of date.

Resist the second framework for six months. Depth transfers; breadth at this stage doesn't.

Check yourself

Close the article and answer in your own words:

What exact job does a framework take off you, and why does it grow faster than the feature list?
What does "the interface is a function of state" mean in practice?
Give the difference between imperative and declarative in one sentence each.
Name three different implementation strategies and what they have in common.
Why isn't "components mix HTML, CSS and JS" a violation of separation of concerns?
What is JSX actually, and what does that explain?
When is a framework the wrong choice?

In short

Build anything real by hand and the bookkeeping between data and DOM grows faster than the features do; that's the job a framework removes.
Every framework rests on one equation: the interface is a function of state, described declaratively instead of transitioned imperatively.
Virtual DOM, compilation and signals are three strategies for the same promise, so the concepts transfer even though the syntax doesn't.
Components separate by feature rather than by technology, and should stay small enough to hold in your head.
JSX is not HTML in JavaScript — it compiles to function calls producing objects, which explains most of its oddities.
The costs are weight, ecosystem churn, and the serious risk of learning a framework instead of the language beneath it.
Static pages, forms and small widgets often don't need one; shared state appearing in several places is the signal that you do.
Learn one framework deeply rather than sampling four, then look at one other once — to see the idea apart from a single implementation of it.