DHHが語る Railsとフロントエンドの今後の関係性

日々変化し続けるフロントエンドの世界において、Ruby on Railsはより良い開発環境の構築に貢献します。

なぜならRailsのようにすべてのフレームワークをパッケージとして備えるような完全なインテグレーションに取り組む開発環境は他にないからです。

Railsの生みの親であるDHH氏に、その強みやHotwireとの関係性についてもお聞きしました。

Railsとフロントエンドの今後の関係性

JavaScriptの新しい構築方法の共有や各ブラウザのJavaScript対応など、フロントエンドでは大きな変化がありました。しかし今後も新しいアイディアの余地は広がっています。

webpackが継承するBundlerとtranspiringのアプローチは約10年間デフォルトとして使われてきました。しかし現在は主要なブラウザでES6をトランスパイアなしで直接使用できるようになってきています。このことはJavaScriptやフロントエンドの開発方法を新しいステージに導きます。

フロントエンドは新しい開発ステージに

現在のRailsの複雑さはフロントエンドやwebpackとのインテグレーション（統合）に起因します。今後はJavaScriptが持つ能力を活かしながら、よりシンプルな方法を考える余地があるのです。TurbolinksやStimulusの開発がその好例です。

そしてHotwireがこれらを一つのパッケージにまとめたもので、Railsの優れたフロントエンドを構築するために必要なものがすべて揃っています。

Hotwireは間違いなくTurbolinksの代替になる

Basecampの新しいEメールサービス「hey.com」はすべてHotwireで構築されています。

顧客に送信するフロントエンドパッケージのJavaScriptバンドルはわずか40キロバイトと信じられないほど小さくなっています。ReactやVueなどを使用するのとはまったく異なる手法であるからです。HotwireのコアはHTMLを送信する（HTML over the wire）ことです。Hotwireは本質的にHTML over the wireの略で、サーバーサイドの生成に重点を置いていることを意味します。

私たちはすべてのアプリケーションをわずかなJavaScriptバンドルで構築しています。Hotwireは間違いなくTurbolinksの代わりになるでしょう。

HotwireがRailsの新しいデフォルトに

Rails 7の新しいデフォルトはHotwireになります。

Railsを使ってReactアプリケーションや他のタイプのアプリケーションを作りたい人は多くいるでしょう。しかしOmakaseアプローチを強く希望しない場合、デフォルトを使用できます。

Hotwireをどのようにデフォルトにするのか？

どのようにHotwireをデフォルトにするのかは、まだ議論の余地があります。webpackをデフォルトにしないで済むのか？ES6をブラウザで直接使うことができるのか？これはChromeがすでにサポートしている新しい規格のImport mapsというものに一部依存しています。一方SafariやFirefoxの場合、ポリフィルはありますがまだサポートされていません。

Import mapは基本的にブラウザのロードパスを提供してくれるので、コンパイルの必要はありません。import * from @hotwire/turbo とすれば、Import mapが @hotwire/turbo の指定範囲を特定のファイルに変換してくれます。yarnが提供するpackage.jsonやログファイルを使えば、すべてのファイルを更新することなく依存関係を解決できるのと同じです。

今はそこを解決しようとしている段階です。しかし解決ができなかったり、ポリフィルが十分ではないと判断した場合でもwebpackをそのまま使用してHotwireをデフォルトとして出荷することができます。

OmakaseにおけるHotwireの選択肢

HotwireはOmakaseのデフォルトの選択になるかもしれませんが、Turbolinksテストのように簡単に取得できます。気に入れば使い続けることができるし、気に入らなければオプトアウトすればよいのです。

Omakaseは「Railsにはデフォルトですべての機能が備わっているべきだ」という考えに基づいています。しかし「Hotwireの代わりにReactを使いたい」「Minitestの代わりにRSpecを使いたい」といった希望があればその個々の部分を変更することができます。

Railsが特別であり続ける理由

Railsが特別であり続ける理由は全てをインテグレーションされたフレームワークに取り組んでいる点にあります。Railsのように全てのバッテリーを備えたフレームワークを持つ競合相手はほとんどいません。

JavaScriptの世界で起きていることに目を向けると、どれも本質的には個人に委ねられていて自力ですべてを組み立てる必要があります。Bootstrapやその他のフレームワークもありますが、すべてのフレームワークをパッケージとして備えるような完全なインテグレーションには誰も焦点を当ててきませんでした。これは開発環境をより良くするという点において大変価値のある焦点だと思います。

あえて全体性に責任を持つことで、生産性を向上させることができます。この点でもRailsはDjangoなどのフレームワークよりもユニークだと思います。Djangoなどはフロントエンドにバッテリーを含めたアプローチを行ってきましたが、それだけでは不十分でした。Railsはフロントエンドがアプリケーションの一部であると言っています。

実際、Hotwireに関する議論の多くでフロントエンドとバックエンドを分けていることが問題になっています。完全にインテグレーションされていて、一人の開発者が1つの機能を上流から下流まで作ることができるフレームワークの方が良いのです。なぜなら一人の開発者が全工程で必要とされることをすべてできるようになり、競争力のある新しいWebアプリケーションの作成が可能になるからです。

今日のテクノロジーの多くは非常にニッチな部分に焦点を当てているため、「狭い分野の専門家」として他の「専門家」と協力する必要がありますが、これは良い方法ではありません。しかしRailsはすべてを代行できるので、コンポーネントの各部分を気にする必要はありません。これが、Railsが特別である理由です。