In 1979, at Xerox PARC, Trygve Reenskaug invented MVC for Smalltalk desktop applications. The idea was genuinely elegant: the Model holds state, the View renders it, and the Controller mediates user input. When the Model changes, it notifies the View through the Observer pattern. The View updates automatically. Everything lives in memory, everything observes everything else. A persistent, circular, synchronous architecture.
It worked beautifully. It was also designed for a world in which the Model, the View, and the Controller all inhabit the same process, on the same machine, for the entire lifetime of the application.
Then, in 2005, Ruby on Rails arrived and borrowed the terminology for the web.
One small problem: the web works rather differently.
The Mechanism That Isn't
A web request arrives. The server loads data from a database. This is called the Model. It renders HTML. This is called the View. A routing function dispatches the work. This is called the Controller. The response is sent. Then everything is destroyed. Model: gone. View: gone. Controller: gone.
There is no Observer pattern. Nothing observes anything, because there is nothing left alive to do the observing. The "circular" architecture that made Reenskaug's design so elegant is, on the web, a straight line ending in disposal.
We kept the names. We lost the mechanism.
The Inheritance of Inconvenience
What followed from this terminological loan was rather predictable. The circular architecture promised by the names never materialised, because it cannot materialise on the web. So developers started patching the gap between promise and reality:
■ "Controllers are too fat." Move logic into services.
■ "Models are too fat." Add Service Objects.
■ "Services are too many." Add Repositories.
■ "Still messy." Adopt
Clean Architecture.
Each layer attempts to fix the layer above it. The result, in a non-trivial application, is a filing system for code that knows precisely where everything lives but has rather lost track of what anything does. Seventeen files for a counter. Marvellous.
What MVC Actually Gives You on the Web
Let us be precise about this. The benefit of web MVC is not architectural. It is familiarity. Tutorials teach it. Bootcamps drill it. Stack Overflow assumes it. Job postings require it. These are real advantages, in the same way that driving on the left is a real advantage if you happen to live in Britain. It is convention, not physics.
The pattern does not map to what the web actually does. It maps to what the web would do if it were a Smalltalk desktop application running in a single process on a Xerox Alto. It is not. It has not been for some time.
What the Web Actually Does
The web is linear. It always has been. An event arrives: an HTTP request, a WebSocket message, a scheduled task. Something processes that event: reads from a database, applies business rules, computes a result. A value returns: HTML, JSON, a redirect, an error. Done. No cycle. No persistent observers. No circular notification chains.
I have been building web applications this way for over a decade. Recently, I gave the pattern a name, mostly so I could stop explaining the same thing in every architecture review: LEAT: Linear Event-Actor-Turnback.
Event: something happens. Actor: something processes it. Turnback: a value comes back. That is what the web does. LEAT is not a framework or a product. It is a description. An honest one.
The Distinction Worth Making
None of this is an argument against MVC itself. Reenskaug's design remains brilliant for what it was designed for. In a desktop application, a mobile app, a game engine, or any context where objects persist in memory and observe each other's state, MVC is precisely the right tool. It solved a genuine problem, and it solved it well.
The error was not in inventing MVC. The error was in copying the terminology to a context where the mechanism cannot follow. We kept the names, built an industry of workarounds around the mismatch, and then blamed the developers when the workarounds needed workarounds of their own.
The web was already linear. It did not need to be taught circularity and then disciplined for failing at it.
Patterns travel well when they travel with their mechanisms. Stripped of the Observer, stripped of persistence, stripped of the circular notification chain, MVC on the web is three folders and a habit. If that is all it takes to make a team productive, fair enough. But let us at least be honest about what we are doing, and stop pretending the architecture is something the protocol never supported.