Turbolinks and the Prague Café Effect | Hacker News Reader

Turbolinks and the Prague Café Effect

eviltrout.com

29 pointstomdale9 comments

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.

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.

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 - http://www.youtube.com/watch?v=hMd45Ij2DYQ), (AirBnB - http://www.youtube.com/watch?v=9g5Kzj6TpPY), 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 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.

[1]: http://37signals.com/svn/posts/347-youre-not-on-a-fucking-pl... [2]: https://twitter.com/dhh/status/281432076199280640

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.

Who is we? Synchronizing changes back to the API doesn't sound easy especially when the state of the remote side may have diverged from the client.

Author here.

One side note: I don't actually hate Turbolinks. If it's working for some people with little effort, more power to them.

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.

I wish DHH would have chosen something a bit more battle-tested than something he whipped up. Yes, Basecamp... that's still only one app. It's fair to say that it's hard to know what David doesn't know.

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.

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.

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.

> Using turbolinks won't make your site slower than not using turbolinks.

No, but it encourages a style of development that makes you rely much more on the server side speed than you should. That is the major flaw I was trying to bring attention to.

The general sentiment was supposed to be: interested in turbolinks? Well take a look at THIS first.

Client Side MVC frameworks are certainly not all about speed - they have other advantages such as great organization of your Javascript code, API first development, etc.

Reply on news.ycombinator.com