I actually do use an el already in the DOM. To be honest, I do it that way because the code looks cleaner and is easier for me to understand that way, I didn't know it was faster. The only caveat I've found with that way is that if you remove a view and add an identical one, the events from the old view still get fired. For views where that happens, I actually use a custom extension of the original views that has a special destroy method that gets called which unbinds events and stuff.

When first learning backbone, I played around with the router, but I don't use it at all now. It was pretty hard for me to use and didn't seem to have much of a point. I suspect for many use cases, if you really need the url path to change, reloading the page from the server would be fine. But of course my perspective comes from only the use cases that I've worked with.

I actually mostly don't use backbone to organize the data, mostly only to display the data. The demo you looked at actually has little mini database implemented in the background using arrays and objects (used as maps). I mostly use collections for things that go right on the screen. I also (mostly) don't use backbone's ability to sync data with the server. I have a module that uses Jquery's Ajax for this instead. The reason I don't use backbone for this is that I found their way of doing it breaks down with more complex relationships within the data.

I mainly use backbone as a utility for message passing (update a model and one place, and messages are passed so everywhere else it is displayed updates also). And for organization: the views, pieces of the DOM within a view, and events.

Also, I use Marionette.js, not pure Backbone.js

...I'm not trying to say my way of doing things is the right way, just relating what I do and why for discussions sake.

Oh, and I looked at your demo. That is really cool. That's really fast for so many records.