Building Backbone Plugins: Eliminate The Boilerplate In Backbone.js Apps (2014)
Better, Faster, Cheaper
Building Backbone.js applications without the use of plugins, add-ons and project-specific abstractions is a waste of time and money.
But while Backbone is no different than any other system in the need for abstractions, it does provide some unique and interesting ways in which we can build our reusable pieces. And having an understanding of how to use Backbone effectively means more than just using the existing components that it comes with, or existing plugins built by other developers. It means understanding how all of the pieces fit together, and how those pieces can be extended and augmented. It means understanding how to pull apart the general needs of a component to create something that can be extended in to a specific scenario. And it means knowing how to recognize and extract the patterns that we create in our own applications, in to re-usable components that may be deliverable as plugins and add-ons in themselves.
What Is Backbone?
· Backbone.Model: A set of data, and optionally logic, representing an entity in the application
· Backbone.Collection: A group of related models, with standard functions for retrieving models, iterating over the models, etc.
· Backbone.View: Views provide a way to encapsulate and organize jQuery or other DOM manipulation library code, and manage, manipulate and respond to the DOM through declarative DOM events, model and collection event bindings, etc.
· Backbone.Router: Respond to changes in the application’s URL, providing bookmarkable and navigable URL’s based on tokenized representations of the application state
· Backbone.History: Manage the actual browser history, forward and backward buttons, and respond to configured routes. The History object does the actual work that routers define, allowing multiple routers to exist in a single application.
· Backbone.Events: Provide an event-driven, or public/subscribe architecture, allowing application components to be decoupled from each other while still allowing communication to happen between them
· Backbone.sync: Provides an abstraction for model and collection persistance. The default implementation expects a REST-like API on a server, communicating with JSON over jQuery AJAX calls
For a more complete introduction to Backbone and it’s components, see the following resources:
· Addy Osmani’s Backbone Fundamentals
· My Intro To Backbone Screencasts
· My Additional Resources
Why Are Plugins And Add-ons Neccessary?
In spite of - or perhaps because of - the flexibility, simplicity and power in the components that Backbone provides, it does not provide everything that a developer needs to create a complete application. There are several concerns that many applications have which Backbone does not directly address, or which Backbone provides some support without a direct implementation.
For example, Backbone’s View provides a default render method that does nothing. It takes no parameters and it produces no observable changes as a result of calling it. However, this method is built in to Backbone.View to illustrate the common practice of providing a render method on a view, which will generate the HTML structure that the view is to manage.
On the flip side of that coin, Backbone’s Model and Collection provide no method of handling nested or hierarchical models and collections. It’s up to the developer and the individual project to set the standard for adding this support, when it’s needed.
In both of these cases, there are existing plugins and frameworks that provide solutions for Backbone-based projects. Frameworks such as my own Backbone.Marionette or Tim Branyen’s Backbone.LayoutManager provide a default, but easily changeable, rendering solution for Backbone views - among many other benefits and capabilities. There are a handful of tools that can provide nested and hierarchical models, such as Backbone-Relational, and many other tools, add-ons, plugins and frameworks that provide a tremendous amount of power, flexibility and capabilities on top of what Backbone provides. For a more complete list of the available plugins and frameworks, see the Backbone Wiki.
With these existing add-ons, plugins and frameworks available, there is often enough for an application of any size to be completed. But there are also times when the feature set of a specific add-on, or the implementation of an individual framework, may not play well with the opinions and needs of the development team working on an application. There are also scenarios where an individual application needs a very specialized set of functionality to work properly - one that needs to be repeated several times throughout the application, but is also specific enough to the project that it cannot be generalized in to an open source project. In either of these cases, and in many other more subtle scenarios, it is beneficial to understand how to create your own plugins and add-ons for Backbone so that you can take full advantage of encapsulated functionality, customized for your application’s needs, while still playing well with existing add-ons. Creating your own add-ons and plugins is both easy, and tremendously frustrating at the same time. Add-ons that are seemingly simple, such as creating the ability to have a “selectable” model and collection via myBackbone.Picky, are quick to build and be useful, but become very complex as the more subtle edge cases are discovered.
Throughout this book, I’ll walk you through the tools, tricks and lessons learned for building the smallest of add-ons through the largest of application frameworks such as Backbone.Marionette. I’ll teach you the tricks that I’ve learned, show you the pitfalls to avoid, and walk you through the construction of add-ons that are both useful and easy to use, while not creating an undue burden for the developers that are maintaining them or the developers that are using them in their applications.
Who Should Read This Book?
This book is aimed at developers that are already familiar with building Backbone.js applications of any scale, and are looking for ways to reduce their development efforts, clean up their code base, and provide standardized implementations for their teams to use in products and projects. It will show how to take a large code base and reduce duplication and boilerplate code down in to managable, customizable and flexible chunks that an entire team can then apply.
The ideal reader is a person who is building medium to large sized applications in Backbone, and may or may not be part of a team. You may be a team lead, looking to simplify the architecture and implementation of a large project, or a sole-developer or contractor, looking for more effective implementation patterns for your Backbone applications. If you’re writing applications and noticing a trend in the amount of boilerplate code, a series of patterns of implementation, or are looking for insight in to how to recognize these patterns, then this book is for you.
This book is not a general introduction to Backbone and its core concepts. There are plenty of books, screencasts, blog posts and other materials that cover a general introduction in great depth. Rather, this book will take your existing knowledge of building Backbone applications to a new level, showing you how to create common abstractions and re-usable implementations that may benefit your project specifically or be more broadly applicable and deliverable as open source.
In Relation To MarionetteJS (Backbone.Marionette)
The majority of knowledge contained in this book came directly from my experiences in building MarionetteJS and in building applications with MarionetteJS. Of course there are other examples and plugins that are used in this book. You will find, though, that most of the information found in here is already found in MarionetteJS’ implementation. Base views, model views, collection views, regions, application objects and workflow… all of this and more, is available in the MarionetteJS framework for Backbone.
However, the vast majority of features and behaviors found in MarionetteJS are implemented differently than those in this book. This is done with purpose, as Marionette has gone through the rigors of hundreds of applications and thousands of developers using it. It would take an insurmountable effort to explain every last line of code in Marionette, quite frankly. This book aims to simplify the most common and core knowledge for building a framework like Marionette. The value in this book, then, is not that you will build MarionetteJS on your own. It is that you will have first hand knowledge of the decision making process for building a framework like MarionetteJS.
Having this knowledge encoded in Marionette and simplified for this book does not diminish the value of the content of this book or the MarionetteJS framework, though. Rather, I am attempting to provide a clear understanding of why MarionetteJS is built the way it is. I want to extend the knowledge of MarionetteJS users as well as the capabilities of Backbone users that do not wish to use MarionetteJS.
And in the end, I am not trying to sell anyone on using MarionetteJS for their applications. My greatest hope, in fact, is that other developers will find the knowledge in this book so empowering in building their Backbone applications, that they will want to create their own frameworks and plugins. Whether you want to build your own plugins and frameworks or use MarionetteJS, ChaplinJS, Backbone.Giraffe, Backbone.LayoutManager, Thorax or any of the other great application frameworks available, though, I hope that this book will give you a better understanding of how to better use BackboneJS.