With Backbone, you represent your data as Models, which can be created, validated, destroyed, and saved to the server. Whenever a UI action causes an attribute of a model to change, the model triggers a “change” event; all the Views that display the model’s data are notified of the event, causing them to re-render. You don’t have to write the glue code that looks into the DOM to find an element with a specific id, and update the HTML manually — when the model changes, the views simply update themselves.
So, how do we want our app to behave? Here are the ideals as I see them.
- All state/models for your app should live in one place.
- Any change in that model should be automatically reflected in the UI, whether that’s in one place or many.
- Clean/maintainable code structure.
- Writing as little “glue code” as possible.
Backbone doesn’t attempt to give you widgets or application objects or even really give you views. It basically gives you a few key objects to help you structure your code. Namely, Models, Collections and Views. Ultimately what it provides is some basic tools that you can use to build a clean MVC app in the client. We get some useful base objects for those and an event architecture for handling changes.