Choosing a Frontend Framework

Everyone asks which framework to pick, and the honest answer is that it depends.

I’ve led framework decisions at agencies, automotive companies, and now a design platform serving millions of users. Over twenty-five years in this industry, I’ve inherited codebases built on jQuery, migrated teams to React, and watched frameworks rise and fall. Through all of it, teams have agonized over React versus Vue versus Svelte, when most frameworks can build most things reasonably well.

The differences show up at the margins: developer experience, hiring, ecosystem depth, performance characteristics, and how well the framework’s mental model fits your problem. Those factors separate a good choice from a painful one far more than any abstract idea of which framework is “best.”

I’m not going to tell you which framework to use. Instead, I’ll share the criteria I use when making these decisions, the tradeoffs I’ve learned to weigh over the years, and the questions I wish I’d asked earlier in my career.

The Criteria I Weigh

Rendering Model

I think about the rendering model first because it constrains everything else you’ll do. The major categories worth understanding are client-side rendering, server-side rendering, islands and partial hydration, and fine-grained reactivity through signals.

Client-side rendering, the approach taken by traditional React and Vue single-page applications, puts all the rendering work in the browser. Server-side rendering, which frameworks like Next, Nuxt, and SvelteKit handle natively, generates HTML on the server before sending it to the client. Islands architecture, popularized by Astro and Fresh, hydrates only the interactive portions of a page while leaving static content alone. And signal-based frameworks like Solid, the latest versions of Svelte, and Angular’s new reactivity system take a different approach to tracking and updating state.

What you’re building determines which model fits best. Content-heavy sites gain a lot from server-side rendering and islands architecture because most of the page doesn’t need JavaScript at all. Highly interactive applications benefit from client-side frameworks with strong state primitives because the entire interface is dynamic anyway. At Canva, we’re building a complex interactive editor where nearly everything on screen responds to user input, and that pushes us toward frameworks optimized for rich client-side state management.

The rendering model you choose will influence your performance characteristics, your hosting requirements, and how your team thinks about the boundary between server and client. It’s worth getting this right early.

Reactivity Model

This one took me years to fully appreciate, but I now consider it one of the most important factors in framework selection.

React uses a virtual DOM diffing approach where the framework compares a virtual representation of your UI against the previous version and calculates what needs to change. Svelte leans on its compiler: since Svelte 5, you mark reactive state with runes like $state and $derived, and the compiler turns them into signal-based code. Solid, Vue 3, and Angular’s signals API use fine-grained signals that track exactly which pieces of state each part of your UI depends on. And observable-based systems like MobX and RxJS provide yet another mental model for thinking about data flow.

The reactivity model shapes how you think about state, how you optimize performance, and how much you find yourself fighting the framework versus working with it. I’ve seen teams waste months optimizing React re-renders that Svelte or Solid would have avoided entirely because those frameworks track dependencies at a more granular level. I’ve also seen teams struggle with Svelte’s compile-time magic because they expected runtime behavior and were surprised when things didn’t work as they assumed.

No single reactivity model is right for every problem, but some fit certain problems better than others, and understanding the tradeoffs up front will save you a lot of pain later.

Ecosystem and Tooling

The framework itself is only part of the picture. You also need to consider the ecosystem that surrounds it: component libraries like MUI, Radix, Vuetify, and Skeleton; meta-frameworks like Next, Nuxt, SvelteKit, and Analog; testing tools like Testing Library, Playwright, and Cypress; and the maturity of developer tools for debugging and profiling.

React has the broadest ecosystem of the frameworks here. Whatever you need, someone has probably built it, and there are likely multiple competing options to choose from. Vue and Svelte are catching up, but you’ll find gaps, particularly for specialized use cases. Smaller frameworks like Solid may require you to build more infrastructure yourself or adapt libraries designed for other frameworks.

I’ve learned to audit the ecosystem before committing to a framework. I make a list of the libraries and tools we’ll definitely need, check that they exist and are actively maintained, and look for warning signs like abandoned repositories or unresolved issues piling up. A framework is only as useful as the tools around it, and finding a critical gap six months into a project is painful.

Hiring and Team Familiarity

I encourage you to be honest about your hiring constraints because they matter more than most technical factors.

React dominates job postings and candidate pools in most markets. If you post a React role, you’ll get applicants. Vue has strong presence in certain markets, particularly in Asia-Pacific and within the Laravel ecosystem where it has historically been the default frontend choice. Svelte and Solid attract enthusiastic developers, but the talent pools are significantly smaller, and finding senior engineers with production experience can be difficult.

