Neat Ideas from Backbone.js Conf

I had the pleasure of attending Backbone.js Conf in Cambridge, Mass with a bunch of my fellow Automatticians last week.  The presentations were a treasure trove of neat ideas and perspective shifts.  Lots of stuff to try out.

You can find a list of all the slides, and some notes from another Automattician here.

Here’s my notes on what caught my eye from each presentation:


  • Don’t hesitate to add useful methods to models (we tend to leave our models unadorned), e.g. account.disable(), photo.sharewith() etc
  • We might be doing some things in the view (e.g. add a comment) that could be in the post model instead
  • Filtered Collections – could use the concept of filtered collections for categories of posts (e.g. this.filter(…) )
  • Have the more ephemeral item be the listener to the thing that is more permanent (e.g. an edit comment view is much more ephemeral than a post view)
  • Try using a deferred to fetch infinite scroll posts – e.g. $.Deferred(…) to let us use users.lookup(id).then( function() ) pattern
  • If a view is suffering from repeated calls, try wrapping the render in _.debounce(), e.g. render: _.debounce( function() { … } )
  • If there are a lot of things to render in a collection, use .first to grab a subset, and then call yourself again with _.defer for the .rest

Building Large Scale…

  • Maybe update some things in the push state (e.g. like whether all comments are toggled closed)
  • Never forget that bootstrapped data will go stale – not necessarily super fast but they will
  • Coffeescript mentioned again 🙂
  • Look at BB.Associations and see how they did nesting (e.g. for comment trees)
  • Could we be navigating to the category route, instead of treating it as a page load (e.g. category/foo)
  • Could a post permalink also be a managed route – i.e. to not load the whole page
  • Break up different parts of the app into app modules, each of which specify their routes – instead of having all the routes in a single app – and then the module only handles those rounds (e.g. an app module might be the artists selector, another the playlist selector )
  • A “controller” could also take shared components (e.g. grids, etc) and pass them into views – this helps makes the code in views simpler
    • e.g. instead of having a posts view handle the “add comment” – let the controller do it – that way the view code is simplified – and then the app module could watch out for the duplicate
    • this could really simplify the posts and comments view code – to make it back to the original BB intent of it just rendering the model (or collection’s) state
  • Look at Marionette again
  • Treat entities as a shared resource (posts) and then views could filter/clone sync
  • We could break out the comment collection view into a subview itself – instead of cluttering up the posts view
  • Right now the app and appView are synonymous – and contains the entities as well – we should probably move our entities out of the app, the app activates that view and passes a filtered collection to that view – the app should also instantiate widget views and pass filtered collections to them too?
    • If we navigate to a single post, the app would activate that module which would tear down that app view and replace it
    • one module for latest posts (category archive same module or separate one?)
    • one for specific post
    • one for author profile
    • sidebar module?
    • move options out too
    • The uberApp should define (template) the sections (divs) of the screen (header, body, sidebar, footer) and connect (assign) an initial set of modules to them
      • Some of those assignments will vary as the routes vary (e.g. / = posts or /post/132 = single post)
      • The uberApp pulls the “wrong” view and replaces it with the correct one?   Hmmmm
      • Some of those assignments will not vary (e.g. footer content?)
      • The uberApp also sets up polling and sockets and the canonical data stores
        • and it manages requests from modules for cached or fresh (new) data
      • Widgets as modules

Test Driven Development

  • Could I implement a automated test that adds and removes post and comment views and detects memory leaks?
  • Could this test automatically run and post notifications when sandboxed, but not kick off otherwise?
  • Maybe have this test run automatically on page load?  – i.e. to get people to use it or at least put an on-screen button to kick off the test and report the result
  • The test(s) could be a module too – and the uberapp could include / assign that module to the main container or sidebar – oooh
  • Good first push state use could be clicking on a permalink on a post in the view of posts view
  • Look at JS DOM (javascript dom simulator)
  • Functional approach (e.g. writing a comment, etc) vs unit/atomic (on change x happens)
  • karma + mocha + chai in node.js instead of jasmine – look at backbone boilerplate by “tim”

Injection for Fun and Profit

  • we already pass in our dependencies in general – we could also have initialize throw new Error if the dependencies are missing
  • the initialize for the app view could form an injector object (with a reference to the app this and the data collection) and then pass that into each subview’s initialize method (and those subviews can throw if it is not seen) [an instance may not need the app view reference actually – the instance view would need to remember to false the ]
  • take a look at sinon.js
  • backbone in action – sam breed –
  • code: mlbbjsco

Domain Driven Web Apps using Backbone

  • Domain Driven Design by Evans (2004)
  • Could we replace our polling with something based on Backbone.js fetch – and how could we extend that to the ultimate sockets approach?
  • Example code :

Geologic Time Scale

  • – real-time web sockets approach
  • What is BackPlugs?
  • Gilt avoids using backbone router (URLs are not processed on the client) – see Play?
  • “an effective foot cannon”

Building Reflow

  • “Fluid” – app wrapper (puts websites into a like-native app)
  • Our “weakness” (in how we bring together modules) – is that the dependencies are defined (in PHP wp_enqueue_script) separately from the objects (in JavaScript)
  • Look at using Backbone LayoutManager and Marionette again for the post view comment collection refactor?
  • Are we hitting performance issues with our templates?  How slow are they?  What about dust?  What about removing some of (or all of) the logic in them?
  • FilterableCollection.js
  • Sinon.js + Squire
  • Sonar for code coverage?
  • Topcoat –
  • Chrome Embedded Framework?

Day 2

Growing Up with Backbone

  • Putting 3rd party code in separate folder(s) facilitates different linting / static analysis / coding standards rules
  • Do we have source maps in our minifcation process? (Note that source map references recently switched from @ to # (or maybe the other way?) )
  • Use coffee script for grunt file / config file creation?
  • Look at “bower” sometime
  • Look into chrome canary

Alternative … Patterns …. cujo

  • We could improve our inter-module dependency visibility by passing in views, collections, etc into the constructors for the modules that need them instead of making it so you have to dig through the code to see the dependencies on o2.whatever.whatever – interesting
    • Dependency Injection is an example of Inversion of Control
  • Instead of mixing objects and classes  – we can avoid confusion by only having classes in our “namespace”
  • Can use the “meld” library (part of cujo JS) to add this before and after behavior (to avoid modifying an object internals) – can, like in WP core, use .filter to apply multiple filters to views this way (before adds a filter)
  • To toggle comment views between and edit and a non-editing state, would there be benefit to using CSS instead of the templating we are doing?  i.e. set a class on the topmost element to “edit” or “show” and let CSS show and hide the fields?  *** FTW *** we could avoid a re-render!

Control Freak

  • We could take that jsonifiedModel business we are doing in the posts and in the comments and have an intermediate object – a view model – that does that embellishment / parsing of the model into bindable json
  • Look at Fiber for extending components and look at Venus for test runner
  • FastClick for touch events

UI Library Design

Enterprise and the Mobile Web

  • Inheritance (e.g. to be able to get a resource URL in a base) is one way – but blocks of related functionality that aren’t really classically inheritable (e.g. the objects aren’t really children of a base, but have something in common they both need to do) – use extend to mixin the behavior
  • One thing we could do with a global datastore object is enforcing transactions – e.g. to write a comment a transaction is created to avoid a read (poll) polluting the comment model in mid-update

2 thoughts on “Neat Ideas from Backbone.js Conf”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s