Part 032 — Framework Decision-Making: React, Vue, Svelte, Native Web

A top-tier frontend engineer does not ask, "Which framework is best?"

That question is poorly framed.

The better question is:

Given this product, team, runtime, organization, delivery model, and maintenance horizon, which UI architecture creates the best risk-adjusted outcome?

React, Vue, Svelte, and native web platform approaches each optimize different constraints. They also create different failure modes.

This part gives you a decision model, not a popularity ranking.

1. Kaufman Skill Deconstruction

Framework decision-making is a compound skill.

Kaufman target performance

After this part, you should be able to write a decision record like this:

We choose Vue for this internal workflow platform because the team needs strong conventions, template readability, incremental adoption, and lower variance in component style.
We reject React for this project not because React is weak, but because the current team has no RSC/SSR expertise and the product does not need React's broader ecosystem.
We reject Svelte because the organization requires a larger hiring pool and long-lived design system compatibility across multiple teams.
We will revisit in 18 months if the product becomes more performance-sensitive or the platform team matures.

That is an engineering decision. "React is more popular" is not.

2. The Decision Frame

Framework choice affects many layers:

A framework is not a local implementation detail if it shapes:

• routing;
• server/client boundaries;
• state model;
• component contracts;
• testing strategy;
• build pipeline;
• accessibility patterns;
• design-system API;
• team onboarding;
• hiring;
• observability;
• deployment architecture.

2.1 Decision dimensions

2.2 Product archetypes

3. React: Runtime Flexibility and Ecosystem Gravity

React is a library for building user interfaces from components. Its power comes from a small component model combined with enormous ecosystem gravity.

React's core mental model:

UI = function of state
components describe desired UI
React reconciles changes and commits updates
side effects are explicit through framework lifecycle primitives

Modern React is not just "components and hooks". In production architecture, React is also:

• a rendering runtime;
• a scheduling model;
• a server/client boundary model when used with React Server Components;
• a large ecosystem contract;
• a design-system platform target;
• a hiring market;
• a migration ecosystem.

3.1 React strengths

3.2 React costs

3.3 React is a strong fit when

- You need a large ecosystem and hiring pool.
- Multiple teams will build on shared component abstractions.
- You need mature design-system support.
- Product complexity is high and long-lived.
- You can enforce conventions through platform/lint/review.
- You need Next.js/Remix-style production architecture.
- You may benefit from React Native or shared mental models.

3.4 React is a risky fit when

- The team lacks discipline around effects, state ownership, and boundaries.
- The product is mostly static but ships a large client runtime anyway.
- The organization cannot standardize data/routing/form patterns.
- The team expects React alone to provide architecture.
- RSC/SSR is adopted without understanding cache/security/runtime consequences.

3.5 React decision note

React is often the safest organizational choice, not always the simplest technical choice.

The senior move is to pair React with a strict architecture:

• route/data conventions;
• state ownership rules;
• effect usage rules;
• component API standards;
• bundle budgets;
• testing strategy;
• framework boundary documentation;
• RSC/server-client policy if applicable.

Without governance, React codebases often become a collection of local opinions.

4. Vue: Integrated Conventions and Progressive Adoption

Vue is a progressive framework centered on declarative rendering, component composition, and a built-in reactivity system. It can be adopted incrementally, but it also supports full application architecture through its ecosystem.

Vue's core mental model:

Templates declare UI
reactive state drives updates
Composition API organizes logic
Single-File Components group template, script, and style

Vue often feels more integrated than React because many choices are more standardized:

• templates;
• Single-File Components;
• Composition API;
• built-in reactivity primitives;
• Vue Router;
• Pinia;
• official style conventions;
• SFC compiler tooling.

4.1 Vue strengths

4.2 Vue costs

4.3 Vue is a strong fit when

- The team benefits from stronger conventions.
- You want approachable component structure without giving up advanced composition.
- Internal tools, dashboards, and workflow apps need consistency.
- Incremental adoption is valuable.
- You want a cohesive official ecosystem.
- The team prefers template-first UI over JSX-heavy abstraction.

4.4 Vue is a risky fit when

- Your organization has deep React platform investment.
- You need React-specific ecosystem libraries or hiring scale.
- You require highly custom render abstraction where JSX is materially simpler.
- The team treats reactivity as magic and cannot debug dependency tracking.

4.5 Vue decision note

Vue is often excellent for teams that want balance:

more integrated than React
less radical than Svelte
more framework-shaped than native web

The senior risk is not Vue itself. The risk is assuming conventions eliminate architecture. You still need boundaries for data, state, forms, routing, caching, accessibility, and testing.

