Why We Chose React Over Angular for an ERP

Introduction

When we started building the ERP platform for a tyre manufacturer, the frontend framework was an open question. Angular is the default choice in a lot of enterprise shops, and for good reasons. We went with React, and two years and ten-plus production modules later I still think it was right — but not for the reasons people usually give.

The Problem

Enterprise ERP frontends are a specific kind of hard, and it isn't the kind most framework comparisons talk about.

The modules we had to build were CRM dashboards, order processing, price sheet management, pre-dispatch inspection, plant assignment, product sales. What they have in common:

• Forms with dozens of interdependent fields. Changing a plant changes the available products, which changes the price sheet, which changes validation rules on three other fields.
• Data tables over large result sets, with filtering, sorting, column pinning and Excel export — used by people who keep them open all day.
• Analytics dashboards with charts and KPI cards that re-render as filters change.
• A mobile dispatch app for staff capturing data on the factory floor.

The constraint that mattered most was not technical. It was that a small team had to build and maintain all of it, across web and mobile, without a frontend platform team to lean on.

That reframes the question. It stops being "which framework is better engineered" and becomes "which framework lets a small team ship ten business modules and still change them safely a year later".

The Solution

We evaluated both properly rather than defaulting. Here is the honest comparison as it applied to us.

Concern	Angular	React
Structure	Opinionated. DI, modules, services out of the box	You assemble it. Freedom and rope in equal measure
Forms	Reactive Forms are genuinely excellent for complex validation	Needs a library; more wiring for the same result
Async	RxJS is powerful once the team knows it	Simpler mental model, weaker for complex streams
Learning curve	Steeper. DI, decorators, RxJS, modules	Shallower start, harder to keep consistent at scale
Mobile reuse	Ionic or NativeScript, a separate skill	React Native shares patterns and people
Ecosystem for data grids	Good, smaller	Larger selection, more mature options
TypeScript	First-class by design	Excellent, but opt-in and easy to do badly

Angular wins several of those rows outright. Reactive Forms in particular would have suited our interdependent-field problem better than what we ended up building. If the whole team had known Angular, I would not argue against it.

Three things decided it for us.

The team already knew React. Not a glamorous reason, but the dominant one. Shipping ten modules in two years with a small team leaves no budget for everyone learning DI, decorators and RxJS while also learning the tyre manufacturing domain — which was the genuinely hard part.

We needed a mobile app. The dispatch module had to run on phones on the factory floor. React Native meant the same language, the same component thinking, the same state patterns and the same people. Angular would have meant Ionic or a second skill set. This was the single largest factor.

Incremental adoption fit how the project actually grew. ERP work arrives module by module as the business asks for it. React's smaller surface let us build each module without committing the whole application to one structural decision made in month one.

Framework comparisons argue about architecture. Delivery is usually decided by who is on the team and what else you have to build.

Code

Here is the same idea in both, so the trade-off is concrete rather than abstract. This is a dependent-field pattern: choosing a plant reloads the products available at that plant.

Angular, using Reactive Forms and RxJS:

// Declarative and self-cleaning. switchMap cancels the in-flight request when
// the plant changes again before the previous one resolves.
this.form.get('plantId')!.valueChanges
  .pipe(
    filter(Boolean),
    switchMap((plantId) => this.productService.byPlant(plantId)),
    takeUntilDestroyed(this.destroyRef)
  )
  .subscribe((products) => {
    this.products = products;
    this.form.get('productId')!.reset();
  });

React with Redux Toolkit, which is what we shipped:

const plantId = useWatch({ control, name: "plantId" });

useEffect(() => {
  if (!plantId) return;

  // AbortController does the job switchMap does above: without it, a slow
  // response for plant A can land after plant B was selected and overwrite it.
  const controller = new AbortController();

  dispatch(fetchProductsByPlant({ plantId, signal: controller.signal }));
  setValue("productId", "");

  return () => controller.abort();
}, [plantId, dispatch, setValue]);

The Angular version is better code. switchMap handles cancellation as a property of the operator; the React version handles it because I remembered to. Multiply that across dozens of dependent fields and Angular's guardrails have real value.

What we did instead was make the pattern impossible to get wrong by extracting it once:

/**
 * Dependent select loading. Owns the cancellation so no caller has to
 * remember it — the class of bug it prevents is the reason it exists.
 */
export function useDependentOptions<T>(
  parentValue: string | undefined,
  loader: (value: string, signal: AbortSignal) => Promise<T[]>
) {
  const [options, setOptions] = useState<T[]>([]);
  const [loading, setLoading] = useState(false);

  useEffect(() => {
    if (!parentValue) {
      setOptions([]);
      return;
    }

    const controller = new AbortController();
    setLoading(true);

    loader(parentValue, controller.signal)
      .then(setOptions)
      .catch((err) => {
        if (err.name !== "AbortError") console.error(err);
      })
      .finally(() => setLoading(false));

    return () => controller.abort();
  }, [parentValue, loader]);

  return { options, loading };
}

That is the actual React trade-off in enterprise work. The framework does not enforce the pattern, so you enforce it yourself — once, deliberately, and then you review for it. Angular would have handed us the guardrail. We had to build it.

For tables over large result sets, the ecosystem argument carried real weight. Server-side pagination plus a mature virtualised grid solved our performance problem, and the React options in that space were more numerous and better documented than the Angular equivalents when we chose.

Best Practices

Five things I would tell someone starting an enterprise frontend tomorrow.

Pick for your team and your roadmap, not for the benchmark. The framework you can hire for, and that covers everything you have to build, beats the one with the better architecture. This is unglamorous and it is usually right.

If you choose React, impose the structure Angular would have given you. Decide early where state lives, how data fetching works, how forms are wired — then write it down and review against it. React will not stop you doing it five different ways across five modules. You have to.

Extract the patterns that cause bugs, not the ones that look repetitive. The dependent-options hook exists because a race condition shipped once. That is a better reason to abstract than reducing line count.

Do not virtualise before you paginate. For most ERP tables the real fix is not sending 50,000 rows to the browser. Server-side pagination and filtering solves more than any rendering optimisation, and it is less code.

Revisit the decision honestly. If your team turns over and everyone knows Angular, the reason you chose React has expired. The decision was contextual; the context changes.

Conclusion

Two years in, React was right for us — because of who was on the team, because we needed a mobile app, and because the work arrived incrementally. Not because it is the better framework in the abstract.

What I would do differently: adopt a proper form library on day one instead of module four. Our forms have the interdependent-field complexity that Angular's Reactive Forms handle natively, and we spent real time rebuilding a weaker version of that ourselves. The framework choice was right. Under-investing in the form layer early was not.

If you are making this call now, be suspicious of any comparison — including this one — that does not start by asking what else your team has to ship.