Replace Angular. What Breaks?

The Claim

NovaTrade had grown inside Angular, but that did not automatically mean its higher-level behavior belonged to Angular.

By this point, the frontend already contained Application use cases and Domain behavior that were supposed to express responsibilities independently of the UI framework.

Saying that was easy.

Replacing the framework gave us a way to test it.

Define the Proof Before the Change

We did not want to build a React version first and decide afterward that the experiment had succeeded.

The success criteria came first.

Application changes = 0

Domain changes = 0

use-case changes = 0

React-specific code
stays at the UI edge

same meaningful Orders journey
still works

Those criteria mattered because they made the claim falsifiable.

If changing the UI framework forced changes through the Application or Domain, then the architecture was more Angular-dependent than we had claimed.

Change One Variable

The experiment was deliberately narrow.

We did not rewrite NovaTrade.

We changed the UI framework for one meaningful Orders journey.

Angular UI
    ↓
Application
    ↓
Domain

React UI
    ↓
same Application
    ↓
same Domain

That distinction is important.

If we had changed the framework, the Application, the Domain, and the business behavior at the same time, the experiment would have told us almost nothing about the original architectural claim.

React Was Not a Rewrite

React was introduced as an architectural probe.

The goal was not to reproduce the entire Angular frontend in another framework.

One existing load-and-cancel Orders journey was enough.

load Orders
    ↓
select submitted Order
    ↓
cancel Order
    ↓
Application use case
    ↓
Domain behavior
    ↓
updated result

The question was not whether React could implement buttons, rendering, or state.

Of course it could.

The question was whether React could drive the existing higher-level behavior without forcing that behavior to become React code.

Framework-Specific Code Stayed Framework-Specific

Framework independence did not mean removing all framework-specific code.

Angular remained Angular.

React remained React.

Angular components
Angular DI
Angular HttpClient
Angular presentation

React components
React Context
fetch
React presentation

What we refused to create was a fake neutral UI layer whose only purpose was to make the experiment look successful.

FrameworkNeutralComponent

GenericUiAdapter

CrossFrameworkSignalWrapper

Those abstractions would not have demonstrated independence.

They would merely have moved framework concerns behind names that sounded neutral.

The Same Application Sat Behind Both

The useful boundary was not between two invented generic UI abstractions.

It was between framework-owned presentation and responsibilities that belonged to neither framework.

Angular UI ──────┐
                 │
                 ↓
            Application
                 ↓
               Domain
                 ↑
                 │
React UI ────────┘

Both framework edges were allowed to be different.

The higher-level behavior did not need to change merely because the UI technology changed.

What Changed — and What Didn't

UI framework
framework composition
framework rendering
framework-specific integration

Application
Domain
use cases
business behavior

That difference was the evidence.

What It Proved — and What It Didn't

For the journey we tested, replacing Angular with React did not require changes to the frontend Application, Domain, or existing use cases.

That supported the architectural claim for that verified slice.

It did not prove that:

• React is better than Angular.
• Angular is a bad architectural choice.
• every frontend should support multiple frameworks.
• all UI code should be framework-neutral.
• every future framework substitution would be equally easy.

The experiment answered a narrower question:

The Lesson