Jordan Walke and React: How Components Changed UI Architecture

Who Is Jordan Walke, and Why React Mattered

Jordan Walke is a software engineer best known for creating React while working at Facebook. Before React, frontends were often built around pages, templates, and a growing pile of “glue code” that tried to keep HTML, CSS, and JavaScript in sync. Walke’s key idea was to flip the model: instead of treating UI as a set of documents you patch over time, treat it as a tree of small, reusable components that you compose into bigger features.

The shift: from templates to components

This wasn’t just a new library—it was a new way to think about UI work. A component bundles a piece of interface with the logic and state it needs, then exposes a clean interface (props) to the rest of the app. That makes UI feel more like building with Lego bricks than editing a single fragile page.

React mattered because it helped teams:

• Build features by composing predictable pieces
• Let data changes drive what you see, rather than manually updating the DOM
• Scale codebases with clearer boundaries and more reusable patterns

What this post covers (with minimal jargon)

We’ll walk through the practical ideas that made React influential:

• Composition: how components snap together and stay maintainable
• Declarative UI (including JSX): describing the UI you want, not the steps to draw it
• State-driven rendering and one-way data flow: keeping updates predictable
• A high-level view of the virtual DOM and reconciliation (without mythology)
• How these ideas changed frontend architecture, team workflows, and long-term maintainability

You don’t need to be a framework expert to follow along. The goal is to make the mental model clear—so you can recognize good React patterns, avoid common misconceptions, and apply the same principles even outside React.

The Frontend Problems React Set Out to Fix

Before React, many teams built rich interfaces by stitching together templates, jQuery-style DOM manipulation, and a growing pile of “when X happens, update Y” rules. It worked—until the UI got busy.

Pain point #1: Manual DOM updates that don’t stay consistent

A common pattern was: fetch data, render HTML, then attach event handlers that mutate the DOM directly. The moment state changed (a new item, a validation error, a toggle), someone had to remember every place that depended on it.

That led to bugs like:

• A counter updates in the header but not in the sidebar.
• A loading spinner disappears in one panel but stays stuck in another.
• An “Edit” form shows stale values after saving.

Pain point #2: Duplicated UI logic across features

As screens evolved, the same business rules ended up duplicated in multiple handlers: “disable the button if the field is empty,” “highlight unread items,” “show the empty state if there are no results.” When requirements changed, you had to hunt through unrelated files to update each copy.

Why UI complexity grows faster than data complexity

Data can be modeled with a few clear structures: a list of posts, a user object, a set of filters. UI, however, adds combinations: loading vs. loaded, error vs. success, read vs. unread, editing vs. viewing, filtered vs. unfiltered—often all at once.

The need: predictable rendering when data changes

Imagine a news feed:

• You load 20 posts.
• A “new posts” banner appears.
• You like a post, mark another as read, and apply a filter.

Without a predictable rule like “the UI is a function of state,” you end up coordinating many DOM edits that can conflict. React’s goal was to make updates dependable: change the data/state, and the UI re-renders to match—every time.

The Component Model: UI as Small, Reusable Pieces

A component is a small piece of the user interface that you can name, reuse, and reason about on its own. In plain language: a component takes inputs, and it returns what the UI should look like for those inputs.

That “inputs → output” framing is the heart of the component model. Instead of treating a screen as one big template, you split it into purposeful building blocks—buttons, cards, menus, forms, and entire sections—then assemble them.

Props: the inputs that shape what you see

In React, the most common inputs are props (short for “properties”). Props are values you pass into a component to configure it: text, numbers, flags, event handlers, or even other UI.

The output is the UI the component renders. If the props change, the component can produce a different output—without you manually hunting down where to update the DOM.

For example, a Button component might receive props like label, disabled, and onClick. A UserCard might receive name, avatarUrl, and status. You can read the component’s interface (its props) the same way you’d read a product spec: “What does this UI need in order to render correctly?”

Reuse and consistency: build once, use everywhere

Breaking UI into components pays off quickly:

• Reuse: the same Modal, Input, or Dropdown can appear across multiple pages.
• Consistency: shared components enforce one look-and-feel and one set of behaviors (validation, spacing, accessibility) instead of letting every page reinvent them.
• Faster changes: update the component once, and every place it’s used benefits.

This is a big shift from copying and tweaking markup per page. Components make duplication feel unnecessary—and eventually, unacceptable.

The mental model shift: think in pieces

React encourages you to design UI the way you’d design a system: as composable parts. A “Checkout page” becomes a tree of components—CheckoutPage containing OrderSummary, ShippingForm, and PaymentMethod. Each part has clear inputs and a clear responsibility.

That shift—thinking in components first—is a major reason React changed frontend architecture. It gave teams a shared unit of design and development: the component.

