Look beyond jQuery to an MV* approach.
You’ve probably seen seen simple example editors, where the browser acts as an editor for to-do lists. In these applications, you edit to-do items, consisting of a text and a state (pending or done). These small editors are very helpful for studying monitoring events from the keyboard and partially updating page content. These are the main principles for building applications in web browsers.
Once you going beyond to-do list editors, the requirements quickly increase. For example, you might work with multiple counters that observe the cursor position, or the number of words in a text box. You might need to support multiple editing modes or text formatters, or edit actions and state synchronization with a backend.
Even if you are not building an advanced editor in a web browser, but more a reader or browser for documents, why would you want to know about the MVC pattern? Client-side MVC is often important for these cases as well. For example, in web applications that render search results, there are often opportunities for microinteractions. If you render a collection of search results, users might want to save items to a “wishlist” or mark results as “favorites”. These actions require saving tiny bits of information on the server and locally updating DOM nodes depending on the outcome of the action. Also, when a user requests details of an item, you might want to save the search state in the browser, and maybe items in a shopping cart.
The jQuery Option
So, assuming you want to hook into browser events and state of a web browser, how do you start building the application? One option, and a good one, would be to start out with jQuery. There are a number of reasons that speak for jQuery:
- jQuery allows us to easily observe events and changes such as clicks and inputs
- jQuery supports a number of strategies to replace HTML on a page accordingly
- jQuery comes with support for Ajax and supports “old”, but widely used browsers such as IE8 out of the box
- jQuery has a rich ecosystem with many plugins and example codebases.
But there are a number of problems with jQuery too. Combining and rearranging jQuery building blocks can quickly become messy. Plugins and components in jQuery are far from being Lego blocks. In particular, managing the number of callbacks or custom contexts to use a plugin quickly explode. Also, mocking an environment suitable for application test would be difficult with pure jQuery.
Looking Beyond jQuery
Once an application grows beyond a certain size, or when you are starting out with a single page application right from the beginning, you quickly will benefit from two strategies:
- The Observer pattern. With jQuery’s
onmethod, you can subscribe to events from DOM nodes. Yet, instead of coupling all kinds of logic to an event, you can build notifiers to decouple a user interface from state changes. Many MV* frameworks directly descend from the observer pattern.
Frameworks to the Rescue
Both the observer pattern and the representation of application state are implemented by front-end MV* libraries and frameworks. Libraries such as Backbone.js are special in that sense however, that they are unopinionated and provide freedom in tuning an application to your custom needs.
With Backbone.js, you can use Backbone components as you need them. For example, you can use
Backbone.Views to observe events from users. Or, you can update the state of
Backbone.Collections directly from jQuery callbacks. Or, you can use
collection to fetch remote data and update nodes in the DOM accordingly.
Minimizing coupling between components is not only very scalable, but has a number of additional benefits. You have single places for extending state or behavior, you can re-use business logic across multiple interfaces, and the interface becomes better testable, since you can easily mock dependencies such as data or user events.
Collections to track and update application state.