Rails のフロントエンド周りの未来予測

ども、@kimihom です。

Rails の Sprockets や Uglifier などが最新の JavaScript に追従していないという理由で、Rails 標準のやり方から外れて最新のフロントエンドツールを追い求める系の報告が多い。一部では完全に Rails の Asset Pipeline から外れて、Gulp などに移行する話もよく聞く。確かに現行の Rails のフロントエンド環境で開発すると、let やクラス構文をまともに使えない(エラーになる)ため、最新の構文に対応した JavaScript フレームワークはほとんど使えないのは大きな問題として残り続けている。

最新版である Rails 5.1 から、ようやく jQuery からの脱却とフロントエンド周りの最新化、つまり Yarn や Webpack の導入が検討され始めている。これに期待されている方も多いのではないだろうか。

Rails5.1に向けてフロントエンド周りで起こっている革命まとめ - Qiita

そもそもこんなにフロントエンドの話題が盛んな今、なぜ最新を行くはずの Rails はここまで遅いのだろうか。

CoffeeScript と Turbolinks

Rails としては、「CoffeeScript を使え」というのが答えのようである。これを使えばクラス構文など、既存の JavaScript で抱えていた問題をよしなに解決してくれる。

Rails としてはそれに Turbolink を組み合わせれば、SPA も作れるのだ。今までの Rails のレールはそこにあったのである。 Rails 5.0 でもその思想は変わらず、よりモバイルフレンドリーになった Trubolinks を推奨していた。

Rails5 が示したサービス開発の新しい指針についての考察。

本来であれば、私たちはこれらを使うべきだったと言えるし、Rails 5.0 までは CoffeeScript と Trubolinks の組み合わせが Rails の答えだったのだ。

Rails 5.1 で変わろうとする未来

かつて Rails がデフォルトの JavaScript フレームワークを prototype.js から jQuery に変えたように、Rails 5.1 からついにフロントエンドの最新に迫るようになった。これは最近のフロントエンドの流れに反応した結果だ。CoffeScript や Turbolinks ってのを Rails 5.0 までは推していた私も、Rails 5.1 からは標準ではなくなるのはほぼ間違いないと考えている。

ようやく対応が始まってきたのには大きな理由がある。現時点でのあらゆるブラウザが、 JavaScript の最新仕様に対応していないからである。Rails が最新の JavaScript に対応しようとすると、Babel など最新の JavaScript 仕様に対応できていないブラウザに対応するためのコンパイラが必要になってしまう。これらの煩わしさから解放されるには、ほぼ全てのブラウザがデフォルトで JavaScript の新仕様に対応してもらう必要がある。

Rails 5.1 が一般的に普及する頃(1, 2年後)には、この問題が解決されているだろう。だからこそ Rails は今このタイミングで最新の JavaScript 対応に着手し始めたと考えられる。

Rails エンジニアが今すべきこと

そんな中で Rails エンジニアはどう行動していけば良いのだろうか。

まずは Rails 5.1 に向けて、JavaScript の新仕様にはしっかりと追従していく必要がある。具体的にはクラス構文, Promise, などの ES~ 系のJavaScript の新仕様, Web Component などの HTML5 などである。これらは React のような JavaScript フレームワークの仕組みではなく、ブラウザ標準のHTML仕様として今後普及していくものだ。これらをマスターしておき、Rails 5.1 に向けて備えておきたいところである。それらが一般的に普及すれば、プロジェクトによっては React っていらなくね？って話になる可能性もあるから、基本をまず抑えておくことは本当に大事なことだ。

大規模な SPA を作る必要がない場合、Rails 5.1 が一般的になるまでは jQuery Rails で全く問題ないと思う。Rails の form_for とそれに連動する値セット/検証や I18N の仕組みは一級品だし、jQuery のエコシステムは膨大だからだ。やがて jQuery 依存のライブラリは、純粋な JavaSciprt だけで書き換えられるようになっていく。そうなった時に、今の jQuery プラグイン縛りから解放され、jQuery からも外れられる。事実、 jQuery Rails は既に jQuery の依存をなくす実装が進んでいる。1, 2年後には jQuery を使う理由(クロスブラウザ)なんてのはなくなって、Query Selector API などの新仕様を使えば良くなるのだ。(jQuery はすべて置き換えられるってのを紹介している記事もある)そんな未来が 1,2 年後には間違いなくやってくる。

ちなみに現在の Rails のフロントエンドの仕組みがどうしても嫌だ！っていう場合や、フロントエンドとバックエンドを完全に分けたいという強いこだわりがある場合は、 Rails を Web API としてだけ使うやり方は大いに考えられる。だけども、そんなことするくらいならバックエンドを Rails にするって選択は無いなぁと思ってしまう。だったら Go とか Scala, Elixir とかの方がよくね？って話になるからだ。「サーバは API だけの作りにして、あとはフロントエンド(JavaScript / Swift / Kotlin)に全部やらせたい」って考え方の人は、他のフレームワークの方が要望を満たせると思う。適材適所でフレームワークの利用を検討すべき時が来ている。なんでもかんでも Rails ってのはやっちゃいけないパターンだ。

Rails は引き続き動的な HTML レンダリングが中心のフレームワークのままやっていくことだろう。.erb の世界である。スマホアプリもWebView 中心の作りにすれば、素早く修正を反映できて高速な開発が可能になる。

終わりに

私としては今後、スマホアプリは WebView 中心のものになっていく感が高まっていくと思っていて、Rails の方針には賛同している。ただしその障壁として iOS の HTML5 対応が遅いので、今後は iOS が従来の IE のような存在になっていくと考えている。となると、日本の iOS ユーザーの比率が高いということがネックになり、またもや日本だけ IE 対応をしていた時のように iOS 対応をしなければならない未来ってのを予測している。こういうのは Web エンジニアの宿命なのかもしれない。

何はともあれ今後の Rails と HTML5 界隈の話から目が離せない。