Single page apps in depth (new free book)

emilepetrone 13 years ago |

I was expecting the book to be on a single page

callmeed 13 years ago | |

A book about woodworking doesn't have to be made of wood, does it?

shill 13 years ago | | |

Actually, most woodworking books are made from wood.

cnunciato 13 years ago | | |

A day later and I'm still laughing over this. :)

callmeed 13 years ago | | |

touché

kami8845 13 years ago | | |

No but there's always that little part of me that expects it to be.

kjbekkelund 13 years ago | |

There is a single page version: http://singlepageappbook.com/single-page.html

pfraze 13 years ago |

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.

Look forward to reading the whole thing tonight.

fshen 13 years ago |

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.

cnp 13 years ago |

This is quite nearly the PERFECT book, one that every web developer should read front to back.

rudasn 13 years ago | |

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.

[1] Only read through http://singlepageappbook.com/detail1.html (on Views)

ssn 13 years ago |

Don't call this a 'book'. I know it is a great plug but it is simply not true.

floptikal 13 years ago | |

It is not a book because...?

raphinou 13 years ago | | |

I find the layout awful for a print version. And the PDF document has chapter links that lead to the website, rather than the page in the PDF.

I can live with that if I generate a PDF from web content, but I'd expect a book to have a better print version and a better quality PDF version...

ezequiel-garzon 13 years ago | | |

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.

[1] http://www.nytimes.com/2011/05/20/technology/20amazon.html

ssn 13 years ago | | |

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.)

ezequiel-garzon 13 years ago | | |

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.

[1] http://dev.w3.org/html5/spec/headings-and-sections.html#outl...

[2] http://www.gutenberg.org/files/27761/27761-h/27761-h.htm

geon 13 years ago | | |

> no page numbers

You would only need page numbers if there were any pages.

cardivvy 13 years ago |

here is my single page app www.cardivvy.com

its simple app using api to get list of car2go available cars, parking spots, with a simple Google Map mashup.

it isn't DOM->Model->View structure. its simple call to api to retrieve json using php and javascript and php/html presentation.

any generalized suggestions about how to do this as DOM->Model->View structure?

where does the api call fit? in DOM

zaphod1984 13 years ago |

thanks for the book! currently reading it on my kindle and really enjoying it!

is there any possibility to donate or contribute?

heretohelp 13 years ago |

I'm a little skeptical from my initial skim of this.

His attacks on using the DOM to store information make me think he's never know the joy of a clean data-binding setup.

mixu 13 years ago | |

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.

floptikal 13 years ago | |

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...

jules 13 years ago | |

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?

niels 13 years ago | |

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.

heretohelp 13 years ago | | |

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.

zachrose 13 years ago | | |

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.

pfraze 13 years ago | | |

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

danso 13 years ago | | |

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

heretohelp 13 years ago | | |

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.)

rsanchez1 13 years ago |

This is my preferred solution to single page apps:

http://www.enyojs.com