DEV Community

Ryan Kahn (he/him)
Ryan Kahn (he/him)

Posted on

Backbone for React Devs: The Song Remains the Same

Why should you care?

Maybe you shouldn't! However, if you have to work in Backbone and come from a React background, or if you're interested in some historical changes in the world of the web, read on! Even if you only care about React or modern DOM diffing frameworks, this comparison will give you a new perspective. So what is the difference between Backbone and React?

Imperative vs Declarative

The primary difference between React and Backbone is that React uses the Declarative (and "Reactive") way to define mutations or changes in a webpage, where as Backbone uses the Imperative way. Consider HTML:

  <h1>The title!</h1>
  <p>Some <span class="bold">content!</span></p>
Enter fullscreen mode Exit fullscreen mode

HTML declares elements on the page, and sets an initial state and content for the page. It says what things are, and where the go, but does not (without a script block) define any interactions or changes to the page.

React is like this too, only it defines a cycle between a State, or values that change, and translates that through functions to a declarative snapshot of what the page looks like in reaction to that change (what you see in JSX). React looks at changes in the snapshots and through that diff mutates DOM elements. Sort of like a diff in git, "Add this Line", "Remove this Line", only its "Add this class", "Remove this element" ect... So in the end you declare the page, and React modifies it imperatively.

Backbone takes an older approach prior to DOM diffing frameworks appearance on the scene. Back then, JQuery was the hot library, and essentially it would do the same thing React does in the end. "Add this class" or "Remove this class". The approach is imperative directly, as in you select elements and mutate the DOM.

State and Components vs MVC

In React, you have state, and components. These fit the data flow and declarative style, where you're constantly translating state into DOM snapshots through nested function calls. Backbone has Models, Views. and Controllers. Because it's imperative, it needs to take an Object Oriented as opposed to a Functional approach. You need long lived references to DOM elements, the View objects, so that you can change them over time. The data flow isn't one way like React, so you need persistent models that handle the state of the program, and trigger changes in the Views through subscriptions (this is sort of like the reactivity in React). Then there are Controllers, that handle the business logic of the program. In React these kinds of changes would live mostly in effects with React hooks.

Code Navigation

Backbone can seem a bit like a mess compared to the clean functional programming of React. Persistent objects messaging each other willy nilly, mutating the DOM in a complex less comprehensible than the one way data flow and declarative nature of React. And this is true! It is a bit of a mess! The key to comprehending it is to trace dependencies, just like you would look at nested components in React. Start with the DOM mutation, or model update that you care about. Then trace the function calls, the subscriptions to the model, or the other way from the view with the updates that lead to the change...follow this around and you'll be able to modify these interactions safely.


I am a strong believer that nothing really changes in software development. In the end we're doing the same thing programmers did on the ENIAC machine, translating input to output through commands and switches. In that same vein, web development hasn't really changed fundamentally between the Backbone years and the React years. We're still declaring the DOM in HTML, mutating it through JavaScript commands.

What has changed is how we divvy up these actions, how we generate the commands, and the resulting power and developer experience that gives us a bigger lever to move those bits around. Keep this in mind as you compare any two frameworks or programs, or languages, or any abstraction that we use in programming. There is nothing all that new fundamentally, and at the same time what does change is the power we have as developers to take in complex inputs and create ever more complex outputs.

Best of luck, and long live the web!

Top comments (0)