Team familiarity matters just as much as hiring. A team that knows Vue deeply will ship faster and with fewer bugs than a team learning React from scratch, even if React might theoretically be a “better” choice for the problem at hand. I’ve seen technically superior framework choices fail because the team never developed fluency, and I’ve seen theoretically inferior choices succeed because the team knew every corner of the framework and could move quickly.

Long-term Viability

I pay attention to who’s funding development and how the framework handles breaking changes.

React has been governed by the React Foundation, hosted by the Linux Foundation, since early 2026, with Meta, Microsoft, Vercel, and other companies as members, which gives both resources and a certain degree of confidence that it won’t disappear overnight. Angular has Google. Vue is independently funded, mostly through sponsorships, which some see as a risk and others see as a feature because it keeps the framework free from corporate priorities. Smaller frameworks often depend on one or two core maintainers, which creates bus factor concerns.

I’ve been burned by frameworks that looked healthy and were abandoned within two years. The JavaScript ecosystem moves quickly, and a project that looks active can stall when maintainers lose interest or the funding stops. I look at commit history, release cadence, how breaking changes are communicated, and whether there’s a clear roadmap for the future.

None of this means you should only ever choose React because it’s safest, only that viability belongs in the decision and you should be honest about the risks you’re accepting.

Strengths of Each Framework

This is how I think about the major options, based on my experience using them in production.

React

React is best suited for large teams working on complex applications who need maximum ecosystem choice and hiring flexibility. It’s the safe choice in the sense that it’s the hardest one to get fired for making. When something goes wrong with a React project, nobody questions the framework selection.

The downsides are the boilerplate, the easy performance mistakes like unnecessary re-renders, and the decision fatigue that comes from having too many options for everything. The React Compiler, stable since October 2025, now handles a lot of the memoization people used to write by hand, but the choices remain. Should you use Redux, Zustand, Jotai, or just Context? A framework like Next or React Router, or a plain client-side app? CSS Modules, styled-components, Emotion, or Tailwind? React gives you a lot of freedom, and some teams thrive with it while others struggle to make consistent choices.

I’ve found that React works best when you establish strong conventions early and stick to them, because otherwise each part of the codebase ends up making its own choices.

Vue

Vue is best suited for teams who want conventions over configuration, because it makes many of the choices React leaves to you. There’s an official router, an official state management solution, and an official way to do most things. This reduces decision fatigue and makes it easier to onboard new team members because everyone is working the same way.

I’ve seen Vue work particularly well for teams coming from backend development. The mental model seems to click faster for developers who are used to templates and clear separation between logic and presentation. The single-file component format keeps everything related to a component in one place, which some developers find more intuitive than React’s approach.

The Vue ecosystem is smaller than React’s, and you may find yourself evaluating fewer options for any given need. Whether that’s a positive or negative depends on your perspective.

Svelte and SvelteKit

Svelte is best suited for performance-sensitive applications where bundle size matters and developers want to write less boilerplate code. Because Svelte is a compiler, it can leave out framework code that other libraries ship to the browser, which gives smaller bundles and faster runtime performance.

In my experience, developers who have used Svelte rarely want to go back to React’s verbosity. The syntax is cleaner, the reactivity is more intuitive, and you write less code to do the same things. SvelteKit provides a full-featured meta-framework comparable to Next or Nuxt.

The downsides are the smaller ecosystem and the difficulty of finding senior developers with production Svelte experience. The compile-time approach can also surprise developers who expect runtime behavior, particularly around reactivity in edge cases. I wouldn’t hesitate to use Svelte for a new project with an experienced team, but I’d think carefully about it for a large organization that needs to hire aggressively.

Angular

Angular is best suited for large enterprise teams who want strong conventions, TypeScript-first development, and a full framework with opinions about everything. Where React is a library and Vue is a progressive framework, Angular is a complete framework with built-in solutions for routing, forms, HTTP, and more.

The learning curve is steeper than other options, and the bundle sizes tend to be larger, though standalone components (the default since Angular 17) and signals have removed a lot of the old NgModule ceremony. Teams who embrace Angular’s structure often find it scales well to large codebases with many contributors. The strong typing and architectural patterns help maintain consistency across a big codebase.

I’ve noticed that Angular teams tend to either love the structure or chafe against it, with few in between. If your team values freedom and flexibility, Angular will feel constraining. If your team values consistency and guardrails, Angular will feel reassuring.

Solid

Solid is best suited for React developers who want fine-grained reactivity without virtual DOM overhead. The API is intentionally similar to React, making the transition relatively smooth, but the underlying performance model is different and often faster.

