Framework Fatigue is Real: Our Design System Survived 3 Framework Rewrites - Here's What I Learned

maya_builds · February 23, 2026, 5:52pm

I need to vent a little and maybe save some of you from the pain I’ve experienced.

I’ve been in tech for 12 years. In that time, I’ve watched the frontend landscape go: Angular → React → Vue → Svelte → back to React. And I’ve lived through rewriting our design system for almost every transition.

The Current Situation

I’m a design systems lead at a mid-size company. Our engineering team is excited about Svelte 5 and SolidJS, citing “better performance” and “smaller bundles.” They want to rewrite parts of our stack.

My immediate reaction: Here we go again.

The Pattern I’ve Seen

Every 2-3 years, a new framework emerges promising:

25-40% better performance
Better developer experience
The “right way” to build UIs
“This time it’s different”

And you know what? They’re often technically correct. The new framework is better in benchmarks.

The Reality I’ve Lived

2019: Angular to React

Reason: React is faster, better ecosystem, easier to hire
Time: 8 months to rewrite our component library
Result: Yes, it was better. But was it 8 months better?

2021: Almost moved to Vue 3

Reason: Composition API is cleaner, smaller runtime
Decision: Stayed on React
Reason: Team stability, ecosystem, hiring pool

2024: Evaluating Svelte 5

Reason: Compiler-based, no virtual DOM, better performance
Current status: Seriously considering
But: Is this just the same cycle repeating?

The Question That Haunts Me

When is “better performance” actually worth the rewrite cost?

Let me ground this with data from our current React app:

Latest React compiler cuts unnecessary re-renders by 25-40%
React Server Components reduced our load time from 2.4s to 0.8s
Our app is fast enough - users don’t complain about performance

So when the team says “Svelte would be 30% faster,” I ask: 30% faster than what? Our already-fast app?

What I’ve Noticed About Frameworks in 2026

Here’s something interesting: All frameworks are converging on the same patterns:

Fine-grained reactivity: Svelte, Solid, and Vue all have it. React’s getting there.
Server-first rendering: Next.js, SvelteKit, Solid Start, Nuxt - everyone’s doing it.
Compiler-driven optimizations: React 19 has a compiler now, not just Svelte.
TypeScript baseline: It’s expected everywhere.

The frameworks are getting more similar, not more different.

The Svelte/Solid Advantage (Being Honest)

I’ll be fair - there are real advantages:

Smaller bundles: Svelte ships less JavaScript
Faster runtime: No virtual DOM overhead
Cleaner syntax: Less boilerplate
Better performance: Especially on lower-end devices

These are real. I’m not dismissing them.

But: The React Advantages

Ecosystem: Component libraries, tooling, examples everywhere
Hiring: Far larger talent pool
Stability: React isn’t going anywhere
Cross-platform: React Native means mobile code sharing
Team knowledge: Our team knows React deeply

My Current Stance

We’re staying on React and investing in optimization rather than rewriting:

Using the React 19 compiler
Implementing RSC where it makes sense
Code splitting and lazy loading
Performance monitoring and targeted fixes

Rewriting to Svelte would make our benchmarks better. But would it make our product better?

The Design Perspective

From a design systems standpoint, framework choice matters less than consistency. Users don’t care if we use React or Svelte. They care that:

The app is fast enough
The experience is consistent
Features work reliably
The design feels cohesive

We keep chasing framework improvements, but users notice design consistency more than JavaScript framework performance.

When I’d Actually Switch

I’d consider rewriting if:

Current framework is genuinely holding us back - Not theoretically, actually
Performance is losing us users - Data-proven, not assumed
We can’t hire/retain engineers - Because the stack is too outdated
The ecosystem is dying - And we’re at real risk

None of those are true for React in 2026.

The Lesson

Pick a framework based on:

Team stability and knowledge
Hiring market
Ecosystem maturity
Long-term support
Actual (not theoretical) product needs

Not based on:

Benchmark wars
Hacker News hype
Fear of missing out
“X is the future” predictions

My Question for Everyone

How do you all handle framework decisions? Are you staying stable or frequently adopting new frameworks? How do you balance innovation with stability?

Have you regretted staying on an older framework? Or regretted switching to a newer one?

Would love to hear experiences from both sides.

Maya

alex_dev · February 23, 2026, 5:53pm

Maya, I feel this so deeply. I’ve lived through the exact same framework churn and the fatigue is real.

The JavaScript Fatigue is Real

Remember when we all talked about “JavaScript fatigue” around 2016-2017? It felt like every week there was a new framework or build tool we “had” to learn. That hasn’t really stopped, it’s just slowed down a bit.

But: Innovation Got Us Here

