He also brought up some issues with including a sub-view within a template. If you try to just include a sub-view within a template, the event binding for the sub-view won’t get wired up right and it just won’t work. You can work around this issue by passing the parent view to the child view and binding to the parent’s rendered event. Then you create the event bindings for the sub-view events after the parent has rendered and everything will just work.
Another potential issue that was brought up is that in some cases, views that are created and destroyed frequently (like a scrolling calendar app) will cause memory leaks. If the views are not bound to the model properly, they’ll hang around after they’ve been destroyed and still handle events and take up memory. This is caused by binding the model to the view with Model.On(). The model holds on to the view, so it won’t go out of scope to be garbage-collected. The easiest way to fix this issue is to flip the event binding and listen for the event from the view with listenTo(). There’s a neat Google Chrome feature called Heap Snapshot that can help debug run away memory leaks. It lets you take a snapshot of the memory at a point in time and compare it to another snapshot. You can see what objects are hanging around in memory and find potential problems.