From MVC to React: How Frontend Architecture Evolved

How forty years of UI architecture fits together: the OOP ideas underneath, Smalltalk's Model-View-Controller, its MVP and MVVM descendants, the single-page app, and React's component model — told through a diner.

Beginner · 15 min read

Why this matters

Every app on your phone answers one question: where does the UI logic live, and how does it talk to everything else? The industry's answer changed four times in forty years. Each change was someone fixing the previous answer's worst pain — and each new answer kept something from the old one. Learn the lineage instead of just the latest framework, and every UI codebase you meet will feel familiar. You've seen its grandparents.

For this lesson, you run a diner.

Video: Traversy Media MVC — Traversy Media
Brad builds a tiny MVC framework from scratch — routing, controllers, models, views — so you can see exactly what a framework adds on top of plain code.

The OOP seeds: what the kitchen already taught you

Last lesson's kitchen gave you two ideas that never leave frontend architecture:

Encapsulation. You don't walk into the kitchen and grab the fryer. You tell the waiter what you want; the kitchen hides its knives, its fire, its mess, and hands you a plate. Objects work the same way: private state, public menu.

Composition. Nobody inherits their dinner from a GrandparentMeal. A meal is composed of dishes; dishes are composed of ingredients. You assemble the plate from parts instead of carving it from one block.

Hold both thoughts. MVC is about to use them, and React will be built on them.

Video: The Four Pillars of OOP Explained in Python — Kandi Brian
Covers the four OOP pillars — the kitchen skills you'll reuse when the waiter metaphor arrives.

MVC, 1988: three jobs, three objects

The idea started with Trygve Reenskaug at Xerox PARC in the late seventies and was written down properly a decade later by Glenn Krasner and Stephen Pope in "A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80" (1988), revised as "A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System." Their summary: MVC is a three-way factoring — objects of different classes take over the operations related to the application domain, the display of the application's state, and user interaction with the model and the view.

In diner terms:

flowchart LR
    You[You<br/>clicks Order]:::client --> W[Waiter<br/>Controller]:::service
    W --> K[Kitchen<br/>Model]:::data
    K --> P[Plate<br/>View]:::client
    P -. watches .-> K

Precise definitions, under the analogy: the model holds data and rules and is unaware of the UI; the view displays state and observes the model; the controller handles input and tells the model what to do. Three jobs, three objects, strict lanes.

One order, end to end:

Interactive diagram: StepThrough (loads in the app)

Video: MVC Design Pattern Demystified — Dara Oladapo | Code, Cloud and DevOps
Plain-English walkthrough of Model, View, Controller and what each object owns.

MVP and MVVM: stricter waiters

MVC's lanes were a little blurry in practice — controllers tended to fatten up. Two descendants tightened the rules:

MVP (Model-View-Presenter). The plate goes passive: it can't talk to the kitchen at all. The presenter — a stricter waiter — carries every message both ways and owns all the display logic. The payoff is testability: you can test the presenter without ever setting a table.

MVVM (Model-View-ViewModel). The menu rewrites itself. The viewmodel translates kitchen state into menu-ready form, and the binding goes both ways: the kitchen runs out of salmon and the menu crosses it out on its own; you circle a dish and the order updates itself. Convenient — until a change ripples from somewhere you weren't watching. Two-way binding is a helpful ghost until it moves a chair.

Both are MVC's children, and both taught the industry the same lesson: the stricter the lanes, the easier the testing — but somebody still has to carry the messages.

Video: MVC, MVP and MVVM Explained — Vikas Kerni's Software Architecture
A platform-neutral three-way comparison — how the controller, the presenter, and the view-model each split responsibility between the view and the model.

The web remix: one table, many courses

Then the web happened, and the diner got weird. In server-side MVC — Rails, Django, and their cousins — the entire restaurant lived on the server. Every click sent you walking to a brand-new restaurant, a full page reload, just to see the dessert menu. It worked. But nobody walks to a new restaurant between courses if they can help it.

