まずはじめにお断りということで、Railsアドベントカレンダーのはずなのに、Raisタグすら入っていない記事をねじ込んでしまいますが、そのあたりはご了解いただければと思います。

そもそもHTMLって

まずは、このWeb全盛時代を支えているHTMLですが、略語を開くとHyper Text Markup Languageということで、「ハイパーテキスト」をマークアップするための言語、というのが本来の形です。それが、JavaScriptなどが加わったこともあって、いつしかアプリケーション用のプラットフォームとも化している、というのが現況です。

各手法を考えてみる

単票HTML

そんなHTMLで複雑なJavaScript、CSSを備えたWebサイトを作った場合、ページ遷移のたびにJavaScriptやCSSはご破算になって、再度解析からやり直しとなります。そのコストもあるし、ページ遷移だけに頼っていてはユーザー体験も非連続にならざるをえない（Google Map以前のネット地図を思い浮かべてください）ということで、アプリケーションプラットフォームとして使うには少々物足りないものとなります。

Ajax＋jQuery

JavaScriptからリクエストを投げられるAjaxは、ページ遷移に依存していたWebの形を大きく変えることとなりました。とはいえ、ネイティブにしてもjQueryにしても、DOMを大きく書き換えようとすれば「細々1つずつ変更していく」か「HTML文字列で作って一気に書き換える」と言うような手段しかなくて、コーディングの手間とパフォーマンスが両立しない環境でした。

仮想DOMとSPA

その後、JavaScriptの高速化もあって、「DOM構造自体はJavaScript上のオブジェクトで表現した上で、差分反映はルーチン任せにしてしまう」という戦略が現実的となり、仮想DOMとして普及していっています。さらに考え方を推し進めれば、「ページ遷移もJavaScriptで実現する」というSPAへと進んでいきます。

Railsでも、複雑なJavaScriptフロントエンドを実現するためのWebpackerや、バックエンドに専念するAPIモードなど、SPA向けの機能も導入されています。

手法の比較

どのような手法をどんなページに使えば適当かは、もちろん適材適所があります。たとえば、文章や画像を表示するだけでほとんどアクションがないのであれば、単純なHTMLだけで用が片付きます。一方で、Webページというよりアプリケーションと言ったほうが適切な、TwitterやGmailのようなものは、SPA的な手法で作るのが適切、ということになります。

Turbolinksの位置付け

で、本題のTurbolinksですが、ページ遷移を乗っ取ることで、JavaScriptやCSSのリセットをバイパスし高速化する、という仕組みです。

動作のパラダイム…ページ遷移をベースにした通常のWebページと同じ
サーバサイドの調整…ほぼ不要
SEO実装…アクセスすれば通常のHTMLを返してくるだけなので、不要
HTML…ほぼ通常通りでOK
JavaScript・CSS実装…それなりに考慮する必要あり（とはいえ、SPAほどではない）

ということで、フィールドとしては「ページ遷移というアクションのある世界」で使うもので（文章表示目的～フォーム送信の入るシステム）、JavaScriptやCSSの解析コストが嵩んできたところに対するオプション、というような位置付けで考えておけばいいかな、と思いました。