Choosing a Frontend Framework

The question everyone asks, and the answer nobody wants to hear: it depends.

I have led framework decisions at agencies, automotive companies, and now a design platform serving millions of users. Over twenty-five years in this industry, I have inherited codebases built on jQuery, migrated teams to React, and watched frameworks rise and fall. The one constant throughout all of this is that teams agonize over React versus Vue versus Svelte, but the reality is that most frameworks can build most things reasonably well.

The differences matter at the margins. Developer experience, hiring, ecosystem depth, performance characteristics, and how well the framework’s mental model fits your problem. These are the factors that separate a good choice from a painful one, not some abstract notion of which framework is “best.”

I am not going to tell you which framework to use. Instead, I will share the criteria I use when making these decisions, the tradeoffs I have learned to weigh over the years, and the questions I wish I had asked earlier in my career.

The Criteria That Actually Matter

Rendering Model

I think about the rendering model first because it constrains everything else you will 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, popularised 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 fundamentally different approach to tracking and updating state.

What you’re building determines which model fits best. Content-heavy sites benefit enormously 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 optimised 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 takes a compile-time approach where reactivity is analysed and optimised during the build step rather than at runtime. Solid, Vue 3, and Angular’s newer APIs 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 optimise performance, and how much you find yourself fighting the framework versus working with it. I have seen teams waste months optimising React re-renders that Svelte or Solid would have avoided entirely because those frameworks track dependencies at a more granular level. I have also seen teams struggle with Svelte’s compile-time magic because they expected runtime behaviour and were surprised when things didn’t work as they assumed.

There’s no objectively correct reactivity model. But there are models that fit certain problems better than others, and understanding the tradeoffs will save you considerable pain down the road.

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’s ecosystem is unmatched in breadth. 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 will find gaps, particularly for specialised use cases. Smaller frameworks like Solid may require you to build more infrastructure yourself or adapt libraries designed for other frameworks.

I have learned to audit the ecosystem before committing to a framework. I make a list of the libraries and tools we will definitely need, check that they exist and are actively maintained, and look for warning signs like abandoned repositories or unresolved issues piling up. The framework is only as good as the tools around it, and discovering a critical gap six months into a project isn’t a pleasant experience.

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 will 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 genuinely 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 have seen technically superior framework choices fail because the team never developed fluency, and I have seen theoretically inferior choices succeed because the team knew every corner of the framework and could move quickly.

The best framework is useless if you can’t staff a team to build with it.

Long-term Viability

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

React has Meta behind it, which provides both resources and a certain degree of confidence that it won’t disappear overnight. Angular has Google. Vue is independently funded through sponsorships and Evan You’s consulting work, 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 have been burned by frameworks that seemed vibrant and died within two years. The JavaScript ecosystem moves quickly, and what looks like momentum can evaporate when maintainers lose interest or funding dries up. I look at commit history, release cadence, how breaking changes are communicated, and whether there’s a clear roadmap for the future.

This doesn’t mean you should only ever choose React because it’s safest. But it does mean you should factor viability into your decision and be honest about the risks you’re accepting.

When Each Framework Shines

Here 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, not because it’s objectively best, but because it’s the hardest choice to get fired for making. When something goes wrong with a React project, nobody questions the framework selection.

What you need to watch out for is the boilerplate, the performance footguns like unnecessary re-renders, and the decision fatigue that comes from having too many options for everything. Should you use Redux, Zustand, Jotai, Recoil, or just Context? Class components or function components? CSS Modules, styled-components, Emotion, or Tailwind? React gives you tremendous freedom, and some teams thrive with that freedom while others struggle to make consistent choices.

I have found that React works best when you establish strong conventions early and stick to them. Without guardrails, the flexibility becomes a liability.

Vue

Vue is best suited for teams who want conventions over configuration. Where React offers choices, Vue offers opinions. 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 have 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. The compiler approach means Svelte can strip away framework overhead that other libraries ship to the browser, resulting in smaller bundles and faster runtime performance.

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 simply write less code to accomplish the same things. SvelteKit provides a full-featured meta-framework comparable to Next or Nuxt.

What you need to watch out for is 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 behaviour, particularly around reactivity in edge cases. I wouldn’t hesitate to use Svelte for a new project with an experienced team, but I would think carefully about it for a large organisation 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 genuinely 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. But 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 have noticed that Angular teams tend to either love the structure or chafe against it. There isn’t much middle ground. 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 fundamentally different and often significantly 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 am 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. The islands architecture approach lets you ship minimal JavaScript while still having rich interactive components where you need them.

If you’re building a marketing site, documentation, or blog, these frameworks offer compelling performance characteristics out of the box. However, they’re less suited for highly interactive single-page applications where the entire interface is dynamic. Know what you’re building before reaching for these tools.

The Meta-Question: Standardise or Diversify?

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

The arguments for standardisation are compelling. When everyone uses the same framework, engineers can move between teams without learning new tools. Shared component libraries work everywhere. You maintain one set of tooling, testing patterns, and build pipelines. Hiring becomes simpler because you can focus your job postings and interview processes. Onboarding is faster because new engineers only need to learn one way of doing things.

The arguments for controlled diversity are also compelling. Different problems genuinely 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 organisation-wide risk, and you avoid being completely locked into a framework that might fall out of favour.

Most enterprises I have 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. The key is making that policy explicit and documenting the criteria for when exceptions are appropriate. Without clear guidelines, you end up with accidental diversity where every team makes independent choices and nobody can share code or move between projects.

What If You Choose Wrong?

You will, eventually. I have. Every senior engineer I know has made framework choices they later regretted.

Frameworks fall out of favour. Requirements change in ways you didn’t anticipate. Teams grow and what worked for five people doesn’t work for fifty. The question isn’t whether you will need to migrate at some point. The question is whether your architecture makes migration possible when that day arrives.

I have 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. Isolate framework-specific code from business logic. Use adapters and ports at system boundaries. Avoid framework lock-in in your data and state layers. Document your decisions so 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 actually building prevents you from optimising 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, optimise for speed. For long-lived projects, optimise 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 audit that the libraries and tools we will definitely need actually 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 have come to believe that the framework matters less than how you use it.

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

Choose deliberately based on your actual constraints rather than hype. Standardise thoughtfully with room for justified exceptions. Build migration into your architecture from day one so you aren’t trapped by today’s decisions.

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