I think that although Turbolinks is an improvement on how current Rails app do view rendering, the article is absolutely spot on; Single Page Apps consuming JSON data and handling the view rendering provide a better user experience, especially when taking the issue of offline into account.<p>On a 2nd note, that's why I think the Rails API project is more important to the future of Rails than the Rails 4 release. I believe that Single Page Apps will become the defacto way to build web applications, and that the war to be the platform of choice isn't just about Backbone Vs Angular Vs Ember, but also about which server-side language and frameworks you use.<p>Rails is great (I never said it was crap), but you have to ask why companies like LinkedIn and AirBnb would choose to move off of Rails. If you checkout these talks (LinkedIn - <a href="http://www.youtube.com/watch?v=hMd45Ij2DYQ" rel="nofollow">http://www.youtube.com/watch?v=hMd45Ij2DYQ</a>), (AirBnB - <a href="http://www.youtube.com/watch?v=9g5Kzj6TpPY" rel="nofollow">http://www.youtube.com/watch?v=9g5Kzj6TpPY</a>), you'll see some of what the guy wrote in his article in them.
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 <i>have</i> been on a plane and wanted to access things like GitHub issues.<p>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.<p>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.<p>[1]: <a href="http://37signals.com/svn/posts/347-youre-not-on-a-fucking-plane-and-if-you-are-it-doesnt-matter" rel="nofollow">http://37signals.com/svn/posts/347-youre-not-on-a-fucking-pl...</a>
[2]: <a href="https://twitter.com/dhh/status/281432076199280640" rel="nofollow">https://twitter.com/dhh/status/281432076199280640</a>
Author here.<p>One side note: I don't actually hate Turbolinks. If it's working for some people with little effort, more power to them.<p>I'd just suggest to _anyone_ considering it, you should look into a JSMVC framework first to see all the other benefits you can get.
Some refer to using backbone.js or ember.js as if using them is cost free. Learning these two technologies has cost. turbolinks also has cost but it is much much lower for a rails developer.<p>So when they are being compared keeping the cost of having developers who can deliver both quality rails code and quality backbone/ember code should be kept in mind.<p>If you need all the features Javascript frameworks provide then ofcourse turbolink is not a good solution. But turbolink is an excellent way to speedup your 'about us', 'contact us' and other low complexity pages.
The article seems a little misleading. Using turbolinks won't make your site slower than not using turbolinks. Even the people in a café in Prague will enjoy improved speed over a full page load. The point of the article is that a JavaScript MVC framework could make your site even faster. Fair enough, but I fail to see how that's a flaw in turbolinks. By that logic it's pointless to make any speed improvements unless we write our backend in assembly.