Frontend / Guide
Pick a frontend framework in six questions
Every framework here renders a normal product fast enough. What separates them is where the HTML gets made, how much JavaScript rides along, who you can hire, and what it costs to leave. Ask six questions in order and the choice mostly makes itself.
About 9 min read. Versions verified September 2026.
The verdict
If it is content, pick Astro 7 and add islands only where a page genuinely needs JavaScript. If it is an application, pick React 19 with Next.js 16, because hiring, SDK support and component libraries all favor it by a wide margin. If the team is small and senior and would rather own less code than have more options, pick Svelte 5 with SvelteKit 2.
Start with what you are building
The project type answers most of the six questions before you ask them. Find your row, then read on to check whether you are the exception.
| Project | Pick | Why |
|---|---|---|
| Marketing site, blog or docs | Astro 7 | Zero JavaScript by default, Markdown content collections, and any React, Vue, Svelte or Solid component as an island where needed. |
| SaaS dashboard or multi-step app | React 19 + Next.js 16 | Server Components, Server Actions and Cache Components handle data without a separate API; every auth and billing vendor ships a Next.js adapter first. |
| Internal tool | React 19 + Vite 8 + TanStack Router | Nobody indexes a page behind a login, so a plain SPA with type-safe routes is right, and the build is static files. |
| App on an existing Rails, Django, Laravel or Go backend that renders HTML | htmx (or Inertia 3) | Keep the templates and the one language you have. htmx swaps server-rendered fragments; Inertia adds React, Vue or Svelte pages without building an API. |
| Design-heavy interactive site | Svelte 5 + SvelteKit 2 | Built-in transitions, compiled output with no framework runtime, and components that read like the HTML a designer handed you. |
| Large enterprise with strict conventions and long tenure | Angular 22 | One way to do everything, a CLI that enforces it, and long-term support lines a procurement team can point at. |
| Realtime or high-frequency UI | React 19 or Solid 1.9 | React with the Compiler handles most live boards. Solid's signals win when thousands of cells update independently and re-rendering is the bottleneck. |
| Mobile | Expo (React Native) | One team and one language for iOS, Android and the web, with shared validation and API clients. A reason on its own to pick React for the web. |
Gotcha: the table assumes no strong prior. A team that ships Vue every day should read every React row as Vue 3.5 with Nuxt 4 and lose almost nothing. Fluency beats a marginally better framework on any project shorter than a decade.
The six questions
In this order. The first two eliminate most of the field, the middle two decide between the survivors, and the last two are the ones teams skip and regret.
- Rendering model. Decide where the HTML is produced before deciding what produces it. Indexed content read on slow connections wants static output or islands; an app behind a login can render in the browser. The rendering models guide settles this in one table and rules Astro in or out immediately.
- Interactivity budget. Count the pages, not the components. If fewer than a fifth of your routes need JavaScript to be useful, a framework on every page is a self-inflicted cost and islands are the answer. If most screens are stateful, you are building an application and need one of the five component frameworks.
- Team and hiring. Whoever maintains the code in three years is the real user of this decision. If you will hire, contract or hand the codebase over, React's pool is several times larger than any other and AI assistants generate it best. If the same five people will still be here, Svelte or Vue can win.
- Ecosystem depth. List what you will not build yourself - a date picker, a data grid, an auth SDK, a rich text editor - and check that each ships a first-party binding for your leading candidate. The component library guide and the state and data guide map what exists per framework.
- Exit cost. Estimate how much of the codebase is framework-shaped. Markdown and plain components lift out of Astro in a week; App Router conventions, Server Components and the caching model do not port out of Next.js at all. High exit cost is fine for a product's core and a trap for a brochure site.
- Performance budget and target devices. Set a JavaScript budget per page and name the worst device that must hit it. A runtime that costs nothing on a developer laptop costs real seconds on a mid-range Android phone. If that phone is your median user, compiled frameworks and islands are how you meet the budget.
Five component frameworks, one table
Versions are what npm install gives you today. Bundle sizes are qualitative on purpose: the libraries you add outweigh any framework baseline, so measure your own build.
| Dimension | React 19 | Vue 3.5 | Svelte 5 | Solid 1.9 | Angular 22 |
|---|---|---|---|---|---|
| Reactivity model | Virtual DOM; the component re-runs and React Compiler 1.0 inserts the memoization you used to hand-write. | Proxy reactivity over a virtual DOM. Vapor Mode, which drops the virtual DOM per component, is in the 3.6 release candidate. | Runes are signals. The compiler emits direct DOM updates, so a change touches only the nodes bound to it. | Fine-grained signals, no virtual DOM, and the component runs once. 2.0 is in release candidate with first-class async. | Signals are the primitive and zoneless change detection is stable; new projects skip Zone.js. |
| Default rendering path | SPA on Vite, or Server Components with streaming on Next.js. | SPA on Vite, or server-rendered with hybrid route rules on Nuxt 4. | Server-rendered by default in SvelteKit, prerendered per route on request. | SPA on Vite; SolidStart adds streaming server rendering. | SPA from the CLI; Angular SSR with incremental hydration is the opt-in. |
| Baseline bundle | Mid. React plus ReactDOM is a fixed runtime on every page. | Mid. Smaller than React's runtime; Vapor Mode will shrink it further. | Smallest. No runtime; output scales with the components you wrote. | Small. A tiny runtime plus compiled templates. | Largest, even after the CLI tree-shakes it. |
| TypeScript story | Excellent. JSX is typed end to end and every library ships types. | Good with <script setup>; template checking depends on editor tooling. | Good. Runes fixed the inference gaps stores had in Svelte 4. | Excellent. TypeScript-first with typed JSX. | Mandatory and the strongest here; templates are compiler-checked. |
| Canonical meta-framework | Next.js 16 | Nuxt 4 | SvelteKit 2 | SolidStart | Angular CLI + SSR |
| Component-library depth | Deepest by far: shadcn/ui on Radix and Base UI, MUI, Mantine, Chakra, Ant Design, and a React binding for every commercial SDK. | Strong: PrimeVue, Vuetify, Nuxt UI, Element Plus, shadcn-vue on Reka UI. | Adequate: Bits UI, Melt UI, shadcn-svelte, Skeleton. A missing SDK binding means writing it. | Thin: Kobalte and Ark UI cover primitives; most integrations are community ports. | Deep in the enterprise lane: Angular Material, PrimeNG, Spartan. |
| Hiring pool | Largest by a wide margin, in every region. | Second; strongest in Asia and continental Europe, thinner in North America. | Small and growing; strongest in European startups. | Smallest of the five. Expect to train React developers into it. | Large in enterprise, banks and government; rare in startups. |
| Learning curve | Hooks rules, effect timing and the server-client split are real load. | Gentlest of the five; an official router and store mean fewer day-one decisions. | Closest to plain HTML, CSS and JavaScript. Juniors ramp fastest here. | Looks like React, behaves differently. Destructuring props breaks reactivity and catches newcomers. | Steepest. Dependency injection, RxJS and decorators land at once. |
| Pick it when | Hiring, SDK support, or a mobile app on the roadmap decides it. | The team already knows it, or you want official batteries without React's ceremony. | The team is small and senior and bundle size or code volume is a real constraint. | Raw interface performance is the product and a thin ecosystem is acceptable. | The organization values conventions over flexibility and measures tenure in years. |
Gotcha: Vue 3.6 and Solid 2.0 are release candidates, so tutorials will increasingly describe APIs a fresh install does not have. Pin the stable line.
Also on the radar
Six tools that answer a narrower question than "which framework". Each wins one row of the project table and loses the rest.
Preact
10.29 - React's API at a fraction of the size
The same component model and hooks in a much smaller runtime, with a compat layer that runs most React libraries unchanged. The swap for an embeddable widget or a React app under a hard bundle budget. preactjs.com
Lit
3.3 - web components without the boilerplate
A thin layer over custom elements with reactive properties and declarative templates. Pick it when the output must work inside any host page - a design system shared by React, Angular and plain HTML teams - not for an application. lit.dev
Qwik
1.20 - resumability instead of hydration
Serializes application state into the HTML so the browser resumes where the server stopped instead of re-running the app; handlers download on first interaction. Clever, still a small ecosystem: for content-heavy sites with heavy interactivity and a team willing to be early. qwik.dev
Alpine.js
3.17 - behavior in HTML attributes
Dropdowns, tabs, modals and toggles declared inline on server-rendered markup with no build step. The natural partner to htmx or a Rails, Laravel or Django template when interactivity is small and local. Stop when you are managing shared state across it. alpinejs.dev
htmx
4.0 shipped - 2.0 is still the npm default
HTML attributes that fetch server-rendered fragments and swap them into the page. Version 4.0 shipped in August 2026 on fetch() with built-in morphing; the npm latest tag stays on 2.x so unversioned CDN users are not upgraded by surprise. Deletes a build pipeline when the backend already renders HTML. htmx.org
Astro islands
7.x - the content-site default
Not a component framework but the thing that lets you skip one. Astro 7 ships static HTML from a Rust compiler on Vite 8, and each island hydrates independently with a directive that says when: on load, when idle, or when visible. Where a React, Vue, Svelte or Solid component goes when the page needs no framework. astro.build
How a framework decision goes wrong
Most failures are a good input applied at the wrong step of the six questions.
| Symptom | Cause and fix |
|---|---|
| The decision doc leads with a benchmark chart | Benchmarks measure a synthetic list on a fast machine. Every framework here renders a real product fast enough; what differs is the baseline on your worst device and the libraries you add. A benchmark is a tiebreaker, never the deciding input. |
| Picked the framework on every conference stage this year | Hype-cycle adoption. Attention is not ecosystem depth or hiring supply. Check the component-library and hiring rows above, then whether your vendors ship a binding. If they do not, it is a research project, not a platform. |
| A working app is being rewritten to the new pick | Rewrites replace known bugs with unknown ones and ship nothing for months. Rewrite only when the old framework is unmaintained or blocks a requirement you can name; otherwise adopt the new one for the next surface. |
| Chose Next.js, then discovered where it has to run | The meta-framework was picked before the host. Server rendering, Cache Components and edge middleware behave differently on Vercel, Cloudflare, a container and a static bucket. Decide the host first with the hosting directory, then pick the meta-framework with a first-party adapter there. |
| Leaving would mean rewriting everything | Exit cost was never estimated. Keep business logic, validation and data access in plain TypeScript modules the framework imports, not in hooks, loaders and actions. The framework owns the view layer, nothing below it. |
| Job posts ask for five years of one framework | Hiring for the framework instead of the product. Strong developers move between React, Vue and Svelte in weeks; what they cannot pick up in weeks is your domain. Hire for the platform and treat the framework as onboarding. |
Our pick
Astro for content, React with Next.js for apps, Svelte for small senior teams
Start with Astro 7 unless the six questions prove you are building an application. Most sites that reach for a component framework are content with a few interactive corners, and islands cover those at a fraction of the weight while still running the React component you already own.
When it is an application - dashboards, editors, multi-step state, a mobile app on the roadmap - go React 19 with Next.js 16. Not the most elegant option; the one where every hiring problem, vendor SDK and answer already exists. Choose Svelte 5 with SvelteKit 2 when the team is small, senior and staying, and would rather maintain less code.
Keep going
The framework roundup has the per-framework cards. For the two closest calls, React vs Svelte and Next.js vs Astro each lead with a verdict.
Question one has its own page in rendering models, and question four continues in the component library guide. Once the framework is settled, the SaaS stack and the static site stack pick the layers around it, and the launch checklist runs before the first deploy.