5. Svelte: Compiler-First UI and Explicit Reactivity

Svelte is different because much of the framework work happens at compile time. Instead of shipping a large general-purpose runtime abstraction, Svelte compiles components into efficient JavaScript updates.

Svelte's modern mental model:

Write component logic
mark reactive values explicitly
compiler analyzes and generates update code
runtime coordination is smaller than virtual-DOM-heavy approaches

Svelte 5 introduced runes as explicit reactivity primitives. That makes reactivity more portable and visible than older implicit $: patterns.

5.1 Svelte strengths

5.2 Svelte costs

5.3 Svelte is a strong fit when

- You need high performance with low runtime overhead.
- The app is greenfield or has limited integration constraints.
- The team is small-to-medium and can align on conventions.
- You value compiler-driven UI and concise component code.
- Bundle size and startup cost are primary constraints.
- You can accept a smaller ecosystem in exchange for simplicity/performance.

5.4 Svelte is a risky fit when

- You need a very large hiring pool immediately.
- Your organization already has deep React/Vue design-system investment.
- You require many niche enterprise integrations.
- You cannot tolerate framework migration churn.
- You need cross-team governance patterns that are already proven internally.

5.5 Svelte decision note

Svelte can be a powerful choice when product constraints reward low runtime cost and the team can own framework expertise.

Do not choose Svelte only because examples look simpler.

Choose it when its compiler-first architecture maps to your product's actual constraints.

6. Native Web / Platform-First Architecture

Native web means building primarily with browser platform APIs:

• HTML;
• CSS;
• DOM;
• Web Components;
• Custom Elements;
• Shadow DOM;
• standard events;
• progressive enhancement;
• server-rendered HTML;
• small JavaScript modules.

This is not anti-framework ideology.

It is a legitimate architecture option when the platform is enough.

6.1 Platform-first strengths

6.2 Platform-first costs

6.3 Native web is a strong fit when

- The app is mostly content, forms, or server-rendered workflows.
- You need embedded widgets across unknown host applications.
- JavaScript budget is extremely strict.
- Longevity and interoperability matter more than rich client abstraction.
- You can rely on progressive enhancement.
- The team has strong platform knowledge.

6.4 Native web is a risky fit when

- The app has complex client-side state and interactions.
- The team lacks DOM/event/accessibility expertise.
- You need rapid delivery of many standard app patterns.
- You will accidentally build a worse private framework.
- Governance is weak and every team invents its own primitives.

6.5 Web Components as design-system boundary

Web Components are most compelling as interoperability boundaries, not necessarily as a full app framework.

Good use cases:

• cross-framework design-system primitives;
• embedded widgets;
• microfrontend host boundaries;
• design tokens and themed components;
• progressive enhancement islands.

Hard parts:

• form participation;
• accessibility semantics;
• SSR/hydration story;
• styling/theming across Shadow DOM;
• event and property conventions;
• testing across framework wrappers.

7. Comparison by Architecture Dimension

7.1 Rendering and hydration

7.2 State and reactivity

7.3 Ecosystem and scale

7.4 Performance default vs performance ceiling

Do not confuse default performance with achievable performance.

Default performance = what average teams get without much discipline
Performance ceiling = what expert teams can achieve with deliberate architecture

Performance is not a framework property alone. It is an architecture property.

8. Decision Matrix

Use a weighted score only after constraints are clear.

Example criteria:

Do not copy these scores. Replace them with project-specific evidence.

8.1 Scoring anti-patterns

Avoid:

React = 10 because popular
Vue = 8 because nice docs
Svelte = 9 because fast
Native = 6 because no framework

Prefer:

React ecosystem score is high because we need mature rich-table, chart, form, auth, and observability integrations in the next two quarters.
Svelte runtime score is high because the product is an embedded widget with strict 50KB initial JS budget.
Vue team-fit score is high because three teams already ship Vue SFCs and have established lint/test conventions.
Native web migration score is high because the app is currently server-rendered and only needs progressive enhancement.

9. Framework Choice by Scenario

9.1 New enterprise workflow platform

Typical constraints:

• complex forms;
• permission-dependent screens;
• auditability;
• data grids;
• state machines;
• long maintenance horizon;
• many engineers;
• design-system needs;
• test automation;
• observability.

Likely good choices:

• React if ecosystem, hiring, and platform team are priorities.
• Vue if team benefits from stronger conventions and cohesive official patterns.

Risky choices:

• Svelte if hiring/governance/ecosystem risk is not acceptable.
• Native-only if the client-side workflow complexity is high.

9.2 High-performance marketing site

Typical constraints:

• LCP;
• SEO;
• mostly static content;
• low JS;
• CMS integration;
• occasional interactive islands.

