How to Evolve a Large Frontend Without Rewriting Everything

The problem

Large frontends usually trigger two bad reactions.

The first one:

• resignation
• nobody changes anything structural
• the codebase gets more exhausting over time

The second one:

• the urge to rewrite everything
• a broad migration
• the promise that “this time it will finally be right”

Both are dangerous.

In the first case, the debt only accumulates.

In the second, the team creates an expensive side project that is risky and hard to sustain while the real product still needs to move.

Mental model

A large codebase does not improve through emotional reset.

It improves through progressive pain reduction.

Short version:

evolving a large frontend means improving boundaries and the flow of change little by little, without asking the team to stop delivering just to “fix the whole house.”

That does not mean you should never rewrite anything.

It means a broad rewrite should be a well-justified exception, not the automatic reaction to frustration.

Where to start most of the time

1. Start with the most expensive pain

Not every bad area deserves attention right now.

It is usually better to prioritize where there is:

• a recurring bug
• high fear of change
• coupling that blocks delivery
• painful onboarding
• slow review because nobody understands the boundary

That cut is usually better than choosing “the ugliest module.”

2. Improve one full flow, not a generic aesthetic

Renaming things and moving files can create the feeling of progress.

But the real gain usually appears when you improve one end-to-end flow:

• screen
• hooks
• integration
• state
• public boundary

That shows value quickly and teaches the team how to repeat the pattern later.

3. Accept that old and new will coexist for a while

There is almost always a transition phase.

Part of the codebase still follows the old model.

The new part already uses better boundaries.

That is not failure.

It is the normal cost of healthy evolution.

The problem starts when the team demands instant uniformity and creates a migration too large to fit real life.

Simple example

Imagine an old admin panel.

Today it suffers from:

• a giant page
• fetch logic spread everywhere
• duplicated state
• a shared component coupled to one domain

The weak reaction would be opening a big front to “migrate the whole frontend architecture.”

The better reaction would be:

1. choose the most critical flow, such as billing
2. separate server state, URL state, and UI state more clearly
3. reduce cross-imports
4. give components and hooks better roles
5. use that flow as the new reference pattern

After that, the team already gains:

• a concrete example
• shared vocabulary
• less fear of repeating the approach

The role of local anti-corruption

When the old codebase still exists, it is often worth creating a protection boundary.

In practice, that can mean:

• a wrapper around the old API
• an adapter between legacy data and new data
• a transition component
• a more stable entry point for the new feature

That keeps the old part from contaminating everything new that gets built afterward.

Common mistakes

• Trying to solve the whole architecture in one initiative.
• Starting with folder organization before understanding the dominant pain.
• Demanding full migration before collecting any local gain.
• Rewriting with no coexistence plan between old and new.
• Measuring success by how pretty the tree looks instead of how easy it is to change.

How a senior thinks

People who have seen rewrites fail usually use a more pragmatic filter:

• which concrete pain will this change reduce?
• how can I prove gain before expanding scope?
• how do I keep delivery moving while the codebase evolves?
• which new boundary needs to exist first?

That kind of thinking does not look heroic.

But it is usually what makes the change survive.

Interview angle

This topic shows up in:

• frontend system design
• technical leadership
• refactoring and legacy
• questions about web product scale

Weak answer:

I would restructure the frontend and organize everything better.

Strong answer:

• picks a real pain
• proposes a progressive migration
• talks about coexistence between models
• shows prioritization and risk-reduction criteria

That is what usually sounds more senior.

Closing thought

Large frontends almost never need an epic rewrite to start getting better.

Most of the time they need:

• a better boundary
• a clearer target
• smaller steps
• discipline around coexistence

Evolving without rewriting everything is not timidity. A lot of the time it is exactly what separates sustainable change from architectural theater.