I like the tutorial style and I wanted to show something like this to someone, so that's really cool. There's one thing I think you've got wrong in the example

I like the tutorial style and I wanted to show something like this to someone, so that's really cool. There's one thing I think you've got wrong in the example: by having functions bound to the same event (addStatus and clearInput), you paint yourself into a corner with Backbone, where you can only bind one function declaratively. However, your solution of clearing the input whenever a status is added is wrong, since (conceptually) the status collection may add statuses whenever it likes for whatever reason, but now doing so will erase the user's input box. Suppose this evolved into a realtime twitter-like thing – you would get hard to understand bug reports of people's input "disappearing". (Moralising: It's important not to let architecture astronautics distract form the actual logic of the program.) When the NewStatusView successfully adds a status, it should be responsible for clearing its input ready for reuse. The call to clearInput belongs at the end of addStatus. A further argument for this is that it will eventually have to move into a success callback of the collection add, for example when a banned list of words in statuses lives on the server, or you actually broadcast the statuses. Don't know why I felt compelled to make such a long comment; hope it makes a great reason even better.