To MVC or Not to MVC? (frontend of course)

Why do I say "of course"? Well backend MVC has been going on for a long time and as far as I'm concerned its just an obvious way to program a website (but that's a topic for a backend article). The new hype in the web world are these frontend MVC's. JQuery adopted frontend templating and others started to build whole libraries for handling heavy frontend applications. Ember.js , backbone.js and now google has gotten into the game with their Angular platform.

What is really the root of this new Web 3.14579... buzz word is that the industry wants the client to do more. There is a nice little slide show planBox did here that displays the reasons they decided to go the frontend MVC route.

Two Benefits to Frontend MVC

• Talent Resource If you have a big business you want interchangeable parts ... frontend MVC allows more separation of frontend and backend needs/personnel,allowing the company to allocate resources more specifically/efficiently
• Dynamic Interface You really need your application to do a lot in the frontend and fast. You do so much rendering and dynamic functionality on the frontend that you might as well just push the data there (json ajax) and reuse the functions that are required to render the page in its multiple states.

Dynamic Interfaces

Here is an example that might benefit from the use of a frontend MVC:

You have a list or groceries. You submit the form and it updates the database, selects the grocery list and refreshes the page. Now you decide to add ajax to the process. Now you submit the form, a response is retrieved and you update the markup with an extra row. To reduce bandwidth costs you send json data and have your markup generated by a javascript function. So this is where your frontend MVC comes in and says, "Hey Mr developer dude, you already have this javascript function for your ajax. Why not just use it for all list rendering?" So all you do is alter your javascript markup template (if you're going to do something like this you really want to use a js templating system) and the list rendering will be the same for first page load and any ajax calls after. Now your server just sends data and json to the javascript instead of markup with every ajax call.

With frontend MVCs you also get a lot of other features like dependency injection and routing. These should be used if your markup can differ greatly in functionality or if you have a diverse set of views for your application.

THIS IS NOT THE HOLY GRAIL OF WEB DEVELOPMENT

Its just another tool in a web developers arsenal. There are times where frontend MVC is good other times where you are actually sending more bytes just because you are adding a frontend MVC library to your page. Decoupling frontend and backend teams can be done for about 80 out of 100 programers, but you will need that 20 that know both environments (80/20 rule???). You will need them to decide how quick changes are implemented, how to easily mitigate security risk (which is usually a miscommunication involving frontend and backend technologies) and it is helpful to have people that know when problems arise when frontend and backend standards are not the same across all technologies.

Its good to specialize, this is what basic economics is all about. But when there is an error in the system you need someone that understands the whole picture. I don't think that the idea of the frontend MVC is anti-fullstack programmer its just another tool to use by any programmer. It does allow for easier separation of my frontend and backend needs, but as with any tool its only as good as the person that uses it.

When NOT to use Frontend MVCs

• simple pages There is not any (or alot) ajax/event binding on the page, no need to upload all that javascript.
• lack of diversity if a page does something complex but only that one thing (a game for instance) you might not benefit from the routing system or the dependency injection of a frontend MVC. It might better and quicker to just load up jquery ui and make a simple javascript object to hold various states of the page.
• talent resources You have 25 php developers and 4 javascript programmers working on your custom game/social site and you need them to be focusing on the game engine not how to make the account page more ajaxy. Trying to separate your frontend and backend too much might cause your once highly agile/well rounded team to perform less efficient than they to be because you specialized your code base away from your resources.