2016」の4日目です。今日は、Turbolinksを考え直してみます。みなさん、Turbolinks好きですか?Rails使ってる人には、結構嫌われてる印象ですが、いかがでしょう?Railsエンジニアに嫌われるTurbolinksの図なんで嫌われたかというと理由はいたってシンプルで、既存の資産が動かなくなったからです。いう、なかなか悲しい歴史を持ったTurbolinksですが、改めて考え直してみようということで、まずはTurbolinksとは何かを簡単におさらいし、なぜ既存の資産が動かなくなったか、そして、今どきのフロントエンドならどうなのかを考えてみます。TurbolinksおさらいRailsの文脈で語られることが多いTurbolinksですが、Turbolinks自体はRailsとは切り離されたJSのライブラリです。require("turbolinks");Turbolinks.start();超ざっくりと説明すると、上記のような呼び出しに対して、以下のような処理をします。抽出したタグの中身で、実際に今表示しているDOMを上書きするHistoryAPIを使って、まるでページ遷移したかのように見せるキャッシュなどの細かい設定や、ページ遷移エフェクトなどの追加機能もありますが、コアになる機能はこんなとこです。JavaScriptでクライアント側をいじることにより、まるでSPAのような見た目を実現することができます。jQueryエコシステムとの相性が悪かったんです。特定のクラス名を付けるルールでHTMLマークアップする$(document).readyで特定のクラスが付与されたDOMを探し、セットアップするという動きを暗黙的にします。これは「jQueryとはそういうものだ」という世界です。ところが、Turbolinksを使うと、ページ遷移がなくなってしまいます。上記で説明した「4」のフェーズで新しいページのDOMが形成されますが、その後に$(document).readyは発火しないのです。言え、実際にはこの問題を回避する手段も用意はされているのですが、Turbolinks自体の動きをしっかり理解していないと正しいチューニングはできません。jQuery以外は自分でコードを書いているようなフロントエンドならともかく、jQueryプラグインやOSSのjQueryコンポーネントを組み合わせてフロントを構築していた場合には、手に負えなくなっても仕方なかったことでしょう。2017年になろうとしている今さて、ここまでは過去の話ですが、今はどうか。Qiitaもうこのアドベントカレンダーから2年経つんですね。時が流れるのは早いですね。あれから、いくつかのAltJSが淘汰されて正統ESが復古したり、jQueryを使うのはもはや悪だというぐらいの言われようになったり、ビルドツールも一周回ってpackage.jsonに戻ってきたり、いろんなことがありました。フロントは流れが早いとか言われますが、とにかく、jQueryを使わずにReactでフロント構築するのが「チャレンジ」だった時代は終わったのです。今どきの、Reactの場合はどうなるかというと、Reactコンポーネント側でwindowのloadイベントやdocumentのDOMContentLoadedイベントをハンドルするようなコードは書きません。仮にOSSのReactコンポーネントライブラリを組み合わせるようなフロント構築をしたとしても、ライブラリの内部でこれらのイベントに依存していて、Turbolinksとうまく連携しないという心配はまずないわけです。RailsはずっとデフォルトでjQueryが依存に加えられてきましたが、5.1.0ではついにjQueryが依存から取り除かれるようです。これでRails側もTurbolinksを使う土壌が整っていくでしょう。GitHubSPAと疑似SPA(*2)一方で、そもそもSPAを実現したいなら、AngularやReactRouterを使えばいいじゃないかという声もあるかと思います。それはまさにその通りで、Turbolinksが提供するような疑似SPAなんかに頼らずに本物のSPAを実装する体力があるのであれば、それに越したことはありません。その方が、ページ遷移をまたいだデータキャッシュを自由にコントロールできるため、より高いユーザビリティを実現できるからです。Turbolinksの最大のメリットは、サーバサイドに一切の変更が必要ないという点にあります。極論を言えば、サーバサイドが動的アプリケーションである必要すら無いのです。S3の静的ウェブサイトホスティング+CloudFrontで構築された完全に静的なサイトで、普通のHTMLファイルが置かれているだけですが、Turbolinksで疑似SPAを実現しています。サーバサイドレンダリングについてあれこれ考える必要もありません。スピード重視の新規開発の場面においては、APIとViewを別々に作るのはどうしても煩わしいものです。シンプルなサーバサイドController-Viewを作る速さと疑似SPAによるユーザビリティの両立には一定の価値があるのではないでしょうか。まとめTurbolinks、意外といいぞ。--skip-turbolinksせずに、Turbolinksの疑似SPAを味わってみては?明日は@takanamitoより、「ちょこっとサーバーを立てたいときのTerraformの構成を考える」です。お楽しみに〜*1タイトルなげー*2「疑似SPA」という呼び方はこの記事上で仮に付けたもので正式名称ではありませんnisshiee.orgTOPaboutblog。