Here’s the thing though - as exhausting as it’s been, that innovation is how we got to where we are today.

React wouldn’t have added a compiler without Svelte showing the way
Server components emerged from exploring different rendering models
Streaming and suspense came from rethinking how data loading works

The churn has been painful, but it’s driven the whole ecosystem forward.

The Balance Question

So how do we balance:

Stability: Needed for team velocity and product reliability
Innovation: How we improve and stay competitive

I don’t have a perfect answer, but here’s what I’ve been thinking:

Use a Stable Framework for Product

For the core product that generates revenue and serves users: Stability wins.

Choose a mature framework (React, Vue, Angular even), commit to it, and optimize the hell out of it. Don’t rewrite unless you have a compelling business reason.

Experiment on Side Projects

For internal tools, marketing sites, side projects, proof-of-concepts: Experiment freely.

Try Astro for the marketing site (island architecture is cool)
Build internal admin panel in Svelte
Prototype new features in SolidJS
Use these as learning opportunities

This way:

Team gets to learn new tech
You evaluate frameworks with low risk
Innovation doesn’t disrupt core product
Engineers stay engaged and growing

The Astro Example

We recently used Astro for our marketing site and the team loved it. Island architecture makes sense for content-heavy sites with some interactivity.

Did it make sense to rewrite our entire product in Astro? No. But it was a great learning experience and the right tool for that specific job.

My Question Back

How do you handle the team morale aspect of this? Engineers want to work with modern tools and learn new things. Saying “we’re staying on React forever” can hurt retention.

Have you found ways to balance team growth and learning with product stability? Or do you just accept that some engineers will leave to work with newer tech?

Alex

eng_director_luis · February 23, 2026, 5:53pm

Maya, as someone who manages 40+ engineers, I have strong opinions about this. Framework standardization is an organizational decision, not just a technical one.

The Fragmentation Problem

A few years ago, we had different teams wanting different frameworks:

Team A: “We should use Vue, it’s cleaner”
Team B: “React is industry standard”
Team C: “Svelte is the future”

This created:

Knowledge silos: Engineers couldn’t easily move between teams
Code reuse problems: Couldn’t share components across projects
Hiring friction: What skills do we hire for?
Maintenance burden: Multiple build systems, toolchains, conventions

The Hard Decision

We standardized on React + TypeScript across all frontend teams. Not because it’s the “best” framework, but because:

Hiring market: Largest pool of experienced developers
Ecosystem maturity: Answers exist for almost any problem
Cross-team mobility: Engineers can work on any project
Component sharing: Design system works everywhere
Long-term stability: React isn’t going anywhere

The Rule We Adopted

Framework Lock: We’ll only change frameworks with:

A 2-year minimum commitment
A business case showing clear ROI
Leadership alignment
Migration plan and resources

This isn’t about being stubborn. It’s about protecting organizational knowledge and velocity.

Where We Allow Flexibility

We do allow experimentation, but strategically:

Build Tools: Teams can choose Vite, Webpack, Turbopack, etc.

Reason: Less organizational impact, easier to change
Benefit: Teams can optimize for their use case

Internal Tools: Marketing site, admin panels, etc. can use different frameworks

Reason: Low risk, good learning opportunities
Benefit: Engineers get to experiment

Feature Flags: Small experiments can use new tech behind flags

Reason: Contained risk, easy to rollback
Benefit: Real-world evaluation

The Cost of Rewriting

Maya, you mentioned 8 months to rewrite your component library from Angular to React. Let me add context from a leadership perspective:

8 months of engineering time = what else could we have built?

We calculated that a framework rewrite for our codebase would take 18 months and delay 2 major features. That’s:

Lost revenue from delayed features
Competitor advantage while we’re heads-down rewriting
Customer frustration from slower feature velocity
Team frustration from “boring” rewrite work

The opportunity cost is massive.

When to Actually Change

I’d only consider a framework change if:

Can’t hire talent - Framework is so outdated nobody wants to work with it
Can’t ship features - Framework limitations are genuinely blocking product progress
Security/maintenance risk - Framework is no longer supported
Competitive disadvantage - Users are choosing competitors because our app is too slow

React in 2026 fails none of these tests.

The Design Collaboration Question

Maya, you mentioned design-engineering collaboration challenges. Here’s a question from the leadership side:

How do you handle designers working with different frameworks?

If your design system spans React, Vue, and Svelte implementations:

Do designers need to understand all three?
How do you ensure consistency?
What’s your documentation strategy?

We’ve found that multiple frameworks make design-engineering collaboration exponentially harder.

Bottom Line

Framework choice is organizational architecture, not just code architecture. Make the decision based on:

