If you can get away with storing your data in the DOM, then go ahead. But this technique is mostly applicable to low-interactivity views (see the view layer overview chapter) - once you start displaying the same data in multiple locations, having your data tied to the DOM structure and state goes from being a easy technique to a complication. Hence I don't really consider storing data in the DOM as a single page app technique as much as an easy way to do low-end interactive components.

I have never been a big fan of "easy" data binding, and totally agree that data is not to be stored in the html. Same reason why you don't use your kitchen table as the pantry...

Isn't the point of data-binding that you don't store stuff in the UI, but instead store it in a model that you bind to the UI?

I'd say databinding is useful for smaller convenience plugins, not for the architecture of larger JavaScript applications. From my quick skim this book is spot on.

It is your opinion that the answer to making a larger JavaScript application is one big bucket of state Object?

Tell me you've got something better than that.

Sort of? I mean, if you're using models and collections to store _model and collection_ state, then essentially yes, you'll probably have a global variable that namespaces the state of data in your application (or closure-wrapped modules, as the author suggests).

At a certain point (and fairly early, really) keeping the state of an interactive application as HTML nodes is not what I want.

Or a number of isolated, small state objects with well-defined interfaces.

Seriously? So you think Backbone.js and the like are just a fad?

I'm not fond of the way Backbone.js works. It solves none of the hard problems of making an SPA. (AngularJS is guilty of this too, albeit from a different angle.)