MVC, or Model-View-Controller, is an old concept that has gained traction in the developer community in the last few years. The idea is instead of writing spaghetti, follow a general separation of duties, where one element defines the data (the Model), one presents the data (the View), and one logic store interacts with the user, the view, and the model (the Controller).

And the way all the JavaScript frameworks are implementing it, MVC sucks.

I’ve recently been evaluating all the JavaScript frameworks, toolkits, and libraries that I can find.

To digress for a moment: I find many people confuse these three concepts, here is my differentiation.
  • A library is a collection of routines that make part of your life easier when you want it. These days jQuery is the most famous. Note I’m referring to jQuery itself, not all the add-ons; some add-ons are dependent libraries, some are toolkits.
  • A toolkit is a far more extensive collection that you can use to build you application. This usually includes frame controls, UI controls, and typically it is built upon consistent libraries that make it feel complete and cohesive.
  • A framework takes it to the next level, and is a fairly rigid structure that you program within. Unlike a toolkit or simple library, to use the framework all your code must confirm to the framework specs. It also requires a much more substantial investment in time to learn since you can’t pick-and-choose when to use it, but the long term payoff is usually huge.

Looking at the frameworks out there you find that a page consists of a model .js file, a controller .js file, and a view .js file. Actually models and controllers can be shared across views, and there are ajax or json server side services for CRUD ops, a bootstrapping html page, various css, etc, but for now just focus on these three MVC .js files.

Let’s say you have a form to be filled in, say a state driver’s application. In the design phase through implementation, MVC serves you very well. But what happens when there are exceptions? What happens when a county decides that it needs a “Motor Voter” section added; is this a whole new page, or do we start adding in logic to control the situation. Sure the first time it is added you need to add some new flexibility into the database and the page, but you want the new variability to be added just once. Let’s say 50 different counties slowly sign on to the “Motor Voter” idea, each with their own tweaks. The developer quickly makes sure the database has a few localizable fields and code lists to handle the slightly variants, everything from field name changes to asking a couple more questions. So all 50 roughly match the base model, at least sufficiently so they all fit into the same generalized database table.

But since the MVC files are JavaScript, we could have a huge proliferation of at least models and views (perhaps not the controllers). This unfortunate situation takes a simple front end database update and creates a developer’s nightmare. The other alternative is to gut the model and view .js files, and create a complex routine to dynamically load the model and view JavaScript content based on the database configuration. This dynamic option assumes the MVC files are even tolerant to such fundamental changes after being loaded, which would also undermine all the inefficiencies programmed into the frameworks’ bootstrap processes.

If you want to dynamically change the page’s elements, not just the data, then the page itself needs to be generated by the server. This is antithetical to the MVC trend. Original web pages were written in C (not even C++) and were .cgi scripts, resulting in the server generating each html file, representing all the content. Later we started making static .css and .js files, and we used  scripting languages (.asp, .jsp, .php, etc). Now with the MVC trend we are trying to push not only the style but also the structure into fixed files, and just dynamically process the data, usually via JSON or AJAX calls.

My argument is that most large scale business apps require dynamically generated structure, not just dynamically fetched data. The MVC model in modern JavaScript frameworks sucks.

I’m disheartened to see how many are going this route. All the major commercial ones are committed (DHTMLX, Ext JS, SmartClient, Wakanda). Java-to-JavaScript compile-and-deploy technologies like GWT have the same problem, but even more baked into the architecture.  Even my old favorite Dojo Toolkit appears to be leaving it’s toolkit roots and joining the MVC framework trend with it’s impending 2.0 release. The one holdout toolkit I can see it YUI, which does support MVC objects, but does not impose a particular framework with specific file paths and names for the MVC .js files; in other words, with YUI you can put the MVC logic into the returned html file via your favorite scripting technology (for me it is a pass through .jsp page to on-the-fly generated code from Java).

The problem that caused the MVC trend was a lack of discipline on the part of the web developers who produce spaghetti code. MVC does force some sorely needed discipline on the wild west prototype language that is JavaScript. But until this problem of generated structure in MVC frameworks is solved via re-architecting the frameworks, I’m going to implement MVC the old fashioned way – a nice toolkit and proper discipline.

UPDATE 2013-01-09: I’ve discovered AngularJS (Thanks Chris!) and all my complaints have fallen away. See the part about “impedance” starting in the 3rd paragraph of the developer’s guide overview page. Long live MVC!