Declarative UI and JSX: Describing the View

React’s biggest mental shift is declarative UI: you describe what the interface should look like for a given state, and React handles updating the page when that state changes.

Instead of manually finding elements, editing text, toggling classes, and keeping the DOM in sync, you focus on the “shape” of the UI. When data changes, the UI is re-described, and React figures out the minimal set of changes needed.

JSX as a readable way to express structure

JSX is a convenient way to write component structure using a syntax that looks like HTML inside JavaScript. It’s not a new templating language you must learn from scratch; it’s a shorthand for “this component renders this tree of elements.”

The key benefit is that markup and the logic that decides what to show live together, which makes components easier to understand in isolation.

Declarative vs. imperative (a quick contrast)

Imperative code focuses on how to update the UI step by step:

// Imperative: manually keep the DOM in sync
function setLoggedIn(isLoggedIn) {
  const el = document.querySelector('#status');
  el.textContent = isLoggedIn ? 'Welcome back' : 'Please sign in';
  el.classList.toggle('ok', isLoggedIn);
  el.classList.toggle('warn', !isLoggedIn);
}

Declarative code focuses on what the UI should be for the current state:

function Status({ isLoggedIn }) {
  return (
    <p className={isLoggedIn ? 'ok' : 'warn'}>
      {isLoggedIn ? 'Welcome back' : 'Please sign in'}
    </p>
  );
}

Why teams like it

Because rendering is expressed as a pure description, components tend to be more readable, easier to review, and simpler to refactor. Designers, product-minded engineers, and newer teammates can often follow JSX without hunting through event handlers and DOM mutations.

This clarity improves collaboration: UI decisions are visible in one place, and changes are less likely to create hidden side effects elsewhere in the interface.

State-Driven Rendering and One-Way Data Flow

“State” is simply the data that can change over time while a user is interacting with your UI. It might be the current text in a search box, whether a menu is open, the items in a cart, or the result of a network request. If it can change and the screen should reflect that change, it’s state.

State-driven rendering: the UI follows the data

React’s key move is to treat rendering as a consequence of state, not a sequence of manual DOM steps. You describe what the UI should look like for a given state. When state updates, React re-renders the relevant parts.

That mental model is different from “find an element, then update its text, then toggle this class.” Instead, you update the state, and the UI naturally updates because it’s derived from that state.

One-way data flow: fewer surprises, easier debugging

One-way data flow means data moves in a single direction:

• A parent component passes data down to children via props.
• Children can request changes by calling callbacks.
• State lives in a clear owner (often the component that coordinates the feature).

This reduces surprises because you can follow the path of an update: an event happens, state changes in one place, and the UI re-renders from that new state. There’s less “who changed this value?” ambiguity.

A small scenario: button click updates a count

function Counter() {
  const [count, setCount] = React.useState(0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Add</button>
    </div>
  );
}

Here, count is state. Clicking the button updates state with setCount. React then re-renders, and the paragraph shows the new number. You never directly “edit the DOM.”

The same pattern scales to filtering lists (state = filter text, UI = filtered items) or form validation (state = field values and errors, UI = messages). Data changes first; the view is just the result.

Reconciliation and the Virtual DOM (High-Level View)

React’s key idea isn’t “redraw the page faster.” It’s: treat the UI as the result of state, and when state changes, compare what you want now with what you had before—then update only what actually changed.

Comparing UI versions instead of rewriting everything

When a component’s state or props change, React calls your components again to produce a new description of the UI. Think of it like taking two snapshots:

• Snapshot A: what the UI looked like before
• Snapshot B: what the UI should look like now

Rather than clearing the DOM and rebuilding it, React tries to compute the smallest set of DOM operations needed to move from A to B.

What “virtual DOM” means (without the hype)

The “virtual DOM” is simply React’s in-memory representation of the UI—a lightweight tree of elements (and component output) that describes what should be on the screen. It’s not a second browser or a faster DOM. It’s a data structure React can inspect and compare efficiently.

Reconciliation: figuring out what changed

Reconciliation is the process of figuring out what changed between the previous virtual tree and the next one. React uses heuristics to do this quickly, such as:

• Elements of different types are treated as different (a <div> isn’t a <span>)
• Keys help identify items in lists so React can match “the same item” across renders

Once React knows what changed, it applies targeted updates to the real DOM.

A practical note on performance

This isn’t magic. Performance depends on patterns: stable keys, avoiding unnecessary re-renders, keeping component work small, and not doing expensive computation during rendering. React can reduce DOM churn, but your component structure and data flow still determine how smooth the app feels.

UI Composition Patterns That Scale

React’s biggest scaling trick isn’t a feature flag or a framework add-on—it’s composition: building screens by nesting components, passing data via props, and using children to let a component “wrap” other UI.

