Railsを快適に開発するための最新フロントエンドツールキット（翻訳）
はじめに
Evil Martiansは、Railsでのスタートアップ支援や構築を行っており、RubyとRailsがチームの生産性と競争力の強化につながることも熟知しています。しかし同時に、こうしたスタートアップが最も苦労している分野がフロントエンドであることも認識しています。本記事では、フロントエンドを掌握するための「銀のツールキット」を紹介いたします！
Railsとフロントエンドにまたがる壮大なストーリーは、まるで何百年もかけて編纂された千夜一夜物語を紐解いているような心持ちにさせられます（要するに一口では語れません）。
しかし2025年のRailsにおけるフロントエンドの話を伝えるために必要なのは、たった6語: "Cooling down Hot Wires with Inertia"、すなわち「Hotwire（高圧線）をInertiaで冷却する」です。このショートストーリーは、無駄を削ぎ落とした思慮深いスタートアップのチームにとって、より良い出発点となります。
6語で終わる短編といえば、ヘミングウェイ作ということにされがちな「赤ちゃん用靴売ります、どれも未使用（For sale: baby shoes, never worn）」1を思い出しますね。
Evil Martiansは、Railsでのスタートアップ支援や構築を手がけています。彼らは、より優秀な製品を構築することで大きなインパクトをもたらして市場を獲得している少数精鋭のチームです。過去記事の私のキーノートスピーチでも述べたように、Railsがことさら話題になっていないにもかかわらず、スタートアップがRailsを選ぶ理由を私たちは知っています。RubyとRailsがチームの生産性と競争力の強化につながることも熟知しています。
しかし同時に、こうしたスタートアップがどの分野で最も苦労しているかも知っています。それが「フロントエンド」です。
私たちは、Railsフロントエンドの生産性を高めるため次なる開拓地をこの2年間模索してきました。さまざまなgemやパターンを試し、十数社もの顧客と案件をこなし、オープンソースソフトウェアの構築や貢献を繰り返してきました。
そして本日、私たちは晴れてここにそのためのソリューションをお披露目できるようになったのです。
🔗 「独自の道を歩むことになるの？」
外部から観察している人々には、私たちがすすめる方法がrubyonrails.orgの公式の方法とどこか異なっていることをいぶかしく思うかもしれません。しかしこの提案は、18年間Rubyコミュニティに深く関わってきた企業にとって実際に健全なものです。
重要なのは、私たちがRailsドクトリンで言う「大きなテント」から逸脱していないことです。結局のところ、他に類を見ないRails独自の設計とは、フレームワークのほぼすべての部分にさまざまな代替ソリューションを適切な形で統合している点なのです。
この設計原則と、公式ソリューションvs代替ソリューションの競争（MySQL vs PostgreSQLを思い出しますよね？）は、Railsの適応力と成功の大きな源となっています。
とは言うものの、代替ソリューションという道を選ぶのであれば、それなりの心づもりが必要です。つまり、代替ソリューションのメンテナーが抱いているビジョンを信頼するということです。
単刀直入に申し上げると、ハイペースで世界制覇を目指している少数精鋭チームなら、私たちが下した判断を信じていただけるでしょう。私たちは、選りすぐりのチームによってさまざまな困難な問題を抱える多くの顧客を支援し、数週間〜数年におよぶプロジェクトに取り組み、生まれたてのプロジェクトを成熟させてIPO（新規上場）に育て上げ、失敗から多くを学び、オープンソースのさまざまなソリューションを構築し、Railsを最もメンテナンスしやすい形で拡張してきました。
（実際、私たちがこのことをまとめた『Layered Design for Rails applications』は、Railsコミュニティサーベイ2024でおすすめ書籍のトップ3にランクインしました！）
お話はこのぐらいにして本題に入りましょう。
🔗 銀のツールボックス
ここで少々問題があります。私たちには銀の弾丸（=万能のソリューション）はありません。しかし銀の弾丸はなくても銀のツールボックスならあります。
フロントエンドのタスクは根本的に多種多様にわたるので、次なる開拓地である「より最適な生産性」を手にするには、1つのツールだけでまかなうのではなく、複数のツールを組み合わせる必要があります。このトピックでは、どのようにして適切なツールを選び取るかというお話をしたいと思います。
🔗 1: シンプルなCRUDページのフロントエンドはHotwireとTurboで構築する
以下の2つの特長を持つページなら、ViewComponentやPhlexで強化された新しい主流であるHTML-over-the-wireフロントエンドを使うことで、最も効率よく構築できます。
- ステート管理をサーバーに委任できるページ。
単純なCRUDページ（多くは管理画面）やウィザードなど、ユーザー操作とページ上の複数の要素のステートがほとんど連携しないような画面がこれに該当します。 -
既存のReact/Svelte/Vueエコシステムによる複雑なコンポーネントのように見えないページ。
既にそうなっているページをHotwireとTurboで構築するのは最適とは言えないからです（後述）。
Hotwireによるフロントエンド構築事例として、Turbo Music Driveという音楽アプリがあります。この動きを見てみましょう。
このアプリを構築した理由は、Hotwireの限界をとことん探るためです。すなわち、相互依存的な操作や画面更新を生産性を落とさずにどこまで構築できるかを追求することです。
このアプリで行っていることが、Hotwireでできるおおよその限界です。これらは、以下に紹介する私たちのツールでシンプルに構築できます。たとえるなら、Turboや私たちの脳内にあるワイヤーが過熱する前にクールダウンするためのソリューションといえます。
🔗 2: 単独のReact/Svelte/VueコンポーネントはTurbo Mountで構築する
逆説的なのですが、Hotwireの生産性を落とさないためには、必要な場所でいつでもHotwireをエレガントに取り外せる能力が必要です。
Turboで完璧に配線されたアプリであっても、一部のコンポーネントで複雑かつリアクティブな機能を要求されるようになると、ワイヤが過熱する可能性があります。
そんなときは、無理にHotwireを使うのではなく、私たちが開発したオープンソースツールTurbo Mountを使ってワイヤを冷却するのがベストです。ReactやVueやSvelte固有のパーツを構築して、このツールでTurboのビューにマウントします。
Turbo Mountを使うことで、自分たちが選んだフロントエンドフレームワークを、非常に細かなコンポーネントレベルで導入できるようになります。Turbo Mountは、Railsのビューと現代のJavaScriptコンポーネントに明快な橋渡しを行います。あらゆるプロパティの受け渡しやライフサイクルイベントが自動処理され、Hotwireで強化されているページにReact/Vue/Svelteのコンポーネントをシームレスに埋め込めるようになります。
上のデモアプリは、Turbo Mountを使って、先ほどのTurbo Music Driveアプリの音楽プレーヤーを既存のReactコンポーネントに置き換えた例です。
- 既存ライブラリのコンポーネントを利用する
- 最終的にカスタムJavaScriptコードが大幅に削減される
（player_controller.jsやPlayer.tsxと比較した場合） -
明確に分離されたコンポーネントのコードが1箇所に凝縮される
（_player.html.erbとplayer_controller.jsの2箇所に分かれない） -
Turbo MountのおかげでReactとTypeScriptコードは50行で済む
この方法には、UXのリアクティブな振る舞いがコンポーネントに縛られるという制約があるのは明らかです。しかし完全にリアクティブなSPAが必要だと思えてきたら、いつでも以下のツールを使えるのです。
🔗 3: React/Svelte/VueによるSPAが必要になったらInertia.jsを使う
複数のコンポーネントのステート管理が複雑に絡み合うようになってワイヤの温度が上昇し、ページ全体をリアクティブにしなければならなくなったら、いよいよInertia.jsによる制御の出番です。
RailsでInertia.jsを使えば、個別のAPIのオーバーヘッドを増やさずに、お好きなフロントエンドフレームワーク（React、Vue、Svelte）でSPA（シングルページアプリケーション）を構築できるようになります。
Inertia on Railsの主なメリットは、既存のRailsアプリケーションとシームレスに統合されることです。Inertiaを使ううえで別のAPIレイヤは不要なので、利用するルーティングパターンやコントローラは従来のままでよく、変更されるコンポーネントはビューだけです。
「互いに依存する複数のウィジェット」や「リアルタイム更新」、「洗練されたステート管理」などを用いて複雑なダッシュボードを構築するときは、Inertiaを使うことで、Railsのシンプルさや規約を損なわずに、最新のフロントエンドフレームワークの威力をフル活用できるようになります。
Turbo Music LibraryのInertial.jsバージョンは上でご覧いただけます。
これを見ると、バックエンドのロジックとコードがほとんど同じままでありながら、UIがReactとそのリアクティブ性によって強化されていることがわかります。
Reactは、本来の用途であるビューレイヤライブラリとして使われています（ルーティングやAPIや複雑なストアなどを山ほど抱え込んだ多機能な怪物ではありません）。
この方法によって、フロントエンドの豊かなエコシステムとツールを活用してUI/UXの開発をフロントエンドチーム（またはBoltなどの AI）に任せて、Railsが最も得意とするアプリのビジネスロジックに専念できるようになります。
技術的な話をすると、HTTPラウンドトリップの大部分を排除して、可能な場合はローカルのステートに依存できるようになります。たとえば音楽プレーヤーでは、プレーヤーのステートを更新する（別の曲を再生する）ためにHTTPリクエストを行う必要はありません。
さらに、Typelizerで型システムを導入すれば両者の共生関係をさらに強化できます（現代のフロントエンドエンジニアがTypeScript以外のものを使うのは考えにくいことです）。
最後に、Inertia.jsはサーバーサイドレンダリングによるHTML-over-the-wireの感覚を実現する余地も残しています。そのためにはさらにツールを導入する必要があります。それでは見てみましょう！
🔗 4: Vite Rubyは秘伝の成分
本日紹介しているツールボックスは、Vite Rubyという秘伝の成分のおかげで非常にうまく連携しています。
Viteは指定のビルドツールをアプリケーションレベルから抽象化し（ViteはesbuildとRollupに依存し、最近Rolldownも登場しました）、高速なビルド、素晴らしい開発エクスペリエンスと、将来を見越したプラグインシステムによる柔軟性を提供します。
Viteは「ちゃんと動く」ものです。いわゆる「ビルド無用（nobuild）」方式と異なり、ビルドツールを必要とするさまざまなgemを締め出しません。Viteはフロントエンド戦略全体を可能にするための基盤となって、高速な開発エクスペリエンスと信頼性の高いproductionビルドを提供します。
私たちの方法ではこれらのツールが不可欠ですが、長期的なサポートと進化によって裏付けられてこそ価値あるものとなります。だからこそ私たちはこれらのツールにコミットするのです。
🔗 私たちのコミットメント
Evil MartiansがTurbo Mountを構築したりInertiaに貢献したりVite Rubyの普及に努めたりしているのは、「それが可能だから」という理由だけではありません。ツールの構築もメンテナンスも貢献も、私たちの顧客の案件で使うためのものであり、私たちはこれらのツールの成功と進化のために投資しているのです。
私たちのツールを使っていて問題があった場合や機能が不足しているように思える場合は、私たちまでお知らせください！お手伝いに参上いたします。
🔗 さらに先へ進むために
2025年のRailsフロントエンドでは、単一のソリューションを選ぶことよりも、個別の業務に適したツールを採用することが肝心です。その精神に則り、私たちの銀のツールボックスは以下のすべてを提供します。
- Hotwireで、標準のCRUDインターフェイスを迅速に開発する
- リアクティブなコンポーネントが必要になったらTurbo Mountでシームレスに統合する
- Inertia.jsを使って、Railsの規約を損なわずにフルSPAを構築する
この取り合わせによって、スタートアップチームがスリムな体制を維持しながら、さらに優れたユーザーエクスペリエンスを提供できるようになります。これらの武器を揃えておくことで、本当に重要なこと、すなわちユーザーに喜んでもらえる機能を構築してビジネスを成功させることに集中できます。
今年の冬はアツくなりすぎないようクールに過ごしましょう。進捗が遅くなり始めたら、私たちにご相談いただければ生産性向上のために参上いたします！
概要
元サイトの許諾を得て翻訳・公開いたします。