MVC and JavaScript Frameworks

In web application development, the Model-View-Controller (MVC) architectural pattern has become popular over the last several years. One of the more obvious advantages of using the MVC pattern is a separation of concerns... abstracting the data being displayed (Model) from the page layout (View), from the way that data is populated or manipulated or stored (Controller). For modern web development, this design pattern helps ensure larger applications are well-architected; the pattern leaves less room for tangential or nonsensical design choices. The reasons for choosing MVC over older ideas like web forms, traditional PHP or ASP.NET, or plain old HTML are obvious.

An even more modern question isn't whether or not to use MVC; it's whether or not the MVC code should be run client or server side. As computer technology has come along, it's become feasible for presentation work to happen on the home computer of any person browsing the web. JavaScript frameworks like AngularJS and Backbone have become more widely adopted; unlike Razor or Ruby on Rails which handle the bulk of the work on the back-end, on the server itself, these modern JavaScript frameworks do similar work as well, but only once they've been loaded onto the client's machine; by running on the browser and manipulating what HTML was sent initially.

I've built my career in Information Technology Management in Marietta, GA, and I've seen web standards evolve over time. Marietta computer consulting is no different than computer consulting anywhere else; being near a major city like Atlanta, there are a lot of opportunities to work with great IT talent in numerous different capacities. I know many companies with outstanding web development teams, and I know they built great web apps with a variety of different technologies. But the ones who have the fewest problems and spend the least time fixing bad design choices are using modern web MVC frameworks like Ruby on Rails and Razor. Even then, they often face a slightly different problem: server burden. If the server is doing all the work, the server is going to take much longer to complete requests. Any popular server getting lots of requests running server side MVC is bound to be bogging down... so of course, it's MVC we want, for its separation of concerns. But even better if we can give the server a rest and keep it open to take lots of requests... send over Javascript in the form of AngularJS or Backbone code with no need to process beforehand, and let the client's machine pick up the slack. It beats waiting for the server to finish processing everyone else's request before starting on yours.