Single page apps in depth (new free book) | Hacker News Reader

Single page apps in depth (new free book)

singlepageappbook.com

157 pointsmixu31 comments

Open articleView on HN

I was expecting the book to be on a single page

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

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

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

Actually, most woodworking books are made from wood.

touché

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

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.

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.

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

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)

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

It is not a book because...?

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

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

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.

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

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

> no page numbers

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

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

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

is there any possibility to donate or contribute?

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.

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

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?

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.

This is my preferred solution to single page apps:

http://www.enyojs.com

Reply on news.ycombinator.com