Live data from Hacker News

Single page apps in depth (new free book)

singlepageappbook.com

1–10 of 32 posts

Re: Single page apps in depth (new free book)

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

Re: Single page apps in depth (new free book)

#4
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

Re: Single page apps in depth (new free book)

#8

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.

Re: Single page apps in depth (new free book)

#9
post #8

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.

Re: Single page apps in depth (new free book)

#10
post #8

Earlier quoted context omitted.

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.

Post reply on HN