Lean Web ■ Part 3
The myth goes like this: every web application needs Model-View-Controller architecture. It is the industry standard.
Let us examine what that standard actually standardises.
The Origin
Trygve Reenskaug invented MVC in 1979 at Xerox PARC. For Smalltalk. For desktop GUIs with persistent state, continuous user interaction, and event-driven workflows. The Model held application data in memory. The View rendered it continuously. The Controller handled user input events in real time.
The web request/response cycle has precisely none of these characteristics.
The Mismatch
HTTP is stateless. A request arrives, processing occurs, a response leaves. There is no persistent controller. No event loop between requests. No state that survives the connection closing.
The web flow is simple: Request, Process, Response. Done. Connection closes. What MVC adds to this is a tour through Router, Controller, Service, Repository, Model, View, and back to Response. Every layer is a function call. Every function call is latency. Every abstraction is a place where bugs hide.
What MVC Actually Costs
Thirty per cent or more in performance overhead from abstraction layers that serve no purpose in HTTP. Stack traces that meander through controllers, services, repositories, and factories before arriving at the line that matters. "Separation of concerns" that separates nothing: your controller is a router, your model is a query wrapper, your view is a template engine. Three names for three things that were already separate.
Why It Stuck
Follow the incentives. Certifications. Training programmes. Consulting hours. Complex software locks customers in more effectively than simple solutions ever could. Ruby on Rails popularised MVC for the web in 2004. Django followed in 2005. Laravel in 2011. Each framework adopted the terminology, and the industry adopted the frameworks. The pattern became a prerequisite rather than a choice.
But should that be your premise as a customer? Clearly: no.
The Question Nobody Asks
Not every website is an application. The majority of "web apps" are content pages with a few interactive elements. For those, three abstraction layers are three too many.
The question should not be "which MVC framework?" but "do I need an architecture at all?"
The leanest architecture is the one with the fewest layers between request and response. The best and fastest architecture is the one you do not need to explain.