This is the first post in backbone.js series which aims at looking at the overview of what is backbone. In this series we will look at various backbone aspects like the Models, Views, Collections, Eventing system, Event aggregator and its uses. And I do promises that by the end of the series you will be able to make decision of when to use backbone.js.
What is backbone.js?
From backbone.js home page, it is described as giving structure to web applications by providing models with key-value binding and custom events, collections with rich API of enumerable functions, Views with declaritive event handling and connects it all to you existing API over a RESTful json interface.
The big and best differences between a library and a framework a library is something you call from your program. A framework is something that calls into your program, or better frameworks sort of control how you design your code or applications. They specify what you can do with them and how to do it. On the other hand libraries provide with some useful features and then you can move on and implement or even extend them to build your application. Frameworks contain key distinguishing features that separate them from normal libraries like inversion of control. In a framework, unlike in libraries or normal user applications, the overall program’s flow of control is not dictated by the caller, but by the framework.
There has been conflicting opinion of whether backbone is MVC or not, a library or a framework etc. But I would like to take sometime to simply look at what MVC is.
What is MVC?
In short MVC stands for Model-View-Controller.
View -visual representation of the model. The view is dependent on the model and in case the model changes then the view should update accordingly. The user usually interacts with the view setting and changing the view thence the model. In most cases or ideal scenario it not the work of the view to update the model but the controller. e.g when a click occurs the information should be taken to the controllers to update the model accordingly.
Controller-controls the co-rodination of the views and the model. They are the mediators between the models and the views. They update the views when the model changes and update the models when any changes occurs on the view.
And therefore in respect to backbone, truly and distinctly it has model and views, but does not have true controllers since its views and routers sort of act similar to controller but neither of them can act as a controller on its own. And this on my own opinion does not qualify backbone a mvc framework and I consider it a member of MV* family with its own implementation.
Backbone had its own Backbone.Controller which was not making sense in the context in which it was used and therefore it was renamed to Backbone.Router. And therefore backbone shares the responsibility of a controllers with the view and the router.Router handle little more of the controller work as you can bind the events and the models and any other customizations you may like regarding the same.
Some few points to note regarding backbone for this post is:
- Backbone core components are Model, View, Collection and Router. Therefore I would not be wrong saying it has borrowed from MVC from framework.
- You have more control of what is happening.Backbone has one of the best eventing system which is great between the views and models. You can even attach an event to any attribute in a model and you will be notified when the property changes.
- Supports data bindings through manual events
- Great support for RESTful interfaces and so models can easily be tied to the backend API’s like ASP NET WEB API.
- It uses underscore.js templating engine which is great.
- Clear and flexible conventions for structuring applications. Its not opinionated, and so does not force you to use all of its components and can only work with only those needed.
Feel free to engage me in discussion, questions, recommendations or even you input. There are more to come on specific backbone intrinsics.
Happy coding 🙂