09 — Pick a Framework — Where the Reactivity Work Happens

I used to look at frontend frameworks like a wall of rival soda brands. React, Vue, Angular, Svelte, SolidJS — five logos, five websites, five different ways to write the same button. It felt like picking a side, and I had no idea what I was actually choosing between.

Writing these notes finally straightened it out. It turns out all five are doing the exact same job, just in different places. Here's the one idea everything else hangs off: a framework is an agreement about how to turn your data into what's on the screen, reliably. You hold some data (developers call this state). The framework's job is to make the screen match that data, every time the data changes.

That job has a name: reactive UI. Instead of writing code that reaches into the page by hand and changes things — "set this text, update that number" — you just describe how the screen should look for a given set of data, and let the framework do the updating for you [1]. All five frameworks do this. The only thing that actually separates them is one question I couldn't see until I wrote it down: where does the updating work happen?

Three lanes, not five rival teams. Once that clicks, "which framework?" stops being brand loyalty and becomes a practical question: where do I want the work to live, and how much do I want the framework to decide for me?

The one thing they all share

Before we split into lanes, let's look at what all five have in common.

Picture a simple counter on a page. With plain JavaScript, every time the number changes you'd have to remember to reach into the page and update that number yourself — find the right element, set its text, again and again. On a real app with hundreds of moving parts, that's a nightmare to maintain: forget one place, or do them in the wrong order, and the screen drifts out of sync with your data.

A framework takes that whole chore off your hands. You declare "the counter shows count," and something else takes responsibility for keeping that true whenever count changes. That "something else" is the reactivity system — the part of the framework that watches your data and updates the screen for you [1][2].

That's the whole trick. Components, props, hooks, stores, templates — all the vocabulary people throw around — is just scaffolding built around this one promise. Understand the promise, and the three lanes below fall out naturally.

Lane 1 — update in the browser: React and Vue

React and Vue do their reactivity work in the browser, while the app is running [2][3].

Here's the picture that made it stick for me. Imagine your component as a little recipe: you hand it some data, and it hands back a description of what the screen should look like. React and Vue don't write that description straight onto the page, though. They first write it onto a lightweight copy of the page kept in memory, called the virtual DOM — think of it as a draft sketch of the real page. When your data changes, the component draws a new draft, the framework plays "spot the difference" between the old draft and the new one, figures out the smallest set of changes, and applies just those changes to the real page.

Both work this way; the day-to-day feel just differs a little. React stays close to plain JavaScript — you describe the screen with code, and "the screen is a function of your data" is taken quite literally [2]. Your data lives in little containers called hooks, and the component re-draws when you tell it the data changed. Vue leans on HTML templates plus a smart tracking layer: you assign a value, and Vue quietly remembers exactly which parts of the template care about that value [3]. Vue tracks dependencies more precisely than React, but it still reconciles against a virtual DOM, so it lives in the same lane.

The cost of this lane: the browser has to carry a bit of extra machinery, and every update pays a small "compare and patch" fee. The upside is flexibility — you can build the screen from any code you like, and the same idea ports to other targets (React Native uses it for mobile). It's also, not coincidentally, the most popular lane in the industry, which matters for jobs and tutorials whether we like it or not.

Lane 2 — update before it ships: Svelte and SolidJS

Svelte and SolidJS move the reactivity work out of the browser and into the packaging step — the moment when your app is built, before anyone opens it [4][5].

Think of it this way: in React and Vue, the component is alive in the browser, drawing drafts and playing spot-the-difference. In Svelte and SolidJS, the component is more like source code that gets read during the build. While packaging the app, the builder looks at which parts of the page depend on which pieces of data, and it writes plain JavaScript that connects each part directly to the data it cares about. No draft, no spot-the-difference, nothing extra to carry into the browser — just the exact instructions the page needs.

