It took me a while to figure it out, but the model concept in Backbone doesn't completely correspond to the model concept in Amber.
Backbone, at least as I practiced it, has a model that very closely corresponds to what goes over the wire. You observe stuff on that, you react to events, the event observers react and update the model and as a result the model is sent over ajax.
Amber, again as I practice it, has a model that corresponds to the complete application state of a particular component of the page. If you have a checkbox that doesn't 1-1 match with something you'd send to your server, you create an attribute on your model purely to track the state of that checkbox and wire up observers to update the appropriate "real" attributes you're sending to the server. This is not immediately apparent when looking at the two frameworks but I find the difference to be crucial.
I started using backbone the day you open sourced it since I had a personal version of more or less the same thing that was twice the code and less elegant. I found that it was fantastic as long as you could do idempotent DOM updates (i.e. innerHTML) but got lost as soon as I wanted to start adding sub components that needed to be initialized and I was back to dealing with a lot of event twiddling and dom manipulation for updating the view. I believe the split in state between the DOM and application model causes this complexity which is avoided in Amber by having all client side application state in one place. I think I could apply the same ideas in Backbone but I haven't tried since switching over.
Neat. Do you have any open-source examples of this simpler "client side application state in one place" up on GitHub? I'd love to take a peek.
I think that I'd tend to agree with your interpretation -- you write:
> [In Amber] If you have a checkbox that doesn't 1-1
> match with something you'd send to your server, you
> create an attribute on your model purely to track the
> state of that checkbox ...
That sort of approach would be against the Backbone "party line". A large part of the point is to have your canonical state for a given resource in one place: the model. If you now have both "model" and a "view-model" for the same resource, one of which has been adopted to be more checkbox-y, just so that its attributes correspond more closely with the DOM ... it would be a shame.
The allAreDone propery. It's not something you'd have in the canonical data you'd send to/from the server but exists as a property so it can be observed and so the template bindings can manipulate it.
> If you now have both "model" and a "view-model" for the same resource, one of which has been adopted to be more checkbox-y, just so that its attributes correspond more closely with the DOM ... it would be a shame.
The model is more checkboxy but the checkboxy bits are initialized from the canonical bits and your sync equivalent has to strip them back off. This is annoying but less annoying than DOM twiddling.
I would like to strongly agree with your statement about idempotent DOM updates v. subcomponents. This question (re-render entire unit or manually sync model changes with individual jQuery dom changes) is one of the first things I try to think through when using JS MVC patterns. It is a huge pain when you have nested controls for nested models.
Backbone, at least as I practiced it, has a model that very closely corresponds to what goes over the wire. You observe stuff on that, you react to events, the event observers react and update the model and as a result the model is sent over ajax.
Amber, again as I practice it, has a model that corresponds to the complete application state of a particular component of the page. If you have a checkbox that doesn't 1-1 match with something you'd send to your server, you create an attribute on your model purely to track the state of that checkbox and wire up observers to update the appropriate "real" attributes you're sending to the server. This is not immediately apparent when looking at the two frameworks but I find the difference to be crucial.
I started using backbone the day you open sourced it since I had a personal version of more or less the same thing that was twice the code and less elegant. I found that it was fantastic as long as you could do idempotent DOM updates (i.e. innerHTML) but got lost as soon as I wanted to start adding sub components that needed to be initialized and I was back to dealing with a lot of event twiddling and dom manipulation for updating the view. I believe the split in state between the DOM and application model causes this complexity which is avoided in Amber by having all client side application state in one place. I think I could apply the same ideas in Backbone but I haven't tried since switching over.