There's another use case that is just as important in my opinion: offline mode. The Turbolinks folks would argue "you are not on a fucking plane"[1], but I have been on a plane and wanted to access things like GitHub issues.
The architecture that allows JavaScript apps to win the "Prague café effect" also makes it possible to write web apps that are still useful without an internet connection, so long as the user has downloaded some information in the past.
DHH has said that things like Turbolinks are "a stop-gap on the road to having persistent JS runtime across page changes"[2], and I think he's right. The tooling is still very immature right now, which is why people like Turbolinks: it fits into an extremely well-polished workflow. But I'm excited about the next few years, as frameworks like Ember and Backbone reach the maturity of server-side frameworks.
Definitely agree. We chose to use EmberJS for this exact reason. The idea of working offline and synchronizing changes back to your API backend when you're back online is great.
Offline apps have been doing this for ages -- it's great that web tech is finally catching up w/ these great adaptations of HTML5 features.
The architecture that allows JavaScript apps to win the "Prague café effect" also makes it possible to write web apps that are still useful without an internet connection, so long as the user has downloaded some information in the past.
DHH has said that things like Turbolinks are "a stop-gap on the road to having persistent JS runtime across page changes"[2], and I think he's right. The tooling is still very immature right now, which is why people like Turbolinks: it fits into an extremely well-polished workflow. But I'm excited about the next few years, as frameworks like Ember and Backbone reach the maturity of server-side frameworks.
[1]: http://37signals.com/svn/posts/347-youre-not-on-a-fucking-pl... [2]: https://twitter.com/dhh/status/281432076199280640