2003 or 2013, ASP or Rails both are terrible ideas IHMO. At least as a default.
Sure it can be very efficient, but it's a terrible default.
When DHH state:
> except, maybe, compatibility issues with some existing JavaScript packages
Some ? Don't you mean most ? Even Twitter Bootstrap will leak memory if used in a turbolink app.
When coffeescript is pushed as default, I'm ok, at worst you don't use it and you have a useless gem.
But turbolink is harmful if you don't know what you are doing.
Much further after that, there was a jQuery plugin called taconite that let you do this from arbitrary languages. The idea was that you can handle all of your templating server side and build the template into a simple xml document that had tags corresponding to jquery dom manipulation functions. You return the template with the right mimetype, and the plugin handles translating your xml template into a dom update. This has been handy a few times to keep all of the display logic centralized in a single templating mechanism.
TurboLink does less, so there are less things to screw up.
TurboLink always replace the whole body, not just part of the page. There's no input focus to maintain. Server side render a page the same regardless of whether it's fetched normally or through TurboLink. Links fallback correctly on JS-disabled client.
