You might be doing that already, but the article mentions (if I got that right) that if you GET an arbitrary URL, the server will still serve the whole rendered page - asynchronous loading only happen on any subsequent requests.
This way, you don't "break" URLs, pleasing search engine crawlers and allowing copy/paste of the links, and still delivering a great experience for the user.
I truly believe there is a big demand for a Node.js framework to facilitate this. There are already a few that allows this kind of architecture (to some degree), but none are quite "there" yet.
How do you feel about derby? (http://github.com/codeparty/derby)
https://github.com/Morriz/backbone-everywhere https://github.com/developmentseed/bones
https://github.com/jordow/FaxJs
The gist is that you just write standard declarative ui structures in pure javascript and the system disassembles the markup on the server, and reassembles it on the client with all the events still in tact. You wouldn't know all that is happening just by looking, though.
...
var twoDivs = {
className: 'outerDiv',
onClick: this.outerDivClicked,
innerDiv: {
className: 'innerDiv',
content: 'inner-most-div!'
}.Div()
}.Div();
the decision to be made there is do you want to load all the objects (models, views etc.) or have an init where it is all either loaded async or from the localstore cache. I went with the later so that the html page can be static cached.
this has taken me a while because there was a lot of js to write - for eg. a sync replacement that uses localCache and the server smartly, that responds in async with 'ok' so the view can be updated rather than waiting on the server, and then triggering server updates every x seconds or when the user closes the window (this all has to be cross-browser, which is the hardest part)
a node.js framework that does all this would be great, while I am using Python atm I think these types of apps are very well suited to run on node.
Not that I know of any yet.
If you don't need any custom logic at all, you can easily use JSON to pass that object between client and server with no further changes. If you do need some custom logic, it'd be slightly more work, but then again you could just opt to use javascript for any small pieces of logic, as there are V8 and/or Spidermonkey wrappers for most or all of the languages supported by Mustache.
So I don't know what a 10-page forum has to do with it. I can render a 10-page forum in ~100ms without Javascript. It all depends on server-time and layout-data.
Maybe you should tell PG this site is years behind ;)
This is what web applications are now and will be. The user experience can not be compared to the old style of application. If you are still building applications today that are GET, fetch, pause, render, etc. then you are years behind. It is awesome being able to click on a link to a 10-page forum thread or blog comment page and have it render in ~100ms.
I think all of the web server frameworks will have to adapt - from RoR to Django etc. since a lot of what they do is being moved to the client (and it becomes even cheaper to run large-scale web services because of this). There are also tons of gaps on the client side - from more capable and cachable templating engine through to a full-stack framework (something like RoR for Javascript but less confusing and hard to use than the current)
The server now is just db+REST, auth and pubsub - soon enough somebody will release a generic PaaS that does all this based on a schema. Almost no more, or very little, server-side code (unless you insist on supporting old HTML clients).