Building a web application today isn’t nearly as hard as it was couple of years ago. Back then creating a rich client application using HTML and JS was possible but the number of options you had is a fraction of what is available today. The first SPAI helped building was relatively simple project –built with ExtJs library when it was still in version 2. There were of course other options like dojo but with our team’s little experience in web technology ExtJs seemed like a better choice solely because of its superior support. Shortly after I worked on another web application built with Web Forms and jQuery. We finished both projects, they worked on most browsers but we didn’t avoid creating a mess in JavaScript. Presentation logic was mixed with business rules scattered through event handlers inside unstructured components source code. Just to be fair it definitely was not caused by the frameworks we used but because of our lack of knowledge and experience. I guess that happened to lots of developers and wise people soon enough realized that there has to be a better way of doing things. I think that this was the main reason of the explosion of JS libraries/frameworks options that aim to help structuring client side code.
MVC, MVP, MVVM or …
The number of libraries and frameworks available is overwhelming. AngularJS, Backbone.js, Ember, JavaScriptMVC, Knockout or Sammy.js are just a few I had a chance to look at from the outstanding list. You can even compare how to built simple TODO application with them. Addy Osmani wrote an excellent article that really helps making your choice sane. Most if not all of those frameworks utilize one or more of MV* patterns. An important thing to remember though is that Model View Controller is more an architectural pattern for presentation than an code design pattern like Builder. It means it does not provide very concrete implementation template but rather a guidance for objects/modules/roles relationships. Similar observations apply to MVC cousins namely Model View ViewModel or Presentation Model and Model View Presenter. This can cause some confusion for someone already familiar with MVC pattern in Asp.net mvc, Fubu or Rails. I always try to find a framework/library author’s explanation of how they applied above patterns – it really helps understanding core concepts of their work.Library or Framework
Some of the tools are called frameworks while other libraries. But what’s the difference anyway? A very common and brief explanation is the one provided by Martin Fowler inside Inversion of Control article:Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client. A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your codeat these points.There are various ways you can plug your code in to be called.Of course the distinction is not always firm and clear. Still, it is important to keep in mind while choosing the righttool for a job. A library will usually give you more control inside infrastructure code but it often requires more work to unify boilerplate gluing code and requires some degree of experience. A framework on the other hand will typically provide you with a setup where you can hook your code hopefully focused mostly on the valuable functional stuff. A framework will limit your freedom to some extent in turn it will eliminate some part of work that you presumably would have to do in order to keep your design clean.