The beta of Rails 4.0 is now available. One of the new features is Turbolinks. It’s a Ruby gem that actually contains code written in CoffeeScript, almost as if someone is trying to troll a large number of developers, but let’s leave that to one side. Here’s what it does:
I was wary of Turbolinks when first announced, as I said at the time:
I understand the motivation for this kind of stuff, and it’s neat, but I’m wary of it because of the additional complexity it introduces for a relatively small benefit.
I may be misleading myself, but it’s rare (on a desktop browser, at least) that it’s the page rendering time that I really notice: far more significant is usually the latency, or the time taken to transfer the significant proportion of a megabyte of HTML that’s smothering a few kilobytes of text.
On the downside, it replaces something that just works with something that … mostly just works. See elsewhere on this page: “Loads blank white screens in firefox 15” / “This is now fixed”. And that’s the problem: you’ve replaced something that works in every browser with something that you have to (or someone has to) test in every browser, and whose failure modes must all be handled. What happens when you click on a “turbolink” on an overloaded server, for example? My experience so far has been that this kind of enhanced link is usually faster, but the probability of nothing happening in response to a click is not insignificant.
I’m aware that I probably sound like an old grouch.
Others have made similar comments; Yehuda Katz wrote:
And that’s my objection, really: Turbolinks fixes a non-problem by adding a lot of complexity. That just seems a bit self-indulgent. Like those mobile websites that replace scrolling (just works everywhere) with heavy and broken swipe pagination (hey, we tested it on iOS 6 on WiFi!), it’s not driven by user needs.
Many of the websites I use on a daily basis are too clever for their own good, and break horribly when exposed to network latency, dropped connections, busy servers, or browsers in the wild. It doesn’t save me time if I have to phone up to give my electricity meter reading because the asynchronous form submission just doesn’t work. It doesn’t save me time if I have to log into a website in Firefox to close an item because nothing happens when I press the button in Chrome. Both of those happened yesterday, on the websites of companies worth hundreds of millions of dollars. My user experience would have been better if they’d been plain old CGI scripts! At least then I’d have got a sensible response from the submission: a timeout, or an error, but something.
If you must replace pages with an asynchronous call rather than just GET followed by 200 OK, then please do use Turbolinks, because there’s zero chance that you’ll get it working right on your own. But even then, maybe still don’t bother, because your visitors might actually prefer predictable click behaviour and memory usage, and websites that just work across a wide range of browsers and network connections. You’ll save yourself trouble, too.