BackBone Tutorial – Part 1: Introduction to Backbone.Js

Introduction

In this article, we will try to look at the basics of JavaScript frameworks and try to introduce backbone.js.

Background

Link to complete series:

1. BackBone Tutorial – Part 1: Introduction to Backbone.Js[^]
2. BackBone Tutorial – Part 2: Understanding the basics of Backbone Models[^]
3. BackBone Tutorial – Part 3: More about Backbone Models[^]
4. BackBone Tutorial – Part 4: CRUD Operations on BackboneJs Models using HTTP REST Service[^]
5. BackBone Tutorial – Part 5: Understanding Backbone.js Collections[^]
6. BackBone Tutorial – Part 6: Understanding Backbone.js Views[^]
7. BackBone Tutorial – Part 7: Understanding Backbone.js Routes and History[^]
8. BackBone Tutorial – Part 8: Understanding Backbone.js Events[^]

It was a long time ago (almost a decade back) when most software applications were getting built as standalone applications. These applications were targeted at a single user and ran on their operating systems. Then came the need to share data across multiple users and a need to store data at a central location. This need gave birth to distributed applications and web applications. Distributed applications ran as standalone applications on the user’s machine giving him a rich user interface (desktop like experience) to work with, and behind the scenes, these applications sent data to a server. Web applications, on the contrary, were sandboxed in a web browser and HTML and HTTP were used to let the user perform operations on the data which is stored on the remote server.

The major differentiating factor for these two applications was that the distributed applications provided an interactive user experience whereas web applications provided very limited features (due to technology limitations). The downside of distributed applications was that it was very difficult to roll-out and ensure the application updated across all users. Web applications had no such problems because once the application is updated on the server, all users got the updated applications.

Both these approaches had pros and cons and something needed to be done to get the best of both worlds. This is where browser plugin based applications like Flash applications and Silverlight applications came into picture. These technologies filled in the gap for all the functionality not possible with HTML. They provided the possibility of creating rich internet applications that ran in the browser. The only downside of this was that the user needed to install the browser plug-in to get these applications to work.

Then came the time when browsers became more capable and HTML became more mature. Creating a rich internet application became possible only using browser based client side technologies. This led developers to write client side code using HTML and JavaScript to create rich internet applications. No need for plugins like Flash and Silverlight. But since HTML and JavaScript were never meant to be used for writing full fledged web applications, these applications had all the HTML and JavaScript code intermingled. This led to spaghetti code and these client side HTML/JavaScript applications (Single Page Applications or SPAs) became a maintenance nightmare.

So why should we write single page apps when they lead to bad code? The main reason for wanting to create a single page application is that they allow us to create a more native-like/desktop-like/device-like application experience to the user. So the need was to create SPAs in a structured manner and this created a need for JavaScript frameworks and libraries that provided some structure to single page applications.

Currently, there are quite a few Open Source JavaScript frameworks available that help us solve the problem of spaghetti code. These frameworks let us design our applications in a structured manner.

Separation of Concerns and MVC

One of the best things about a good application architecture is the Separation of Concerns (SoC). The best part of the Backbone Marionette framework is the ability to provide this separation of concerns using the MVC pattern. The Model will represent the business objects needed to implement the solution. The view is the part that is visible to the user. The user can simply consume the data using views or act upon the data, i.e., CRUD operations. The controller is the one that provides the mechanism for interaction between models and views. The controller’s responsibility is to react on the user’s input and orchestrate the application by updating the models and views. The Models and Views remain loosely coupled, i.e., the Models don’t know anything about the View and the View has a Model object (association) to extract information and display it to the user.

What is BackBone.js

Backbone.js is a lightweight framework that lets us create single page applications in a structured manner. It is based on the Model-View-Controller (MV*) pattern. It is best suited for creating single page applications using a RESTful service for persisting data.

Now one might wonder what is this MV*. we have talked about the MVC architecture at length and then we are saying that backbone is a MV* framework. Well the reason for this is that backbone does not want to enforce the use of controllers. Applications can choose to hook their own code to be used as controllers, use some plugin that can provide a controller or perhaps use MVVM pattern instead of MVC pattern.

What will Backbone Provide

Model

Every application needs some way of organizing their data structures. Backbone will provide us with the possibility of creating Models to manage all our entities. Backbone models by default provide the ways to persist themselves. The persistence can be on a localStorage or even on a server via a restful API. These models also provide ways to validate the data in the model before persisting it.

Collections

Collections are simply a group of models together. Backbone also provides the possibility of creating the ordered set of models, i.e., collections.

Views

The major problem in JavaScript applications is to handle the UI elements on views. Listening to their events and changing their values based on the data received. Backbone eases up this problem by providing an abstraction over the HTML elements, i.e., views. Backbone view are like observers on some HTML. We can define the HTML and associate with a view. The view will then take care of handing the events of these HTML elements and populating and rendering these views based on data. The HTML is totally separate from the view object. It can be associated with the view object either directly or via some templating engine (hang on tight, we will get to see all these in action in due course of time).

Routers

Even though we want to create a single page web application, requirements might dictate the need of copying, bookmarking the URLs. So for a single page application, if we want the URL to determine the view/views to be rendered, routers are very helpful. routers will look at the requested URL and then execute code based on the requested URL and then render the view to the user.

Why This Article Series

So the idea behind writing this tutorial series is to understand backbone.js framework in a step by step manner by looking at small chunks of features. This article is mainly to get the user acquainted with the backbone.js framework features. From the next article, we will dig deeper and start looking at the backbone framework in detail. Later, we will create a complete application to understand all these concepts.

In the very later stages, we will look at Marionette.js plugin. This plugin makes it much more easier to create backbone applications. Also from the architectural perspective, backbone.js + Marionette.js application are even better structured than backbone.js applications. We will then create a complete application to see the backbone marionette in action.

So just sit tight and start enjoying this backbone journey with me.