Backbone.js Large mutli page app, manage page transitions cleanly destruction, creation etc

Question

I'm currently building a huge backbone app (facebook clone).

Over the last couple of days, feeling pretty happy with how everything works in BB thanks to Rob Conery's excelent tutorial (essential viewing if your starting out with MVC 3 and BB http://tekpub.com/productions/mvc3)

Now I've come to the stage where I need to switch pages in my app, and I am starting to wire this up, but it feels like I'm doing a lot of this myself. This is fine, and I know I will be able to do what I want it to.

I've delt with the memory leaking issues, by making sure I unbind and remove my models/collections/views when switching page, Switching views in backbone for navigating between pages - whats the right way?

But aside from this stuff, there is a whole load of tasks that I want to do when I switch between pages. Essentially removing and adding parts of the page. This is slightly more complicated becuase rather than just removing everything, I'd like to only remove/destory the bits of the page that need to change, based on the transition I'd like to make.

As said, I'm getting it working myself at the moment, but I wondered if there was a pattern to handle this tear up / tear down process, and keep things clean (and not end up with a massively bloated router (controller bloat!!!)

Answer 1

Marionette is definitely the way to go. Specifically, Marionette.Layout is fantastic for swapping out specific regions without re-rendering the entire page. Check out some of Derick's Example Apps to get acquainted with the framework.

I'd recommend staying away from the Router until after you've gotten your app working using plain old events. Then add the Router support after. Basically the Router should be wired up to reflect the state of your app, but you should not depend on it to be your controller.

As an aside, I'm using RequrieJS on a large multi-module Backbone project and it's been a godsend. It's controversial in the BB community, but it's worth looking into if you'll have lots of inter-dependent components and you want to let another framework handle all the dependencies.