Thoughts on development, design and the world we live in.

backbone.js #throneofjs

By sarah in Uncategorized. Posted on July 21st

Jeremy Ashkenas (@jashkenas) notes that browsers let us do things that were not possible a few years ago… However, it seems to me that the frameworks being presented at the Throne of JS conference don’t leverage those new capabilities.  Backbone is doing stuff that has been around since website started requiring IE 5.5 as a minimum browser.  Nonetheless, I enjoyed Jeremy’s talk which focused on the philosphy of backbone with just a quick tour through coding in the console at the end.

Jeremy works on the interactive news team at the New York Times. He’s the creator of underscore, coffeescript, and leads the development of Document Cloud. Document Cloud is a Knight Foundation project — all code under one of their grants must be open source. Document Cloud took the approach of extracting generally useful libraries, so jammit, underscore, backbone were extracted from the DocumentCloud effort.

“I’m not sure there has ever been so much hoopla about so little, backbone is only about 800 lines of code,” Jeremy quipped at the start of his talk.  Backbone has been around for less than two years.  The framework is intentionally minimal, and only gives you the pieces that you need every time you build a web app with JS.  They worked hard to keep it small, simple, efficient, so you don’t have to feel guilt because you are adding backbone into your app.

  • models & views
  • state & UI, convenience and convention
  • map locations in your application to URLs

Why do we take JS seriously these days?  It’s a client-side Wild West, despite that most apps are built with at least some JavaScript.  [Editorial side note: why so long before people took JS seriously?]

The Rise of Ajax

  1. initial pattern was AJAH (Asynchronous Javascript And HTML), Jeremy calls this conservative… go fetch a chunk of HTML and replace part of the page
  2. jQuery: submit form and have arbitrary code to dive into the HTML and manipulate the DOM
  3. Backbone and other frameworks that allow separation between model & views, abstractions around arbitrary DOM manipulation

Backbone’s philosophy is to enable you to create your own idealized API.

HTML is not the source of truth — the truth should be inside rich JS models. Nice analogy: the truth of your car is not on the dashboard, your spedometer says 25 mph so that is how fast your car is going, who care what the wheels are doing?

A good model has a semantic api, a method without dependency on the UI expression of state.  Backbone seeks to enable rich data manipulation, separable from UI.

JS has a poor standard library (example: indexOf, crazy that we need to write a for loop just to find out if something is in an array cuz of Interent Explorer).  Jeremy listed off a set of capabilities that underscore takes care of…interesting one I hadn’t heard of is debounce which simply throttles the calling of that function so it isn’t called more often then a certain given threshold (in milliseconds).

Being small and lightweight is very important because JS is a fun environment where you need to pay attention to how much code you write to solve a problem.  Yes, he really called that fun :)

“Apps can die from too much Javascript”

Backbone is

  • driven by use cases
  • UI, backend, platform agnostic
  • transparent source: the source code of backbone itself is heavily annotated — you shouldn’t have to read the source, but if you do need to, it should be easy to hook into.  All methods are public functions that can be overridden.

When is using Backboe a good idea?

Is single-page app a term like horseless carriage?  Instead maybe we should just think of it as a JS app -> Data + interaction

Avoid the modal interface.  We’re using JavaScript to avoid the modality of one page at a time, one thing at a time.

MVWhatever — it can be actively harmful to try to shoehorn your code into an MVC pattern.  Everyone has done this “forever” (separating model from views).  A lot of the ideas of backbone came from Robert Kiefer, who Jeremy used to work with, now at Facebook.  He wrote original AOL Webmail client, using these patterns.  Statelessness is a way of life

There is a lot of inherent complexity in a rich interface.  We need to think about how we write a UI component so it is isolated and it can remain correct no matter what else is going on.  Backbone helps with this.

Demo of Document Cloud

To wrap up his talk Jeremy then gave a compelling demo of Document Cloud.  He demo’s the following methods in the browser console:

  • Documents.pluck(“title”)
  • Documents.pluck(“annotation_count”)
  •  list view and thumnail view implemented as same views with different CSS, so drag select, command-select works the same
  •  Documents.first()
  • .get(‘title)
  • .set({‘title’: “whatever”})
  • .set({selected:true})

When he changes the data by calling methods on the console, the UI updates by itself.  Note that “title” is in the model in the database, whereas “selected” is purely client-side data (in this app).









































By sarah | Posted in Uncategorized | Comments (1)

One Comment

  1. Posted July 22, 2012 at 7:01 am | Permalink

    I had a discussion with Jeremy after to fill some of the early historical gaps. In the pre-Ajax days (i.e. from about 1998 until Jesse’s epiphany and the subsequent wide uptake), interaction via Javascript to the back end was initially mostly done in an RPC fashion with server-side methods exposed via client-side proxy and often full data objects marshalled across the divide to be reconstituted on the client. It wasn’t until Mozilla 1.0′s release that the XMLHttp object became a viable cross-platform transport mechanism and transmitting html became standard practice. It’s interesting to see how some of the new frameworks and technologies are evolving, particularly towards the traditional client-server model that was largely pushed aside in the late 90s.

Post a Comment

Your email is never shared. Required fields are marked *