JavaScript MVC

by Jonathan Snook

26 Reader Comments

Back to the Article
  1. I’m glad you are publishing more technical articles and less fluffy ones. Still not convinced MVC is the way to go for Javascript RIA.

    It would be nice if one could port some an Actionscript framework (PureMVC springs to mind) to Javascript, but I doubt that would be worth it, or even feasible.

    Copy & paste the code below to embed this comment.
  2. Interesting article, I wasn’t aware of people trying to implement MVC into front-end code. I’d guess it’s coming from the .net boys trying to cope with javascritped business logic.

    I’m not sure what you’ve described is actually MVC. You’re mixing templates into the javascript and using AJAX to pull data. Also, there’s that whole issue of application behaviour code supplying business logic to the entire application through things like validation routines. It’s the job of the back-end controller to define relationships not the ‘view’ behaviour code.

    A much better approach would be to add the elements <div id=“database” ></div id=“templates” ></div> and have your behaviour logic read the content of those elements to control client event handling. Let’s look at an example you describe concerning the preloading of a calendar. You load your special event days into the ‘database’ as a table for those months prior and ahead of what is displayed. You might call this client-side database normalisation. Your controller can then read the recieve the next click event, the model can retrieve the special event days and the view fetches and builds the template which is inserted as a widget by the controller.

    For brevity. This is more like what the setup of MVC validation messages, as you’ve described, should look like on the page:

    </div id=“templates” >
    {loop varMessageData as Data}

    </div id=“database” >
    <table name=“error_messages”>
    <td>1</td><td>Your email address is invalid</td><td>warning required</td>

    <table name=“validation_requirements”>

    In any event I still think that MVC for web application development is a collective madness which we’ll all look back on in ten years time and have a good laugh. MVC doesn’t clearly define ORM as an inherant part of the pattern, which, makes CMS development obtuse at best.

    Copy & paste the code below to embed this comment.
  3. @waffle: doing view rendering on the server is definitely a valid approach. However, the tradeoff for me is how much time/bandwidth do you sacrifice in doing so. If you’re rendering a complete calendar of events for each month, it’s almost pointless to do it via Ajax—especially if there aren’t any events within a particular month. I prefer pulling in just a JSON request because it’s smaller. Storing that information client side then becomes part of the model (essentially, keeping track of state and syncing with the server).

    Are we going to look back to server development 10 years from now and all laugh about having used MVC? With the increasing complexity of client-side apps (not only on the web but also in desktop apps like AIR and Titanium), it seems like a natural choice.

    Copy & paste the code below to embed this comment.
  4. I tend to agree with Eddroid. MVC isn’t new and the fact that it has survived decades for many similar discussions such as this to be taking place today gives everyone something to think about, especially its detractors.

    Even if I’m doing a small dirty project, I still find more merits doing it right. MVC patterns for smaller projects isn’t going to give you that much more overhead in any case. Backtracking your codes a year later won’t make much of a difference in a small project whether its done with MVC or not. But it does make a difference when you are working with a team. Your project may need to spin off to something larger, or open-source, etc from the same code base. Then I’d think your MVC foundation would do you justice.

    I’d rather not be caught realizing this a year later into development.

    Essentially, I look at the quest of applying MVC patterns for javascript/ajax more than just for goodness’ sake, but a case of developing healthy coding habits, seeing and thinking right. A cause with more benefits than not, most certainly.

    On the server side, I like codeigniter for its loosely coupled design which gives developers more flexibility. I could stray from convention where necessary. Likewise, I think in browser MVC, we should also find that balance.

    It isn’t too difficult to consume a fish without swallowing its bones. Great article Jonathan!

    Copy & paste the code below to embed this comment.
  5. There are other patterns to separate concerns. MVP, Humble Dialog, and even Presenter First.

    For me the separation helps because I test first then write my code. When I need to refactor, adding new behavior to my app, separation is what I need.

    Use of JavaScript is to give a more responsive experience the user. An example of this would be if you wanted to display some markers on a google map. The addresses are stored on your server. The addresses have no geocoding. User requests data from server. Client requests geocoding from a geocoding service. Display markers on google map. The other way would be my server having to request geocoding. then sending data to client.

    OBTW why not have the address be behind somebody else’s API. So now all my server has to serve up is HTM, JavaScript, and CSS. Let the client pay for the bandwidth.

    Now my business costs go way down. My programmers (me) don’t have to invest in backend software maintenance costs. Learning PHP, Python, Ruby, DOTNET, only so far as needing to know how to get a server up and running.

    Hmmm…. wonder if you could write a mongrel-like server in JavaScript. Just embed SpiderMonkey.

    Copy & paste the code below to embed this comment.
  6. MVC was first put in practice in the development of the Smalltalk GUI. The latest work by the same team is the Squeak language and environment. Squeak has a GUI toolkit named Morphic which is not strictly MVC because after 30 years of trying they concluded it is just not worthwhile to separate the view from the controller, as the two are naturally very interdepedent. So for GUIs and client-side web programming the way to go is M/VC: split the model from the rest, and be happy.

    Copy & paste the code below to embed this comment.