JavaScript grew up, and the single-page app arrived: one table, many courses. The page loads once; after that, courses keep arriving without anyone leaving the room. The dining room got smart — the browser now ran real application logic — and the server retreated to being a very good kitchen: an API — a fixed menu of requests the dining room can place, answered as data.

But the smart dining room had a new problem: a whole application's worth of UI state, living in JavaScript, with no architecture to hold it. Enter React.

Video: I built 10 web apps... with 10 different languages — Fireship
One developer rebuilds the same app in ten languages — watch MVC's ideas survive the remix.

React: components all the way down

React rebuilt the dining room from the two OOP ideas you already know:

Components are encapsulation, again. A component is a bento box: self-contained, with its own little compartments of state, a tidy public surface (its props — the inputs a parent component hands down, like the order ticket the waiter carries in), and no peeking inside. A MenuItem doesn't care how OrderButton works. It just uses it.

Composition over inheritance. You don't build a FancyMenuItem by inheriting from MenuItem and overriding three methods. You snap bricks together: a Menu is composed of MenuItems, each composed of a Name, a Price, an OrderButton. LEGO, not woodcarving. The React docs say it outright: favor composition over inheritance.

Unidirectional data flow. State lives near the top and rains down as props — a one-way street. A click doesn't reach sideways into another component; it calls a handler that updates state, and the new state flows back down. Water down a terraced garden: never uphill.

flowchart TD
    S[App<br/>state lives here]:::service --> H[Header]:::client
    S --> M[Menu List]:::client
    H -. events flow up .-> S
    M -. events flow up .-> S

Compare the two eras directly:

Interactive diagram: VsToggle (loads in the app)

Video: Learn React JS - Full Beginner’s Tutorial & Practice Projects — freeCodeCamp.org
freeCodeCamp beginner course built around components — the foundation of React thinking.

Takeaways

  1. MVC (Krasner & Pope, 1988) splits UI work three ways: the model owns data and rules, the view displays, the controller takes input. Three jobs, three objects.
  2. The model never knows the UI exists. The view observes the model; the controller is the only one who talks to both.
  3. MVP makes the view passive and gives the presenter all the logic — easier to test. MVVM adds two-way binding between view and viewmodel — convenient, harder to trace.
  4. Server-side MVC reloaded the whole page per click; SPAs keep one page and let the browser run the dining room, talking to the server as an API.
  5. React is OOP ideas at UI scale: components encapsulate state, UIs are composed rather than inherited, and data flows one way — down as props, up as events.
  6. Learn the lineage and every UI codebase feels familiar. You've met its grandparents.

Check your understanding

  1. In the diner analogy, which role is the Controller — and why?

    • The kitchen, because the kitchen does all the real work
    • The menu board, because it displays every option available
    • The waiter, because it's the only one that takes your input to the kitchen
    • The customer, because every order starts with them

  2. In classic MVC, what does the Model know about the View?

    • Nothing — the model is unaware of the UI; the view observes the model
    • Everything — the model renders each view directly on every change
    • Only the view's address, so the model can push updates to it
    • It builds the view's HTML itself whenever its state changes

  3. What distinguishes MVP from classic MVC?

    • The model and the view merge into a single object that does both
    • The presenter is removed, and the view talks straight to the database
    • MVP requires a relational database underneath to work
    • The view becomes passive — the presenter carries every message both ways

  4. In React's unidirectional data flow, how does a click on a deeply nested button update what the user sees?

    • The button edits its sibling components directly, in place
    • It calls a handler that updates state; new state flows down as props and re-renders the UI
    • The click travels straight to the database and back again
    • The view observes the model and redraws itself on change

  5. The lesson says React favors "LEGO, not woodcarving." What does that mean?

    • React apps must be prototyped with physical toys first
    • React is slower to build with than plain JavaScript
    • Compose small components instead of inheriting from big ones
    • Every React component is required to use inheritance

Go deeper

Want to keep pulling this thread? These talks and tutorials go further than we did here:

Sources & further reading