Why React Was the Wrong Choice for This Web App

Context

CX.dev partnered with a privacy-focused client building a secure web application where data minimization, attack-surface reduction, and long-term maintainability were non-negotiable requirements.

This was not a typical growth-oriented SaaS product.
It was a system that needed to be boring, predictable, and defensible under scrutiny.

At first glance, React appeared to be the safe, industry-standard choice.

It wasn’t.

The Problem With the “Default” Choice

React’s ecosystem is optimized for flexibility, velocity, and composition. Those strengths come with trade-offs that matter deeply in privacy-sensitive environments:

• Form handling is abstracted away from native browser behavior
• State management and validation often rely on third-party libraries
• Production apps routinely pull in dozens (sometimes hundreds) of dependencies
• Each dependency introduces a new supply-chain and runtime attack vector

For this client, every additional abstraction increased:

• Audit surface
• Compliance burden
• Long-term operational cost

The system didn’t need infinite flexibility.
It needed correctness, restraint, and fewer moving parts.

The Alternative: Native by Default

We selected Svelte and deliberately leaned on native browser primitives, especially for forms and submission flows.

This had several immediate effects:

1. Reduced Attack Surface

• Native HTML forms handle edge cases React apps often re-implement manually
• Fewer client-side abstractions meant fewer places for subtle bugs and exploits
• No need for large validation or form-state libraries

2. Fewer Dependencies

• Significantly smaller dependency graph
• Lower exposure to supply-chain vulnerabilities
• Easier long-term maintenance and security patching

3. Simpler Mental Model

• Business logic stayed close to the browser’s default behavior
• Fewer framework-specific failure modes
• Easier onboarding for future engineers and auditors

In short: less code doing less work, in fewer places.

Why This Was a Security Decision, Not a Framework Preference

This wasn’t about React vs. Svelte as technologies.

It was about system behavior under real-world constraints:

• Privacy requirements
• Adversarial threat models
• Long-term ownership
• Regulatory scrutiny

React would have worked.
But it would have required more compensating controls to reach the same security posture.

Choosing Svelte allowed the team to:

• Avoid unnecessary work
• Reduce risk instead of managing it
• Build a system aligned with the client’s values

Outcome

• Lower operational complexity from day one
• Smaller dependency footprint
• Reduced privacy exposure
• Lower long-term cost of ownership

Most importantly, the system behaved predictably without relying on heroics, patches, or constant vigilance.

Takeaway

Industry defaults are optimized for averages.
Serious systems are built for specifics.

Sometimes the most responsible engineering decision is not choosing the most popular tool—but the one that allows you to do the least harm by default.