When teams lean into composition, they stop thinking in terms of one-off pages and start thinking in terms of small, reliable parts that can be rearranged without rewriting everything.

Composition basics: nesting, props, and children

Nesting is the visual version of how the UI is structured: a page contains sections, which contain cards, which contain buttons. Props are the configuration knobs (text, states, callbacks). And children is how you create components that provide structure while letting callers decide what goes inside.

A good mental model: props customize, children fill in, nesting assembles.

Patterns you’ll see in healthy React codebases

Layout components define structure and spacing without owning business logic. Examples: Page, SidebarLayout, Stack, Modal. They often rely heavily on children, so the same layout can wrap many different screens.

Reusable inputs standardize form behavior and styling: TextField, Select, DatePicker. Instead of copying labels, error states, and validation messaging across screens, you centralize those decisions and expose a simple prop API.

List and item components keep repeated UI predictable. A common split is ItemList (fetching, pagination, empty states) plus ItemRow (how one thing looks). This makes it easier to change rendering without breaking data handling.

Sharing behavior without sharing markup

Hooks are the modern way to reuse stateful behavior (like toggles, form state, or fetching) across components without forcing them into the same UI shape. That separation helps teams evolve design while keeping logic consistent.

Why this supports design systems

Composition is how design systems stay consistent: components become the “approved” building blocks, and layouts define the rules of spacing and hierarchy. When the system updates—colors, typography, interaction states—products inherit improvements with fewer manual edits.

Managing State: From Local to Shared

State is just “data that can change.” In React, where that state lives matters as much as the state itself.

Local component state: keep it close to where it’s used

Local state belongs to a single component (or a small widget) and doesn’t need to be read elsewhere. Think: whether a dropdown is open, the current value of an input, or which tab is selected.

Keeping this state local reduces coordination and makes components easier to reuse. A good rule: if only one component cares about it, don’t export it to the rest of the app.

When state becomes shared (and why)

Shared app state is data multiple parts of the UI must agree on. Common examples include:

• Authentication status and the current user
• Theme (light/dark) and accessibility preferences
• Shopping cart contents
• Search and filtering criteria used by several components

Once multiple components need the same source of truth, duplicating state leads to mismatches (“header says 3 items, cart page says 2”).

Common approaches (conceptual)

Lift state up: move the state to the closest common parent and pass it down via props. This is often the simplest option and keeps data flow explicit.

Context: useful when many components need the same value without “prop drilling,” such as theme or auth. Context is best for relatively stable, app-wide concerns.

External stores: when state grows complex (frequent updates, derived data, cross-page workflows), a dedicated store can centralize logic and updates.

Predictability: prefer a single source of truth

React’s one-way data flow shines when there’s a clear owner for each piece of state. Aim for a single source of truth where practical, and derive the rest (counts, totals, filtered lists) from that state instead of storing duplicates.

Maintainability: Testing, Refactoring, and Team Workflows

React’s biggest day-to-day win isn’t a clever rendering trick—it’s how component boundaries turn UI work into smaller, safer changes. When a component has a clear responsibility and a stable public “surface” (its props), teams can refactor internals without forcing rewrites across the app. That stability makes code reviews easier, reduces accidental breakage, and helps new teammates understand where to make changes.

Testing: treat components as pure-ish functions

A useful mental model is: given props and state, a component should predictably describe UI. Even though effects and browser APIs exist, most of a component’s logic can remain deterministic. That’s why maintainable React testing often focuses on behavior and output:

• Render the component with specific props/state and assert what users can see and do.
• Prefer testing through the DOM (text, roles, labels) over internal methods.
• Mock boundaries (network, storage, time) so tests stay fast and reliable.

Accessibility checks fit naturally here: if you test using roles and accessible names, you catch missing labels, broken focus states, and inconsistent semantics early. Consistency checks (linting, formatting, design-system usage) reinforce the same idea: predictable components are easier to maintain.

Team workflow: stable contracts scale collaboration

When components expose a small prop API and hide implementation details, multiple people can work in parallel—one adjusts styling, another changes data fetching, a third updates tests—without stepping on each other.

Checklist: maintainable component design

• One clear responsibility per component.
• Props form a small, stable API (avoid “kitchen sink” props).
• Prefer composition over deep prop drilling.
• Keep side effects isolated (hooks/utilities), not scattered.
• Write tests around user-visible behavior (including accessibility).
• Reuse shared patterns via a design system or common primitives.

Performance Basics Without the Myths

React performance is usually less about “React being slow” and more about how much work your app asks the browser to do. The fastest UI is the one that does the least: fewer DOM nodes, less layout/reflow, fewer expensive calculations, and fewer network round-trips.

Common pitfalls: where wasted work sneaks in

