In the early web, we built with templates.

HTML acted like the canvas, while server-side tools like PHP or Ruby did the drawing. CSS came in to add the color. If any behavior was needed, JavaScript was sprinkled on top as an afterthought. It was a very strict kind of separation of concerns, structure, logic, and style, each lived in their own separate boxes. And back then, it made sense. Most interfaces were static. The browser just rendered what the server gave it and moved on.

But then things started to change. The web wasn’t just pages anymore; it became a platform for building full applications. Clicking a button couldn’t always mean refreshing the page.

Interactions had to feel smooth, immediate, and alive. And suddenly, templating systems that only filled in data weren’t enough. We needed a new way to build, a new idea that captured what modern interfaces had become: living, breathing, interactive systems.

The End of Templates — and the Beginning of Components

Before React became popular, most frontend development was built around templating languages like Handlebars, Mustache, or early Angular. These tools made it easy to combine HTML and data, but they had limitations. They saw the UI as mostly static, something you filled with data and rendered once. There wasn’t much room for behavior, state, or rich user interaction.

React changed that, not just with JSX, but with a completely new way of thinking about building interfaces.

As Pete Hunt put it at JSConf Asia 2013, “We like to think of components as mixing markup and display logic.” That shift wasn’t just about using a new syntax. It was about rethinking how we organize code. Instead of keeping HTML, CSS, and JavaScript in separate files, React suggested bringing everything related to a piece of UI into one place. A component became more than markup; it became a full unit that included structure, logic, styling, and behavior.

This was the architectural idea Jordan Walke introduced at Facebook, a way to build UIs using small, focused components that are easy to reuse, reason about, and compose into larger systems.

Why Reusable Components Matter

Once you adopt the mental model of UI as a function of state, something profound happens: your interface naturally breaks into smaller parts, not randomly, but in a structured, meaningful way. Each part becomes a component: a focused unit that knows how to render itself based on the data it receives.

A reusable component works a lot like a pure function. It takes in props, handles its own state (or responds to it), and keeps its logic and styles self-contained. It doesn’t depend on global variables or unpredictable side effects. Because of this, you can use it anywhere, in a form, a modal, or a dashboard, without needing to rewrite or tweak it. That kind of reusability isn’t just a coding trick. It’s a way of designing software that’s easier to maintain, scale, and understand.

Pete Hunt summarized it perfectly:
“Components are reusable, composable, and unit testable because they are isolated units.”And in this case, isolation isn’t about disconnecting from everything; it’s about being clear about what a component needs and what it does. That clarity is what makes components easy to reuse, simple to test, and safe to build on, without worrying about the rest of the app.

Components as Systems, Not Files

The rise of components introduced something powerful: composability, the idea that small, focused pieces of UI could be combined to form more complex interfaces. Think of a Card component. It might have a Header, a Body, and a Footer. And each of those could be built from even smaller parts, like an Avatar, a Button, or a Text label. This kind of structure isn’t just a byproduct; it’s part of how components are meant to work.

Instead of organizing code around files or templates, developers started to think in terms of systems, collections of parts that each do one job well and fit together cleanly. Because components are both isolated and composable, they make it easier to build frontends that are scalable, testable, and expressive.

You’re no longer just stitching together bits of HTML; you’re composing ideas.

From Component to Design Language

As this mental model matured, it spread.

Figma began reflecting component logic in design, letting designers reuse and nest elements like developers do. Storybook made it possible to view and test components on their own, outside the main app. Libraries like Chakra UI, Material UI, and Tailwind UI kits turned these patterns into full design systems, structured collections of reusable components, all following the same set of rules.

Reusable components changed how we think. Instead of writing HTML and CSS, we started using a shared visual vocabulary. A Button wasn’t just a styled tag; it became a way to express, “this is how clicking feels in our app.” A Card wasn’t just boxes on a page; it became a visual language for organizing content.

That’s the real value of reusability: not just saving effort, but creating components that express meaning, structure, and behavior consistently across the entire product.

Testability Through Isolation

Testability isn’t something extra that components happen to offer; it’s baked into how they’re designed.
You can render a component, give it some props, trigger events like clicks, and check what it does, all without needing to start up a full app or connect to a server. That’s possible because components are made to be predictable. They don’t rely on hidden things in the global scope, and they don’t bring along unexpected dependencies. Each one is a small, focused piece of behavior, kind of like a pure function, but for UI.

That’s why isolation matters. It’s not a constraint, it’s an intentional design choice. And it’s what makes components reliable to work with, easy to test, and quick to debug. It’s the thing that lets you move fast and trust your work.

Components as Language

At their core, components aren’t just bits of code; they form a language built on purpose.
They give developers and designers a shared way to talk about what things mean, not just how they look. When you use a Button again, it’s not just about saving time; it’s a signal: this is how clicking should feel throughout the app. A Card isn’t just a layout block; it shows how related information belongs together.

That’s the true power of reusable components. They don’t just help you build faster — they help everyone on the team understand the interface more clearly.

We’re Building Components, Not Templates

When Pete Hunt said, “We’re building components, not templates,” he wasn’t just talking about code; he was pointing to a whole new mindset.

Templates are about creating something static; they focus on how the final HTML looks. Components go deeper. They’re about building blocks that hold both structure and behavior. Templates assume you’re building a single page; components assume you’re building a system.

This shift, from assembling markup to thinking in behavior-driven units, completely changed how we build for the web. React didn’t just give us new syntax; it gave us a new mental model. And once you begin thinking in components, it’s hard to imagine going back.