I haven't seen the F8 session or used Flux. I've just vaguely skimmed some of the reddit comments. Howeverâ¦
Once upon a time, there was this thing called the Model View Controller architecture. It was a product of the Smalltalk community, but then so were Design Patterns and Extreme Programming. At its heart, it was the simple idea that Model classes should be responsible for representing the state of your application, View classes should be responsible for drawing your user interfaces and presenting that state to your users, and Controller classes should be for translating actions performed by your user into changes to your model, that were then reflected in your view.
Then, twenty years after MVC was introduced to the Smalltalk world, along came the Model 2 Web Application. In an attempt to make Java web development fit into the growing J2EE spec, the Java community seized on MVC and mapped it almost arbitrarily to the web. Every HTTP request would be served by a single controller (servlet), which would collaborate with zero-to-many models (EJBs), and map the resulting data into a DTO (Pay no attention to the man behind the curtain!) that could be passed via RequestDispatcher to a single JSP view.
The sleight-of-hand was the assumptionâbaked into the servlet specâthat each HTTP request would map to a single controller which would delegate to a single view. A few frameworks like Tapestry tried to buck the trend, but a Java developer years later could literally replace servlets with actions, EJBs with dependency-injected beans and JSPs with the templating language du jour, and still deliver a not-unreasonable technology choice in most circles. This malaise even infected other undeserving languages like Ruby.
The problem is that even in a very simple web application, a single page contains elements that by rights should be the responsibility of different views, backed by different controllers and their own models. The single controller-per-request, or even the primary controller-per-request is a broken paradigm, and one that every developer has come up with some sub-optimal tower of contraptions to compensate for.
As a result, your average non-trivial Java web application ended up being a mess of controller implementation inheritence, servlet filters, interceptor stacks, view decorators and arbitrary objects placed in the template engine's context to allow the drawing of all the bits of the web page that don't belong to the increasingly impure controller.
Amusingly, the "Type 2" approach to web MVC isn't a bad fit for REST-based systems, (because a REST resource usually does have a single responsibility), but most pure REST systems figure it's overkillâ¦ because a REST resource just has a single responsibility.
A simple inversion fixes so much. Going back to the GUI paradigm and flipping the process around so the view comes first and then delegates to controllers and models as necessary is already the go-to strategy for single-page applications and frameworks like Backbone. This kind of "view first" is also a perfectly good strategy for server-side page generation, one that large distributed systems have been taking advantage of for years to delegate fragments of page generation to independent external services.
This blog post was brought to you by the Society for Sending Charles Back In Time Fourteen Years To Slap Himself.
If your implementation of MVC does not scale then I'm afraid that it's your implementation which is faulty and not the MVC pattern itself.
I have been developing web applications using MVC for over a decade, and I have never had any problems. My implementation is very simple:
1) I don't use a front controller, every page has its own component script. 2) Every page use a single controller and a single view. Most controllers use the HTML view while some use the PDF or CSV view. 3) Each controller accesses as many model objects as there are zones (data areas) on the page.
The idea that I would need a separate view for each widget on an HTML page just strikes me as counter-intuitive and totally ridiculous.
There is no rule that says a controller can only access a single model, so I don't follow that rule.
The single biggest factor that prevents your application from scaling is the number of class files it has to load and instantiate in order to complete its task. By having a single Controller, a single View and the minimum number of Models I have reduced the overheads to the absolute minimum. Compare this with some of todays popular web frameworks which require 100 classes just to paint the index page! How ridiculous is that?