Likely good choices:

• Astro/platform-first/islands.
• Svelte or Vue with strict static generation.
• React only if paired with strict JS budget and framework discipline.

Risky choice:

• SPA-first architecture.

9.3 Embedded customer widget

Typical constraints:

• unknown host app;
• small bundle;
• style isolation;
• no global conflicts;
• easy integration;
• versioned script delivery.

Likely good choices:

• Web Components.
• Svelte compiled widget.
• Preact or small runtime.

Risky choices:

• Heavy React app unless host already uses React or isolation strategy is strong.

9.4 Complex SaaS dashboard

Typical constraints:

• data fetching;
• cache invalidation;
• filters in URL;
• charts;
• tables;
• role-based UI;
• critical workflows;
• performance over time.

Likely good choices:

• React with a disciplined data/router stack.
• Vue with Pinia/router/query stack.

Svelte can work well but requires deliberate ecosystem validation.

9.5 Cross-framework design system

Typical constraints:

• multiple consuming frameworks;
• accessibility;
• theming;
• versioning;
• stable component contracts.

Likely choices:

• Web Components for primitive interoperability.
• Framework-specific wrappers for ergonomics.
• Separate design tokens from component implementation.

Risk:

• Trying to make one component model feel native in every framework without wrappers.

10. Migration and Coexistence Strategy

Framework decisions are often not greenfield. Existing code exists.

10.1 Migration options

The default senior recommendation is strangler or island migration, not rewrite.

10.2 Migration invariants

- Users must not experience workflow regression.
- Authentication/session must remain coherent.
- Routing must support old and new surfaces.
- Design system must bridge visual consistency.
- Observability must distinguish old/new stack errors.
- Test coverage must protect migration boundaries.
- Rollback must be possible per route or feature.

10.3 Coexistence boundary

Share stable platform packages, not internal UI state.

11. Governance After Choosing

The framework choice is the beginning, not the end.

A strong decision includes governance.

11.1 React governance example

- Use framework router conventions; no ad hoc global routers.
- Server/client component boundaries documented per route.
- Effects require clear external synchronization reason.
- No data fetching directly inside random leaf components unless using approved query layer.
- Component props use discriminated unions for variant complexity.
- Bundle budget enforced per route.
- State ownership documented for shared workflows.

11.2 Vue governance example

- Use Composition API and <script setup> for new components.
- Reactive state belongs in composables or stores according to ownership rules.
- Watchers require explicit cleanup and reason.
- Pinia stores model domain state, not arbitrary component convenience.
- SFC style conventions define scoped/global/token usage.
- Route-level data fetching and error handling standardized.

11.3 Svelte governance example

- Use Svelte 5 runes consistently for new code.
- Effects are for synchronization, not derived state.
- Stores/runes usage policy documented.
- Component events and bindable props follow design-system conventions.
- SvelteKit load/error boundaries standardized.
- Generated output and bundle cost monitored.

11.4 Native web governance example

- Custom Elements naming and versioning policy.
- Shadow DOM usage policy.
- Event naming and payload contracts.
- Form participation rules.
- Accessibility testing required for every component.
- Progressive enhancement baseline documented.
- No private mini-framework without architecture review.

12. Anti-Patterns

12.1 Framework as identity

"We are a React shop."

This can be useful for staffing and platform consistency.

It becomes harmful when it prevents product-appropriate architecture.

Better:

"React is our default application framework because it matches our platform, hiring, design-system, and ecosystem constraints. Exceptions require an ADR."

12.2 Benchmark-driven selection

Benchmarks are useful signals. They are not product architecture decisions.

A framework that wins a micro-benchmark can still fail your product because of:

• missing ecosystem;
• weak hiring pool;
• poor team fit;
• integration complexity;
• insufficient testing support;
• migration risk;
• governance failure.

12.3 Rewrite fantasy

A rewrite is attractive because it imagines a clean world.

Real rewrites inherit:

• unclear requirements;
• hidden behavior;
• undocumented edge cases;
• customer-specific workflows;
• old bugs users rely on;
• integration contracts;
• data assumptions;
• organizational pressure.

Choose incremental migration unless there is a compelling reason not to.

12.4 Framework without architecture

Frameworks solve rendering and component abstraction.

They do not automatically solve:

• domain modeling;
• cache invalidation;
• authorization;
• auditability;
• observability;
• accessibility governance;
• test strategy;
• release discipline;
• team ownership.

13. Architecture Decision Record Template

Use this ADR when choosing a frontend framework.

# ADR: Frontend Framework Choice for <Product>

## Status
Accepted / Proposed / Superseded