The ecosystem is small, the hiring pool is limited, and the framework is still maturing. But the technical approach is compelling, and I wouldn’t be surprised to see Solid’s ideas influence the broader ecosystem over the coming years. I’m watching it closely and would consider it for the right project with the right team.

Astro, Qwik, and Fresh

These frameworks are best suited for content-first sites where most of the page doesn’t need to be interactive. Astro and Fresh use islands architecture, which lets you ship minimal JavaScript while still having rich interactive components where you need them. Qwik takes a different route called resumability: the server serializes the app’s state into the HTML, and the browser downloads the code for an event handler only when someone triggers it, so there’s no hydration step at all.

If you’re building a marketing site, documentation, or blog, these frameworks give you good performance out of the box. They’re less suited to highly interactive single-page applications where the entire interface is dynamic.

Standardize or Diversify

At a certain scale, the framework question becomes an organizational question. I’ve seen this play out at every company I’ve worked at, and the debates can become surprisingly heated.

Standardization has real advantages. When everyone uses the same framework, engineers can move between teams without learning new tools, and shared component libraries work everywhere. You maintain one set of tooling, testing patterns, and build pipelines. Hiring is simpler because job postings and interviews can focus on one framework, and onboarding is faster because new engineers only need to learn one way of doing things.

Controlled diversity has real advantages too. Different problems suit different tools, and forcing everything into one framework can mean fighting the framework for certain use cases. Microfrontend architectures enable framework isolation, so different teams can make different choices without affecting each other. Experimentation becomes possible without organization-wide risk, and you avoid being completely locked into a framework that might fall out of favor.

Most enterprises I’ve worked with land somewhere in the middle. They establish a primary framework that handles eighty or ninety percent of use cases, with an explicit process for requesting exceptions. This works when the policy is explicit and the criteria for exceptions are written down. Without clear guidelines, you end up with accidental diversity where every team makes independent choices and nobody can share code or move between projects.

Choosing Wrong

You’ll choose wrong at some point, and so have I. Every senior engineer I know has made framework choices they later regretted.

Frameworks fall out of favor, requirements change in ways you didn’t anticipate, and teams grow until what worked for five people doesn’t work for fifty. You’ll probably need to migrate at some point, so it helps to have an architecture that makes migration possible when you do.

I’ve led migrations that took months and migrations that took years. The difference was always how well the original team isolated framework-specific code from business logic. When your data fetching, state management, and business rules are tangled up with your UI components, migration means rewriting everything. When those concerns are separated, migration means swapping out the view layer while keeping everything else.

The patterns that protect you are straightforward in principle even if they require discipline in practice. Framework-specific code stays separate from business logic, adapters and ports sit at system boundaries, and the data and state layers don’t depend on the framework. Written-down decisions let future teams understand the context and constraints you were working within.

If you can’t articulate how you would migrate away from your current framework, you’re probably more coupled than you think. That isn’t necessarily a crisis, but it’s worth being honest about.

Decision Checklist

Before committing to a framework, I work through a series of questions with my team.

What are we building? A content site, an interactive application, a real-time collaboration tool? Different answers suggest different frameworks, and being honest about what you’re building keeps you from optimizing for the wrong things.

Who’s building it? Team familiarity matters more than the theoretical “best” choice. A team that knows their framework deeply will outperform a team learning something new, at least in the short term.

What’s our hiring market? I check local job boards rather than relying on global social media sentiment. What’s popular in San Francisco may not reflect your hiring reality in London or Sydney or Singapore.

How long will this live? A six-month prototype has different constraints than a ten-year platform. For short-lived projects, optimize for speed. For long-lived projects, optimize for maintainability and migration paths.

Can we migrate later? If the honest answer is no, that’s a sign you’re over-coupled to your framework. Consider whether that level of lock-in is acceptable given the project’s expected lifespan.

What does our ecosystem need? Before committing, I check that the libraries and tools we’ll definitely need exist, are actively maintained, and work well together.

Conclusion

After twenty-five years in the industry and nearly two decades as a frontend architect, I’ve come to believe that the framework matters less than how you use it.

Clean architecture, clear boundaries, and disciplined patterns will get you further than picking the “right” framework. I’ve seen teams succeed with React, Vue, Svelte, Angular, and everything else on the market. I’ve also seen teams fail with every single one of those options. The framework was rarely the determining factor.

A deliberate choice based on your real constraints lasts longer than one based on hype. Standardizing works best with room for justified exceptions, and building migration into your architecture from day one means today’s decisions don’t trap you later.

The best framework is the one your team can ship with.