Turbolinks 3こそがRailsの未来
かもしれない。
追記 2016/2/22
と書いてたけど実現しない感じになってきました。
現状のTurbolinksは Turbolinks classic とリポジトリ名が変更され、新たにTurbolinks5の開発が進められることになったようです。
背景にはiOSやAndroidとのCompatibilityを高めるためみたい。
Turbolinks3で目玉として導入される予定だったPartial ReplacementxはViewの遷移の責務がTurbolinksが持つことになり複雑さがますため、取りやめになりました。その代わりにpersistさせたいelementにdataを記述することでTurbolinksのDOMの置き換えがその部分は行われない手法が採用される予定みたい。これで複雑さを減らし、同じように高速化が実現出来るみたい。Rails5と同じタイミングでリリースされそうなので今後もチェックが必要そうです。
先月行われたRailsConf2015のKeynoteで@dhhがRails5について発表し、その中でRails5の目玉としてActionCabel, Turbolinks 3が紹介された。
Rails5以降、Turbolinks3で何が変わるか。
今までのTurbolinks
- ページ遷移をする代わりにAjaxでGETリクエストを発行し、レスポンスからbodyタグの内容を取り出し、現在のページのbodyと入れ替えを行う事で、cssやjsのリクエストを減らす、それらのparseにかかる時間を短縮する効果が主な用途だった
- Turbolinksの特性上、ページ遷移を行わないため
document.readyが発火しない、前のページで実行されたjsを明示的に終了させる必要がある、などの問題がありTurbolinksとjsのコードを共存させるのが難しい。
以前Turbolinksについて書いた記事、こちらも合わせてどうぞ
今日のWeb開発とその問題
Javascriptのクライアントサイドフレームワーク(Angular, Backbone, Emberなど)が多く出てきた事でブラウザ上で動くリッチなサイトが以前より開発しやすくなってきた。
しかしサーバサイドとクライアントサイドの両方の開発が求められるようになったため、その分エンジニアに両方のスキルが求められるか、またはそれらのスキルを持った複数のエンジニアが必要になってきた。
エンジニアのリソースが潤沢にある会社や、クライアントサイドもサーバサイドも両方こなせるエンジニアがいるチームなら問題ないのかもしれないがなかなか難しい。
そこでTurbolinks
Railsの強みの一つは高速にWebアプリケーションを構築すること。スタートアップや個人が作りたいアプリケーションをできるだけ開発コストを抑えて最速で作成するのに適したWebアプリケーションフレームワークだと思う。
Turbolinks 3.0 から Partial Replacements の機能が追加され、今までbodyの中身全てを入れ替えていたところを、指定した一部のDOMのみを変更できるようになる。
クライアントサイドフレームワークを使用して動的にDOM操作をしていた箇所をTurbolinksを使うことで、ある程度置き換えることができる(かもしれない)。
Javascriptの使用をできるだけ抑え、Turbolinksを代わりに使用することで開発工数の増加を抑えることが狙い。
Partial Replacements で実装できそうなこと
- ページのタブ操作やコンテンツ切り替え
- コメントの追加
- カートに商品を追加、個数の変更
- フォロー/アンフォローの切り替え
- ページ切り替え
- 検索キーワードに応じて結果を動的に切り替える
- 入力フォームのvalidation errorを画面遷移なしに表示(submitをするたびに)
などなど、これまでjsを使って実装するとなると割と工数がかかっていた事をほとんど実装することなく実現できるのではないだろうか。
じゃあJavascriptはできるだけ使わないほうがいいのか
もちろんそれは一概には言えない。開発チームの構成、どういう機能が要求されるアプリケーションなのか、ユーザーエクスペリエンスがどのぐらい重要なのか、開発期間がどれくらいあるか、など様々な要因によって決まってくるのでなんとも言えない。開発工数を少なく素早く作りたい場合は、jsの使用はjQueryで簡単に実現できる程度で留めてクライアントサイドフレームワークを使わないという選択をすることもできる。それぞれメリット、デメリットがあるのでチームごとに考える必要がある。
Rails API
RailsはTurbolinksを取り入れてJavascriptを完全に排除したいかというとそうではなくて、デフォルトの指針としてはJavascriptに極力手を出さずに開発することを目指すが、SPAのサーバやAPIサーバを構築する事も今後も積極的にサポートしていく。
Rails5からRails-APIがRails本体に取り込まれるとアナウンスしているので、こちらを使用してAPIサーバーとしてRailsを扱うこともできる。
今後のTurbolinks
JavascriptでもReact.jsなど新しく注目を集めるライブラリやフレームワークが出てきてますしクライアントサイドの開発は便利に、楽に、拡張性が高くなっていくはず。
しかし、Turbolinks3を使用することでJavascriptをそんなに必要とせずとも動的に動くサイトが比較的簡単に構築できるようになれば、リッチなサイトを構築することと開発工数との関係の一つの落とし所なのではーと期待してる。