Why are there so many
JavaScript frameworks?
Vue, React, Angular, Svelte — they all do similar things. Here's why they exist, where they came from, and what actually makes them different.
Websites used to be much simpler
In the early days of the web, a page was basically a document. You clicked a link, the server sent you a new page, and your browser showed it. Simple. The JavaScript on the page was mostly small stuff — a dropdown menu here, a date picker there.
But then websites started doing more. Gmail let you write and send emails without ever refreshing the page. Google Maps let you drag a map around in real time. Facebook updated your feed as new posts came in. These weren't documents anymore — they were applications that happened to run in a browser.
And that created a problem. JavaScript wasn't really built for this. When data in your app changed, you had to manually reach into the page and update it yourself. It looked something like this:
This seems fine for a counter. But imagine a real app: a shopping cart where the item count, the subtotal, the "checkout" button, and a sidebar summary all need to update when you add something. You'd need to remember to update every single place, every single time. Miss one and your UI shows the wrong thing. This is called being "out of sync" and it was the source of most bugs in web apps.
Real life version
Imagine a whiteboard in an office showing the number of orders received. Every time an order comes in, someone has to walk to the whiteboard and update the number. If they forget, the whiteboard is wrong. Now imagine there are five whiteboards in different rooms, all showing the same number.
The code version
Your app has data (the real order count). Your UI has multiple places showing that data (the whiteboards). Keeping them all in sync manually is error-prone and exhausting. The bigger the app, the worse this gets.
Developers tried different approaches to solve this. jQuery (2006) made it easier to manipulate the page, but didn't really solve the sync problem. AngularJS (2010) tried automatic two-way syncing — when the data changed, the page updated, and vice versa — but it got confused and slow in complex apps. Backbone gave you more structure, but you still did a lot of manual wiring.
Nobody had a really clean answer until 2013.
React's big idea: describe, don't instruct
In 2013, Facebook released React with a deceptively simple insight. Instead of writing code that says "when this changes, go update those things" — you write code that says "here's what the page should look like given the current data." Then React figures out what actually changed and updates only that.
❌ The old way (imperative)
"Go find the counter element. Change its text to the new number. Then find the button. Change its colour if the number is above 10. Then find the summary label..."
You tell the computer exactly what to do, step by step.
✅ The React way (declarative)
"Here's what the page looks like when count is 5. Here's what it looks like when count is 11. When count changes, you figure out the difference."
You describe the result you want. React handles the steps.
This is called declarative programming, and it solves the sync problem almost completely. You never forget to update a part of the UI because you're not updating individual parts — you're re-describing the whole thing and letting React work out what changed.
Think of it like this: instead of giving someone turn-by-turn directions (imperative), you give them the destination address (declarative). They figure out the route. React is the GPS.
React also introduced components — the idea that you build a UI by assembling reusable pieces, like LEGO bricks. A "Button" component, a "UserCard" component, a "ShoppingCart" component. Each one manages its own behaviour. You compose them together to build complex pages.
Here's the core formula that React introduced — and that every framework since has adopted:
The five ideas React established — which every framework since has kept:
Components
Build UIs from small, reusable pieces. Each piece manages its own logic and appearance.
Declarative rendering
Describe what the UI should look like. Don't write the steps to get there.
State is the source of truth
Your data lives in "state." The page is just a reflection of that data — not the other way around.
Everything in one place
A component's HTML, logic, and styles live together. Not split across three separate files.
Data flows one way: down
Data passes from parent components to child components via "props." Children tell parents about events via callbacks. There's one clear direction — no tangled two-way wires.
These five ideas are now universal. Vue has them. Angular has them. Svelte has them. Solid has them. If you understand these five things, you understand the core of every modern framework — they just implement them differently.
So why did other frameworks appear?
React solved the what — the mental model. But its how — the mechanism it used underneath — wasn't the only possible answer. React used something called a virtual DOM: a copy of the page kept in memory. When your data changes, React re-describes the whole page, compares the new description to the old one, and only applies the differences to the real page.
This was clever and it worked. But other developers started asking: is this the most efficient way to do it? Is there a way to skip the comparison step entirely? Can we make the updates even more targeted? And while they were at it — do we have to write everything in JavaScript, or can we have proper HTML templates?
The frameworks that came after React all kept its mental model. What they changed was the engine underneath, the way you write code, and how much they decide for you. Think of it like different car brands — same road, same destination, different engineering choices under the hood.
Before looking at each framework, here are the three big questions where they diverge:
How do updates actually happen?
React re-renders the component and diffs a virtual copy of the DOM. Vue uses reactive objects that track exactly which parts of the page depend on which data. Svelte's compiler rewrites your code at build time so updates go directly to the right DOM node. Solid skips re-rendering entirely — components set up subscriptions once, and only the exact expressions that changed get updated. All achieve the same goal by very different routes.
Do you write HTML or JavaScript?
React and Solid write everything as JavaScript — your markup is written inside JS functions using JSX syntax. Vue, Angular, and Svelte let you write real HTML and add logic with special attributes like v-if or {#if}. Neither is wrong — JS-first is very flexible, HTML-first feels more natural if you already know HTML.
How much does the framework decide for you?
React only handles the UI layer. You pick your own tools for navigation, data fetching, forms, and everything else. Angular is a complete platform — routing, HTTP, forms, and testing conventions are all built in and have one "Angular way" to do them. Vue and Svelte are closer to React (small and focused). This isn't better or worse — it depends whether you want flexibility or a paved road.
With those three questions in mind, here's how each framework answered them:
Evan You had worked with AngularJS and React and wanted something that took the best of both while being more approachable. Vue borrowed React's component model and one-way data flow, but kept HTML as the primary way to write templates — and added convenient two-way binding back for forms.
Vue's big selling point is being "progressive" — you can add it to an existing website with a single script tag, no build tools required. As your project grows, you can add the router, state management, and full tooling. Most frameworks are all-or-nothing; Vue lets you start small.
Vue components are .vue files with three clear sections: <template> for HTML, <script> for logic, and <style> for CSS. Many developers find this the most readable format of any framework.
Templates
HTML-first
Updates
Reactive proxies
Scope
Library (progressive)
Important: Angular (2016) and AngularJS (2010) share a name but almost nothing else. The 2016 version was a complete rewrite and is a completely different framework. Most people who say "I've used Angular" and disliked it were actually using the old one.
Angular is the most "batteries included" option. It comes with a router, an HTTP client, a forms library, testing utilities, and strong conventions for how to structure your code. It uses TypeScript (a stricter version of JavaScript) by default. If you join a large team that uses Angular, you can usually read and contribute to their code immediately — because there's one Angular way to do most things.
The trade-off is that Angular has a steeper learning curve and feels heavy for small projects. It shines in large enterprise teams where consistency and convention matter more than flexibility.
Templates
HTML-first
Updates
Zone.js → Signals
Scope
Full framework
Svelte's creator Rich Harris asked a provocative question: what if the framework didn't exist at runtime at all? Every other framework ships a library to the user's browser — code that runs to manage updates. Svelte instead runs at build time: a compiler that looks at your component and generates plain, optimised JavaScript that updates the DOM directly.
The result is that Svelte apps are tiny. There's no framework code in the bundle — just your app logic, pre-compiled into efficient instructions. For the developer, it also feels the most like writing plain HTML and JavaScript. Instead of calling special functions to create reactive values, you just write let count = 0 — and Svelte's compiler makes the assignment itself reactive.
Other frameworks are factories that run in the browser. Svelte is a factory that runs before the browser — it does the work at build time and ships the finished product.
Templates
HTML-first
Updates
Compiler-generated
Scope
Library
Solid looks almost identical to React on the surface — it even uses JSX. But under the hood it works completely differently. In React, when data changes, the whole component function runs again and React figures out what changed. In Solid, the component function runs exactly once — and only the specific tiny part of the page that depends on the changed data updates.
Think of it like this: in React, updating the counter is like repainting the whole wall every time a single tile changes. In Solid, only the tile itself gets repainted. This makes Solid extremely fast with very little effort.
Solid is the youngest of the major frameworks and has a smaller community, but it's popular among developers who want React's developer experience with significantly better performance.
Templates
JSX (JS-first)
Updates
Fine-grained signals
Scope
Library
A funny thing happened: everyone arrived at the same idea
If you follow framework development today, you'll notice something: Vue, Angular, Svelte, and Solid have all independently landed on the same underlying concept — called signals.
A signal is the simplest possible reactive value: a box that holds a piece of data, where anything that reads from the box automatically gets notified when the value inside changes. No diffing, no re-running the whole component — just a precise, direct connection between data and the part of the page that shows it.
Signals in real life
Imagine subscribing to a newsletter. Every time a new issue is published, it lands in your inbox — automatically, without you having to check the website. You're subscribed to exactly that newsletter, and you get exactly its updates.
Signals in code
A piece of UI "subscribes" to a signal. When the signal's value changes, that piece of UI updates — automatically, without re-running the whole component. Only the subscribers to that specific signal are notified.
The same primitive, four different names:
Vue 3
ref() Angular 16+
signal() Svelte 5
$state Solid.js
createSignal() React is the notable exception. It still uses virtual DOM diffing, and its answer to improving performance is the React Compiler — a tool that analyses your code at build time and automatically adds optimisations you'd otherwise write by hand. Different approach, same goal: do less unnecessary work when data changes.
The fact that four frameworks independently converged on the same primitive is a strong signal (pun intended) that signals are probably the right abstraction. The mechanisms started different and are ending up in the same place.
How they compare at a glance
Every framework in this table shares the five React pillars: components, declarative rendering, state as the source of truth, co-location, and one-way data flow. These are the shared DNA. The differences below are all in the "how."
| Framework | How updates work | Write style | Form binding | Size / scope |
|---|---|---|---|---|
| React | Virtual DOM diff | JSX — JS-first | Manual | Library |
| Vue | Reactive proxies | HTML templates | v-model (auto) | Progressive |
| Angular | Zone.js → Signals | HTML templates | ngModel (auto) | Full framework |
| Svelte | Compiled away | HTML templates | bind: (auto) | Library |
| Solid.js | Fine-grained signals | JSX — JS-first | Manual | Library |
If you're starting out, React is the safest choice for job market demand and community size. Vue is the most approachable if you already know HTML. Svelte is the most enjoyable to write once you get used to it. Angular is worth learning if you're joining a large team or enterprise environment. Solid is worth watching — it may well be where things are heading.
The good news: once you genuinely understand one, you understand the core of all of them. The mental model transfers. The syntax is just syntax.
The one thing to remember: all of these frameworks are trying to solve the same problem — keeping your UI in sync with your data, without you having to do it by hand. They just found different routes to the same destination.