

Turbolinks and the Prague Café Effect - tomdale
http://eviltrout.com/2013/01/06/turbolinks-and-the-prague-effect.html

======
paulbjensen
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.

------
tomdale
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...](http://37signals.com/svn/posts/347-youre-not-on-a-fucking-plane-and-if-
you-are-it-doesnt-matter) [2]:
<https://twitter.com/dhh/status/281432076199280640>

~~~
leepfrog
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.

~~~
atomical
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.

------
EvilTrout
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.

~~~
peteforde
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.

------
neerajdotname2
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.

------
actsasbuffoon
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.

~~~
EvilTrout
> 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.

