The period 2012-2013 has seen a major surge in HTML5 Technologies especially the JS Frameworks. All of these can be categorized into MV* patterns. The reason for the sudden rise in popularity for JS frameworks largely goes to the fact that numerous smart-phones are now available with literally any resolution and sizes and websites and applications are forced to adapt quickly or fall apart. As the User Experience plays an important role than ever before, one page websites became the future replacing PHP powered websites to use PHP just for back-end purpose.
What Is MVC, Or Rather MV*?
These modern frameworks provide developers an easy path to organizing their code using variations of a pattern known as MVC (Model-View-Controller). MVC separates the concerns in an application down into three parts:
- Models represent the domain-specific knowledge and data in an application. Think of this as being a ‘type’ of data you can model — like a User, Photo or Note. Models should notify anyone observing them about their current state (e.g Views).
- Views are typically considered the User-interface in an application (e.g your markup and templates), but don’t have to be. They should know about the existence of Models in order to observe them, but don’t directly communicate with them.
- Controllers handle the input (e.g clicks, user actions) in an application and Views can be considered as handling the output. When a Controller updates the state of a model (such as editing the caption on a Photo), it doesn’t directly tell the View. This is what the observing nature of the View and Model relationship is for.
MV*-architecture is not a kind of fashion, or killer-feature, or something that could be thrown out. It is a pragmatical way to organize rich UI-applications to tackle complexity of the modern programs.
Why use Modular Pattern?
- Not everyone structures code by default. Frameworks enforce structure to some extent. This extent is variable based on how much scaffolding they provide. Too much scaffolding usually translates to steeper learning curve.
- Frameworks generally encapsulate design/programming patterns from the collective experience of a larger community, so in some cases there will already be structure in there, while you will build and re-factor.
- Mostly developers will come and go, using popular/standard frameworks makes it easier for developers other than the original developer to understand the structure. Good frameworks are well documented and have active communities to be able to ask for help.
- As you move from project, you most likely copy/paste code from previous project that you now require in a new project. In case you use a framework even if its your own MV* framework, you just import and include this framework each time.
- It tends to be heavy weight for implementing. Where you could have gotten away with 1 class, you’ll now have three. On smaller projects, you’re right to question the benefits of MVC.
- It can be frustrating to stay within the structure of MVC. There’s always the temptation to let Controller code bleed into the View, or let the View directly access the Model. After you write your umpteenth wrapper function, you’ll wonder why you’re doing it.
- MVC presumes your app will live forever and will change technologies. If you never change the UI, the data source, or the business logic then you kind of wasted your time in encapsulating those layers in anticipation of change.
Framework or just a Library?
The Key components for an Angular.js powered application will be :
- Template : An Angular template is the declarative specification that, along with information from the model and controller, becomes the rendered view that a user sees in the browser. It is the static DOM, containing HTML, CSS, and angular-specific elements and angular-specific element attributes. The Angular elements and attributes direct angular to add behavior and transform the template DOM into the dynamic view DOM.
- Directives : At a high level, directives are markers on a DOM element (such as an attribute, element name, or CSS class) that tell AngularJS’s HTML compiler to attach a specified behavior to that DOM element or even transform the DOM element and its children. Angular comes with a set of these directives built-in, like ngBind, ngModel, and ngView. Much like you create controllers and services, you can create your own directives for Angular to use. When Angular bootstraps your application, the HTML compiler traverses the DOM matching directives against the DOM elements.
- Model : A model notifies its associated views and controllers when there has been a change in its state. This notification allows the views to produce updated output, and the controllers to change the available set of commands. A passive implementation of MVC omits these notifications, because the application does not require them or the software platform does not support them.
- Scope : A root scope can be retrieved using the $rootScope key from the $injector. Child scopes are created using the $new() method. (Most scopes are created automatically when compiled HTML template is executed.)
- Collections – Collections are ordered sets of models. You can bind “change” events to be notified when any model in the collection has been modified, listen for “add” and “remove” events, fetch the collection from the server, and use a full suite of Underscore.js methods. Any event that is triggered on a model in a collection will also be triggered on the collection directly, for convenience. This allows you to listen for changes to specific attributes in any model in a collection.
- Events – Events is a module that can be mixed in to any object, giving the object the ability to bind and trigger custom named events. Events do not have to be declared before they are bound, and may take passed arguments.
Knockout includes the following features:
- Declarative bindings – a simple and obvious way to connect parts of your UI to your data model. You can construct a complex dynamic UIs easily using arbitrarily nested binding contexts.
- Automatic UI refresh (when the data model’s state changes, the UI updates automatically) – automatically updates the right parts of your UI whenever your data model changes.
- Templating (using a native template engine although other templating engines can be used, such as jquery.tmpl)
Main concepts are :
- Models : All the database connections and synching with view happens here.
- Router : Routers are used to query the model, from their model hook, to make it available in the controller and in the template.
- Controllers : Controllers makes the bridge between the model and the view or template.
- Views : Views represent particular parts of your application (the visual parts that the user can see in the browser). A View is associated with a Controller, a Handlebars template and a Route.
- Component : A Component is a completely isolated View that has no access to the surrounding context.
- Templates : A template is the view’s HTML markup.
- Helpers : Handlebars helpers are functions that modify data before it is rendered on the screen.
Basically all the above mentioned framework/library is suited according to the requirement. Like if you want a light weight application with constant database updation and client side logic, then one should opt for backbone.js and if you have a very large application which is maintained by a lot of developers, then Angular.js will be the best solution. Learn one and the others would be much easier to grasp. And stick to the one that you feel is good for your method of development.
Hope you liked it. Thanks for reading. Cheers.