## Context
- Product type:
- User journeys:
- Interaction density:
- Rendering requirements:
- Performance budget:
- Accessibility/security/regulatory constraints:
- Team skill:
- Existing platform investment:
- Maintenance horizon:

## Options Considered
- React
- Vue
- Svelte
- Native Web / Web Components
- Other:

## Decision
We choose <option>.

## Rationale
- Constraint 1:
- Constraint 2:
- Constraint 3:

## Trade-offs Accepted
- Cost 1:
- Cost 2:
- Cost 3:

## Rejected Options
### React
Rejected because...

### Vue
Rejected because...

### Svelte
Rejected because...

### Native Web
Rejected because...

## Governance
- Routing:
- State:
- Data fetching:
- Forms:
- Styling/design system:
- Testing:
- Accessibility:
- Performance:

## Migration Plan
- Phase 1:
- Phase 2:
- Phase 3:

## Revisit Trigger
- Team size exceeds...
- Bundle budget fails...
- Product becomes...
- Framework support changes...

14. Decision Heuristics

14.1 Choose React when

You need maximum ecosystem depth, hiring availability, long-lived platform investment, design-system maturity, and are willing to enforce architecture strictly.

14.2 Choose Vue when

You want a cohesive framework with strong conventions, approachable component structure, good TypeScript support, and balanced complexity for product teams.

14.3 Choose Svelte when

You value compiler-first UI, low runtime overhead, concise component code, and can own a smaller but capable ecosystem.

14.4 Choose native web/platform-first when

The platform is enough, JavaScript budget is strict, progressive enhancement matters, or interoperability across unknown hosts is the central constraint.

14.5 Choose no new framework when

The existing stack is adequate and the real problem is architecture, state modeling, build tooling, testing, or governance.

This last heuristic is important. Many framework migrations are attempts to escape codebase problems that will reappear in the next framework.

15. Practice Loop

Exercise 1 — Constraint interview

Pick a real or hypothetical product. Answer:

- What are the top 5 user journeys?
- What is the required rendering strategy?
- What is the JS performance budget?
- What is the expected team size?
- What is the maintenance horizon?
- What integrations are required?
- What design-system constraints exist?
- What migration constraints exist?

Do not choose a framework until this is complete.

Exercise 2 — Decision matrix with evidence

Create a weighted matrix for React, Vue, Svelte, and native web.

For every score above 3, write evidence.

For every score below 3, write mitigation.

Exercise 3 — Failure-mode analysis

For your preferred framework, list 10 ways the choice can fail over two years.

Example:

React chosen -> no state conventions -> three competing data-fetching patterns -> duplicated cache bugs -> workflow inconsistency

Then define preventive controls.

Exercise 4 — Migration plan

Assume you have a 7-year-old SPA. Design a migration strategy that does not require a big-bang rewrite.

Include:

• routing boundary;
• shared auth/session;
• design tokens;
• observability;
• test coverage;
• rollback mechanism;
• first route to migrate;
• success metric.

Exercise 5 — ADR writing

Write an ADR choosing one framework and rejecting the others. The rejection section must be respectful and constraint-based, not preference-based.

16. Senior-Level Heuristics

1. Framework choice is risk allocation.
2. Popularity reduces some risks but increases complacency risk.
3. Performance comes from architecture, not framework branding.
4. A framework with fewer choices can be better for teams with weak governance.
5. A flexible framework requires stronger conventions.
6. Compiler-first systems shift complexity from runtime to build semantics.
7. Native web is powerful when the platform is enough and dangerous when you accidentally rebuild a private framework.
8. Rewrites usually underestimate hidden behavior.
9. The best framework decision includes an exit strategy.
10. Most frontend failures are not framework failures; they are boundary, state, data, and governance failures.

17. References

• React Documentation: https://react.dev/
• React Server Components: https://react.dev/reference/rsc/server-components
• Vue Introduction: https://vuejs.org/guide/introduction
• Vue Single-File Component <script setup>: https://vuejs.org/api/sfc-script-setup
• Vue API Reference: https://vuejs.org/api/
• Svelte 5 Migration Guide: https://svelte.dev/docs/svelte/v5-migration-guide
• Svelte Reactivity Docs: https://svelte.dev/docs/svelte/svelte-reactivity
• MDN — Web Components: https://developer.mozilla.org/en-US/docs/Web/API/Web_components
• MDN — Custom Elements: https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements
• MDN — Shadow DOM: https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM

18. What Comes Next

The next part applies this decision-making to one of the most common modern production stacks: Next.js production architecture.

We will focus on App Router, Server Components, caching, streaming, deployment topology, self-hosting constraints, and failure modes.