The two differ in how you express that reactivity. Svelte puts HTML, JavaScript, and CSS together in a single file and figures out the connections from your assignments — then generates the update instructions for you [4]. SolidJS keeps React-style syntax so it looks familiar, but underneath it uses something called signals: each piece of data is its own little signal, and the build step connects each part of the page to exactly the signals it reads [5]. So changing one value updates one spot — not a whole section of the page.

The cost: the packaging step is mandatory. A Svelte or Solid component isn't runnable JavaScript until it's been built, so you can't just drop it into a page and go. The win: speed and a smaller download — there's no extra framework machinery to carry, and updates skip the compare step entirely. This is the lane I'd reach for when how fast the page feels, or how much data it has to download, matters more than a huge ecosystem.

Lane 3 — the whole toolkit: Angular

Angular sits in its own lane because it isn't just a way to draw the screen — it's an all-in-one toolkit with a strong opinion about how to build an entire application [6].

It still does reactive UI: your component renders from your data, and a change-detection system keeps the page in sync. But on top of that, it bundles in everything a big app tends to need, all made by the same team and designed to fit together: a router (for moving between pages), dependency injection (a way to hand each component the things it needs), a forms system, an HTTP client (for talking to a server), a way to manage data, a command-line tool, and a testing setup.

The cost is weight and opinion. Angular pushes you to use TypeScript and tells you how to structure things, so the learning curve is steeper and there's more boilerplate up front. The payoff is that on a large team, those shared rules end a hundred "but how do we do X?" arguments — the framework already decided. That's why Angular's reputation lives in large enterprise codebases: the "everything included, one way to do things" bet pays off when the project is big enough that the shared rules save more time than they cost [6]. It's the lane I'd pick when "one official way to do everything" beats "we want to choose our own pieces."

How the lanes actually differ

The one question is the headline; the day-to-day consequences are where it shows up. Here's the whole thing in one table:

A few of those worth spelling out:

• What the browser carries. React and Vue ship some extra machinery. Svelte and SolidJS ship plain generated JavaScript, nothing extra. Angular ships the machinery and its toolkit.
• What runs on each update. React and Vue compare and patch. Svelte and SolidJS run instructions that go straight to the changed spot. Angular checks for changes across the screen, tuned by its OnPush optimization.
• Who decides structure. React and Vue give you components and leave the architecture to you. Svelte and SolidJS are similar but lighter. Angular decides the architecture for you.
• Ecosystem and jobs. React's is the biggest by a wide margin [2]; Vue is strong, especially in certain markets; Angular owns the enterprise niche; Svelte and SolidJS are smaller but growing.

None of these is "the best." They're trade-offs along the one axis that matters: work in the browser vs. work during packaging, freedom vs. opinion, ecosystem vs. efficiency.

How I use this

The practical payoff is that "which framework?" becomes a calm question instead of a religious one. When someone asks, I don't reach for a brand anymore — I ask which lane fits the constraints.

• Small app, want to move fast, ecosystem matters? React or Vue.
• Care about speed or download size, and a build step is fine? Svelte or SolidJS.
• Large team that needs shared rules and a full toolkit? Angular.

The brand is downstream of the lane; the lane is downstream of the problem. That ordering is the whole reason I wrote these notes down.

References

[1] roadmap.sh, "Frontend Beginner — Pick a Framework," 2024. [Online]. Available: https://roadmap.sh/frontend/learn-a-framework

[2] React Team, "Quick Start — Thinking in React," react.dev, 2024. [Online]. Available: https://react.dev/learn

[3] Vue.js Team, "Reactivity in Depth," vuejs.org, 2024. [Online]. Available: https://vuejs.org/guide/extras/reactivity-in-depth.html

[4] R. Harris, "Virtual DOM is pure overhead," svelte.dev, 2018. [Online]. Available: https://svelte.dev/blog/virtual-dom-is-pure-overhead

[5] SolidJS Team, "Reactivity — SolidJS Documentation," solidjs.com, 2024. [Online]. Available: https://www.solidjs.com/docs/latest#reactivity

[6] Angular Team, "Introduction to the Angular docs," angular.dev, 2024. [Online]. Available: https://angular.dev/overview