Skip to content
Sahil Durgia/ full-stack
2 min readReact

Component-Based Architecture: Why It Won, and What It Costs

Breaking a UI into small, composable pieces sounds obviously good. Worth being honest about the real cost, not just the benefit.

Reactcomponent architecturesoftware design

Component-based architecture won across every major frontend framework — React, Vue, Angular, Svelte all organize UI as composable components. It's worth being precise about what that actually buys you, and honest about what it costs, rather than treating it as an unqualified good.

What it actually buys you

  • Reuse with real encapsulation — a Button component's internal markup and styling can change without every call site needing to know or care.
  • Local reasoning — understanding a component's behavior generally only requires reading that component and its direct props, not the whole application.
  • Independent testability — a component with a well-defined prop interface can be tested in isolation, without standing up the entire app around it.
  • A natural unit of ownership — on a larger team, components map cleanly onto "who's responsible for this," the same way the micro-frontend split in the Quote Management System case study mapped ownership onto module boundaries.

The real cost, honestly

Component boundaries are a design decision, and a bad one has a real cost: split too finely, and a simple change requires touching five files to trace one piece of logic. Split too coarsely, and you're back to a monolith with extra function-call overhead and none of the actual benefit. "Where does this component boundary go" is a genuine architecture question with real tradeoffs, not a mechanical exercise — exactly like the micro-frontend-vs-single-app decision one level up.

The practical rule that actually holds up

A component boundary earns its place when it maps to something that's reused in more than one place, OR something that has a genuinely separable concern (a piece of state, a piece of UI logic) that makes the rest of the parent component easier to read once it's extracted. "I might reuse this someday" is not, on its own, a good enough reason — premature abstraction has a real cost too, and it's just as real as the cost of not abstracting soon enough.

Keep reading
Next: JSX, explained

Part 7 of the why-React series.