The evolution of browsers into powerful platforms is inspiring developers to write richer and more complex applications. The downside to this is of course that as the code becomes more complicated, problems like code maintenance or resolving new bugs begin to appear.
What is a modular application?
It is an application divided into several modules that are loosely coupled together, which can be integrated into a more complex application; now, there are many different approaches and patterns that can provide developers with an easy way to organize their code and build a modular application. One of the most popular is the MVC pattern.
What is MVC?
MVC stands for Model-View-Controller and essentially splits your application into 3 parts:
- The Model is where the data stands; if the model changes it notifies the view to update itself,
- The View is what users see. It observes the model and presents to the user the information with which they can interact (clicking) – but the view is not too smart and it doesn’t know what to do so it notifies the controller that an event (a click) occurred,
- The Controller is the logical part of the application. When the Controller takes notice of an event it changes the Model accordingly, change which ends up influencing the View and so on.
Traditionally, a web application stores the data in to the DOM (Document Object Model), which is a bad idea because it doesn’t respect the DRY (Don’t repeat yourself) principle. Let me give you an example of why you should use a Model to store you data: suppose you have a web application which has different parts that should have the same data; when the user makes an action and you update one of them you also have to remember to update all the related parts properly – the problem with this kind of approach is not only to make sure you will remember which parts should be updated, but also to make sure you don’t forget any.
A View in Backbone JS is typically a visual representation of the data stored in Models. Everything that is displayed in a page can be considered a View, even the whole page itself could be a View that contains other Views. In this way Backbone encourages developers to abstract the DOM manipulations into Views and to use events to change the Models.
The Controller in the Backbone terminology is called a Router because it lets you save the state of the application using hashbang URL. To better understand this concept I will give a known example: the Gmail application – after you first log in you will see a list of emails that you can read or delete, you can go to sent section or compose a new email and all of this happens in the background because the page isn’t refreshed and there is no need for a new page to be rendered.
To build a Gmail application with Backbone JS we can use a Model to store the emails (subject, from, content), which Model is used by a View to display the emails to the user. The View will listen for events (for example the user can delete one of the emails) and update the Model which in turn will refresh the View. Now, when the user switches between reading an email and viewing the inbox folder and then refreshes the page, the user will expect to see the inbox folder and not the content of an email the user just read – this behavior is called preserving application state and can be easily implemented with Backbone Routers.
In conclusion Backbone JS and Require JS are amazing resources that can save an imaginative developer’s time and effort while also providing the end user with a great experience.