A frequent issue is unnecessary re-renders: a small state change causes a large subtree to re-render because the state lives too high up, or because props change identity every time (new objects/functions created inline).

Another classic pain point is heavy lists—hundreds or thousands of rows with images, formatting, and event handlers. Even if each row is “cheap,” the total work adds up, and scrolling becomes janky because the browser can’t keep up.

Practical optimizations that usually pay off

Start with structure:

• Split components so state updates only re-render the parts that actually change.
• Use memoization (e.g., memoized components or memoized calculations) when a component is re-rendering with the same inputs.
• Apply virtualization/windowing for long lists so you only render what’s visible.

Also focus on what users feel: reduce input lag, speed up first meaningful paint, and keep interactions smooth. A 20ms improvement in a frequently used interaction can matter more than shaving 200ms off a rare screen.

“Derived state”: compute it, don’t store it

Derived state is data you can compute from other state/props (like fullName from firstName + lastName, or filtered items from a list + query). Storing it often creates bugs: you now have two sources of truth that can drift.

Prefer computing derived values during rendering (or memoizing the computation if it’s expensive). Store only what you can’t derive—typically user input, server responses, and UI intent (like “is the panel open?”).

How React Rewired Frontend Architecture

React didn’t just introduce a nicer way to write UI; it nudged teams to reorganize how frontends are built, shared, and maintained. Before components became a default mental model, many projects treated the UI as pages with scattered scripts and templates. With React, the unit of architecture increasingly became the component: a piece of UI with a clear API (props) and predictable behavior.

SPAs, routing, and “app-like” structure

React fit neatly into the rise of single-page applications (SPAs). When rendering is driven by state, the “page” stops being a server-delivered template and starts being a composition of components plus client-side routing. That shift made it common to structure code around feature areas and reusable UI parts rather than around separate HTML files.

Component libraries and design systems

Once UI is built from reusable pieces, it’s natural to standardize those pieces. Many organizations moved from copy‑pasting markup to building component libraries: buttons, form controls, modals, layout primitives, and patterns like empty states. Over time, those libraries often evolved into design systems—shared components plus guidelines—so teams could ship consistent experiences without reinventing UI for every screen.

A shared UI vocabulary across teams

Components encouraged teams to name things the same way. When everyone talks about a <Button>, <Tooltip>, or <CheckoutSummary>, conversations become more concrete: people can discuss behavior and boundaries, not just visuals. That shared vocabulary also helps new teammates onboard faster, because the system is discoverable through code.

Ecosystem influence beyond React

React’s success influenced how the broader frontend community thought about UI: component-first development, declarative rendering, and predictable data flow became common expectations. Other frameworks embraced similar ideas, even when the implementation details differed, because the underlying practices proved easier to scale in real teams.

Trade-Offs, Misconceptions, and an Adoption Checklist

React earned its reputation by making complex UIs easier to evolve, but it’s not “free.” Knowing the trade-offs up front helps teams adopt it for the right reasons—and avoid cargo-cult decisions.

Real trade-offs to plan for

React has a learning curve: components, hooks, and mental models like state updates and effects take time to internalize. Modern React also assumes build tooling (bundling, linting, TypeScript optional but common), which adds setup and maintenance. Finally, React introduces abstraction layers—component libraries, routing, data fetching patterns—that can be helpful, but can also hide complexity until something breaks.

Common misconceptions (and the reality)

“React is only the view.” In theory, yes; in practice, React strongly shapes your architecture. Component boundaries, state ownership, and composition patterns influence data flow and how teams organize code.

“The virtual DOM is always faster.” The virtual DOM is mainly about predictable updates and developer ergonomics. React can be fast, but performance depends on rendering patterns, memoization, list sizes, and avoiding unnecessary re-renders.

Where React shines (and when to keep it simple)

React is a strong fit for apps with lots of interactive states, long-lived codebases, and multiple developers working in parallel. For a mostly static marketing site or a couple of small widgets, simpler options (server-rendered templates, lightweight JS, or minimal frameworks) may be easier to ship and maintain.

Adoption checklist + next steps

• Define your UI complexity and expected lifespan (months vs. years).
• Choose a baseline stack (React + a framework, or React-only) and document conventions.
• Agree on a state strategy: what stays local vs. shared.
• Standardize testing (component + integration) and code review rules.
• Budget time for performance checks and accessibility.

If you’re prototyping a React app and want to validate these ideas quickly (component boundaries, state ownership, composition patterns), a vibe-coding workflow can help. For example, Koder.ai lets you describe features in chat and generate a working React frontend plus a Go/PostgreSQL backend, then iterate with snapshots/rollback and export the source code when you’re ready to take over manually. It’s a practical way to test architecture decisions on a real feature before committing to a full build.

Next: prototype one real feature, measure complexity and team velocity, then scale patterns deliberately—not by default.