Gave this a quick skim, matches with a lot of what I've been thinking lately. I particularly like idea of isolating modules from the DOM so they can be tested in the CLI-- could also enable reuse on server & client.
I'v did some single apps.
* https://trakrapp.com/ (server's certificate has expired) an issue tracking app. with Backbone, Jquery.
* http://mei.fm/create Wwn's online stack editing app. (need to signin to get full functionality). A team structure the code with the help of Jquery, Mustache.js, Underscore.
* http://rssminer.net/demo .yet another RSS reader. I write it with Jquery, Mustache.js, Underscore.
I haven't read through the whole thing [1], but I really like the fact that he actually discusses different approaches when trying to achieve a goal and instead of just mentioning them. He has an opinion and is not afraid to express it and that's good because it encourages thinking and discussion.
A few years ago nobody criticized an author for calling his work a book if it didn't have an electronic version. We are now clearly in a transition phase [1], but it is plain that soon it will be acceptable and in fact expected to forgo the print edition when publishing "a book". A significant threat to content preservation, but that's another story.
What distinguishes a book is the 'form factor'. Obviously we are talking about an e-book. Nonetheless little care has been put into producing a 'book': not TOC, no index, no page numbers, etc.
(Obviously this is all independent of the content.)
These are outdated requests, maybe with the exception of the TOC, which soon should also be taken care of by technology [1].
Regarding the index, if you are willing to visit the single-page version, a simple CTRL-F gives you the 70 references to "DOM", for instance. Your modern browser quickly shows how those references are spread in the document. That is pretty much an optimal index to me, with an unlimited number of entries, rendering the separate and physically constrained notion of index obsolete.
And why pages? In today's world of wildly diverse screen sizes and resolutions, please let the content flow. I remember being led to the wrong place of a book in my college years just because the edition I consulted happened to different from the author's, but I found that reasonable in the paper age. Semantically demarcated concepts such as chapters or sections have always been referred in this way, and rightly so. If you think about it, page numbers only helped you locate verbatim excerpts such as "to be, or not to be" in [2]. A completely valid and efficient artifact of the pre-digital era, which has now become dispensable, just as indexes have.
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...
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.
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.
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.)
