HTML5 Zone is brought to you in partnership with:

Victor works on the Angular team at Google. He is interested in functional programming, the Web platform, and client-side applications. Being a language nerd he spends a lot of my time playing with Smalltalk, JS, Dart, Scala, Haskell, Clojure, Ruby, and Ioke. Victor is a DZone MVB and is not an employee of DZone and has posted 45 posts at DZone. You can read more from them at their website. View Full User Profile

Contrasting Backbone and Angular, Pt. 1

10.31.2013
| 7596 views |
  • submit to reddit
Contrasting ideas and tools is a great way to understand them better. In this series of articles I will go down the list of the things we have to deal with day to day when building web applications, and show how Backbone and Angular can help with each of them.

What We are Trying to Solve

Most of the things we do as web developers fall into one of the following categories:

  • Implementing business logic
  • Constructing the DOM
  • Implementing view logic (declarative and imperative)
  • Syncing up the model and view
  • Managing complex UI interactions
  • Managing state and routing
  • Creating and wiring up components

Not surprisingly most client-side frameworks address these in one way or another.

Backbone

Let’s start by looking at what Backbone gives us to solve these problems.

Business Logic Backbone Models and Collections
Constructing DOM Handlebars
Declarative View Logic Backbone Views
Imperative View Logic Backbone Views
Sync up Views and Models StickIt
Managing UI Interactions JS Objects or Marionette Controllers
Managing State and Routing Backbone.Router
Creating and Wiring Up Components Manually

For visual people:

Backbone Architecture

When I Say Backbone…

Comparing vanilla Backbone with Angular would not be fair. So by Backbone I actually mean Backbone + Marionette + plugins.

Business Logic

A large chunk of the business logic of the application goes into Backbone models and collections. Often these objects correspond to resources on the backend. On top of that, they are used for backing up views.

Constructing the DOM

Backbone uses template engines to construct the DOM. In theory, you can plug in any engine you want. In practice, though, Mustache and Handlebars are the ones that usually get used. As a result, templates in Backbone are often logicless and string-based, but they do not have to be.

View Logic

The idea of dividing the view logic into imperative and declarative is an old one (goes back to the original MVC pattern). Event handling configuration and data bindings are declarative. Event handling itself, on the other hand, is imperative. Backbone does not draw a strict line between the two. Both go into Backbone.View.

Syncing Up the Model and View

Due to the minimalist nature of Backbone, there is no built-in support for data bindings, but there are several plugins available (like Backbone.StickIt).

Managing Complex UI Interactions

All UI interactions can be split into simple (managed using the Observer Synchronization) and complex (where the Flow Synchronization is required).

As mentioned above, simple interactions get handled by Backbone.View using data bindings and event handlers. Some use Backbone.View to also handle complex interactions, but I recommend against doing that. Backbone.View already does too much. That is why I personally prefer using plain old JavaScript objects instead.

Managing State and Routing

Backbone comes with a very simple implementation of the router. It provides no support for managing view and the application state. Everything has to be done manually. That is why in practice most people prefer other libraries (e.g., router.js) over the built-in router.

Creating and Wiring up Components

In Backbone you get the freedom to create and wire up components in the way that fits your application best. The downside is the amount of boilerplate you have to write, in addition to the discipline required to keep the code well organized.

Angular

Now, let’s contrast it with how Angular approaches the same problems.

Business Logic JS objects
Constructing DOM Directives
Declarative View Logic Directives
Imperative View Logic Controllers
Sync up Views and Models Built-in mechanism
Managing UI Interactions Controllers
Managing State and Routing AngularUI Router
Creating and Wiring Up Components Dependency Injection

Angular Architecture

Business Logic

Since Angular does not use observable properties, it does not restrict you when it comes to implementing the model. There is no class to extend and no interface to comply. You are free to use whatever you want (including existing Backbone models). In practice, most developers use plain old JavaScript objects.

The Template and View

The template in Angular is a piece of the DOM before it gets compiled. During the compilation Angular transforms that DOM subtree and attaches some JavaScript to it. The result of this compilation is another DOM subtree, which is the view. In other words, you do not create the view yourself. Angular does it by compiling the template.

Constructing the DOM

Backbone clearly separates the construction of the DOM from the view logic. The first one is done using a template engine; the second one is done via data bindings and imperative DOM updates. Angular, on the other hand, does not separate the two. It uses the same mechanism, directives, to construct the DOM and define declarative view behavior.

View Logic

Angular, however, draws a line between declarative and imperative view logic. The former is done by the view, and the latter by the controller.

Syncing Up the Model and View

Angular has a built-in support for data bindings, which, in contrast to most client-side frameworks, does not rely on observable properties and, instead, uses dirty checking.

Managing Complex UI Interactions

As already mentioned, the controller is responsible for implementing the imperative logic of UI elements. On top of that, it can be used as a Supervising Presenter to coordinate complex UI interactions.

Managing State and Routing

Similar to Backbone, the built-in router in Angular is very basic and not sufficient for building real applications. Thankfully, there is the AngularUI Router project. It manages the application state, views, and supports nesting. In other words, it does everything you would expect from the router. But you are not limited to it. As with Backbone, other routing libraries (e.g., router.js) can be used as well.

Creating and Wiring up Components

Angular has an IoC container, which, like dependency injection in general, forces you to write modular code. It improves reuse, testability, and helps get rid of a lot of boilerplate. The downside is increased complexity and reduced control over how components get created.

Summing Up

That was a short overview of how Backbone and Angular address the main problems we deal with every day when building web applications. In Part 2 of this series I will expand on implementing business logic in Backbone and Angular.

More on Architecture and Design

Read more about architecture at engineering.nulogy.com.

Published at DZone with permission of Victor Savkin, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)