[Xichekolas]

No, presumably the client clicks on something, which calls an action on his server via xhr, which does some server-side logic (say, update the cart and compute a new total) and returns a json packet, which the client then uses to update the page.

Without knowing the specific details, I'd imagine the json response has directives for what static html to load if needed, which results in more xhr requests to get those files. The client side js simply needs to know how to process the json it's given, it doesn't need to know any business/persistence info.

What I'm curious about is how he handles urls (if everything is xhr, then the url will always stay the same, which is kind of a pain for linking to specific stuff, unless you do anchor workarounds like Facebook does). Also, I'd be curious if he uses the static html files as templates (injecting data into them clientside) or just has a TON of tiny html fragments.

[neeson]

So far, all the HTML that a given page will need is part of the same document. The templates for the dynamic content are all stored inside a hidden div.

I expect that eventually this will cause too much of an up-front load time, so I'm planning on having the JS load bundles of it on demand. Reducing total HTTP requests is a big usability win, in my experience.

To answer your URL question, I use attributes, like this:

http://urbantastic.com/org.html?id=org-8srmt85mtf8t

Which the server ignores, but the Javascript parses and uses to figure out where it is.

[Xichekolas]

Ah, yeah it'd make much more sense to have all the html handy at once instead of requesting them one at a time.

So in the case of that link... org.html has all the html fragments it needs for anything that can be done on that page in a hidden div?

A neat idea for sure, thanks for sharing... (now off I go to play with it!)

[smanek]

Makes much more sense. Thanks