Team composition and knowledge
Hiring market
Long-term product needs
Cross-team collaboration requirements

Not based on Hacker News excitement or benchmark comparisons.

Stability is a feature, not a bug.

Luis

mobile_maria · February 23, 2026, 5:54pm

Maya, the mobile perspective on this is interesting because we face framework decisions less frequently but with higher stakes.

Mobile’s Framework Stability

In mobile, framework switches are even more brutal than web:

React Native vs Flutter decision: You’re committing for 3-5 years minimum.

Why?

Deeper platform integration means more code to rewrite
Native modules need complete reimplementation
Migration is harder (no gradual adoption like web micro-frontends)
User impact is higher (app store updates, download sizes)

So mobile has been forced to be more conservative about framework choices.

But: Web Can Experiment More

Here’s what’s interesting about web in 2026: Micro-frontends and island architecture make incremental adoption possible.

You can:

Keep core app in React
Use Astro for marketing site
Try Svelte for a specific feature behind feature flag
Evaluate real-world performance without full rewrite

This is much harder in mobile. Once you pick Flutter or React Native, you’re all-in.

The Recommendation

For web teams, consider stable core + experimental edges:

Core product (80% of code):

Choose stable, mature framework
Commit for 3-5 years
Optimize don’t rewrite

Edge cases (20% of code):

Marketing sites
Admin panels
Internal tools
New experimental features

Use micro-frontend patterns to safely experiment with new frameworks for edge use cases.

Island Architecture

Maya, have you looked at Astro’s island architecture or Qwik’s resumability?

These aren’t full rewrites - they let you:

Keep most of your React components
Ship less JavaScript by default
Add interactivity only where needed

This might be a middle ground between “stay on React forever” and “rewrite everything in Svelte.”

The Platform Difference

Web has the luxury of incremental adoption. Mobile doesn’t.

Use that to your advantage - you don’t have to choose “all React” or “all Svelte.” You can strategically use both.

Maria

product_david · February 23, 2026, 5:54pm

Coming from the product side, I have a different take on this framework discussion.

The Product Perspective

From where I sit, framework rewrites are almost never the right business decision. Let me explain with cold, hard business logic.

What Customers Care About

Customers don’t care if we use:

React vs Svelte vs Vue
Virtual DOM vs compiler
Client-side rendering vs server components

Customers care about:

Does it solve my problem?
Is it fast enough?
Does it work reliably?
Are we shipping new features?

Framework choice is invisible to users unless performance is genuinely bad enough to impact experience.

The Opportunity Cost

When engineering says “we should rewrite in Svelte for better performance,” I hear:

“We should spend 8-18 months NOT shipping features so our benchmarks look better.”

What could we ship instead in 8-18 months?

3-4 major features that customers are asking for
Improvements to existing features that increase retention
Integrations that unlock new market segments
Product improvements that increase revenue

When Performance Actually Matters

Performance matters when:

Data shows users are leaving because of speed issues
Conversion rates improve with faster load times
Competitors are measurably faster and winning customers

If you have that data, then yes - performance work is justified.

But that’s usually optimization work (code splitting, caching, lazy loading), not framework rewrites.

The ROI Question

Maya, you mentioned React compiler gives you 25-40% fewer re-renders and RSC reduced load from 2.4s to 0.8s.

That’s a 70% improvement without changing frameworks.

Compare that to: Rewriting in Svelte might give 30% improvement (maybe) but costs 8-18 months of engineering time.

Which has better ROI?

Framework Choice That Makes Business Sense

Pick framework based on:

Hiring velocity: Can we find engineers quickly?
Team productivity: How fast can we ship?
Ecosystem maturity: Are solutions available?
Long-term stability: Will we need to rewrite again in 3 years?

React wins on all of these in 2026.

The Question I’d Ask Engineering

If the team wants to rewrite for Svelte:

“How will this impact our product roadmap and what customer problems will we not solve as a result?”

If the answer is “it won’t impact roadmap” - they’re wrong. Rewrites always take longer than estimated.

If the answer is “it will delay features but performance is critical” - show me the data proving performance is losing us customers.

Measuring What Matters

Instead of framework benchmarks, let’s measure:

Time to Interactive (TTI)
First Contentful Paint (FCP)
Actual user engagement metrics
Conversion rates
Customer satisfaction scores

Optimize the metrics that impact business outcomes, not the ones that look good in blog posts.

My Take

Framework stability is a product feature. Reliable, fast feature delivery beats cutting-edge technology every time.

Does that make me the “boring” product person who says no to cool tech? Maybe. But my job is business outcomes, not engineering excitement.

Am I missing something from the technical side? Genuinely curious if there are business benefits to framework changes that I’m not seeing.

David