はじめに
この記事はRuby on Rails 7を使用して自作サービスを開発した体験をベースに、Ruby on Rails 7からフロントエンドの標準となった「Hotwire」について感想を書いた記事です。
同じく自作サービスに取り組む方の技術選定の参考になればと思いますし、Hotwireとはなんじゃい、って方にも読んでいただける内容になってるかと思います。
フィヨルドブートキャンプアドベントカレンダーに参加しています
この記事は「フィヨルドブートキャンプ Part 1 Advent Calendar 2023」20日目の記事です。
Part2 はこちらです。
前回は きたろうさんの「平均学習時間にみる『独学 vs プログラミングスクール』（実体験より）」でした。
フィヨルドブートキャンプにおいてもかなり高水準の学習時間のはずのきたろうさん。てっきり学習に専念しているのかと思っていたのですが、仕事をしながらこの実績を叩き出しているようで…読みながら身を正す思いでした。私ももっと頑張りたいところです。
part2は wataさんの「Railsのform_forとform_withの違いを調べてみた」でした。
form_withがform_forを呼び出しているのは知らなかったのでとても勉強になりました。
技術的な情報
- Ruby on Rails 7.1
- Ruby3.2.2
筆者はHotwireの中でもTurbo Drive / Frames / StreamsとStimulusを使用してサービスを制作しました。 Turbo StreamsのWebSocketやStradaは使ったことがありません。
Hotwireとは
TurboとStimulus, Stradaで構成される Rails標準のSPAを手軽に構築させてくれるフロントエンドライブラリ群。Railsの標準ですが、Rails以外でも使えるようです。
画面や要素の更新を受け持つTurbo、JavaScriptに一定のレールを敷いてDOM操作を構築しやすくするStimulus、最後にStradaがあります。Stradaはネイティブアプリ向けのライブラリです。 ↓がHotwireを構成する機能（ライブラリ）群です。
- Turbo Drive
- Turbo Frames
- Turbo Streams
- Stimulus
- Turbo Native
- Strada
これらは段階的に導入できるようにもなっています。
フロントエンドライブラリ・フレームワークのReactやvueとの違いは、Hotwireはサーバーサイドレンダリング(SSR)されるという点です。 Hotwireではクライアントがボタン1つ押して、画面上の1箇所が変わるにしてもリクエスト〜レスポンスが生じますが、 ReactやVueでは最初の読込み時にHotwireと比べるとデータを多く取得してクライアント側で表示処理が完結できるように動作します。 だいぶ端折った表現ですが、Hotwireは初期読み込み量が少なくて早い、ReactやVueは読み込み量が多いので待ち時間が生じる可能性がある、ということですね。
Hotwireの構築意図としてはRailsの標準としてRailsが従来通りにページ描画する挙動にミックスされるように構築されたのだと思います。これをよしとするかどうかは人に分かれるところではありますが、あくまでRailsの一部としてバックエンドと統合して組み込める、というのが特徴だと思います。
この辺は猫RailsさんのHotwireの良かった点、辛かった点、向いているケース、向いていないケース - 猫Rails を読むと参考になります。
また、Hotwireの理念的な部分はRailsを開発しているDHHの言葉を知るのが一番でしょう。
Hotwireの良かった点
必要十分で手軽
個人的な体験ベースになりますが手軽さに関しては特筆すべき点があると思います。
機能がシンプルかつTurbo、Stimulus、Stradaで分離されているのでドキュメントを読んで習得していくのも楽です。猫Railsさんの記事にもありますが数時間で読めてしまうというのはその通りです。 機能群は段階的にサービスに組み込めるようになっているので自分なら理解度に合わせて使うことができます。
使うのも手軽
使ってみるのが手軽だったのもHotwireのいいところだと思います。 Railsアプリをセットアップした段階で組み込まれています。導入は楽ちんです。
Turboを例に取ってみれば画面遷移を高速化するTurbo Driveは標準で機能しています。Rails newすれば動作してくれています。
では、画面全体を担当するドライブからある要素に絞って更新してくれるのがTurbo framesです。画面上のある一箇所を更新することができます。 Turbo Framesをより細かく動作するようにできるのがTurbo Streamsです。
このように段階を経て複雑な操作を実装できることもHotwireの特徴です。これのおかげで自分の理解度に沿ってTurbo DriveからStimulusまでステップアップしながら実装できました。
JavaScriptが書ければStimulusも使える
JavaScript処理にレールを敷いてくれるのがStimulusです。 DOM操作をやりやすくしてくれていて、操作したい要素に属性をつけるとStimulus（JavaScript）側で取得して操作できるようにしてくれます。 ライフサイクルもあるので私はvueを触った感触と似ていると思いました。
StimulusのいいところはTurboと分離している点です。SPAの挙動はviewにTurboで記述して、複雑な動作を要素ごとにStimulusのコントローラを作って記述することができます。
始めるための情報が揃っている
Hotwireを導入する、使うためのドキュメントは必要十分に揃っています。
Hotwireは機能がシンプルな分、公式ドキュメントの内容もシンプルですが、日本語の解説資料として猫Railsさんがデモ付きで解説記事をだされてたりもします。
開発を始める際は、この辺りを読んで開発に取り組み始めました。
また、最近知りましたが万葉さんがドキュメントの和訳Projectをやられているそうです。記事終盤のリンク集にまとめています。
Hotwireのうーんな点
Hotwireも完璧ではないのでうーんとなってしまうようなポイントがありました。
その1つが小規模な単発での技術記事の少なさです。情報の流通量が少ないことが挙げられます。 実際にQiitaを調べたところReactは約29000件に対して、HotwireとTurboが約2300件ずつ、Stimulusは300件ほどと大差のある状況です。
Hotwireは一般的にRailsの一機能として捉えられているからなのか、フロントエンドフレームワークのReactや Vueに比べてそもそも使う人が少ないことが理由だとは思います。 そんな感じなのでドキュメントでカバーされていないようなピンポイントな事象でハマった際になかなか情報に行き着かないということはありました。
そういった際は公式のコミュニティ(英語)を頼りました。それで解決しない場合はググって出てきた中国語圏のコミュニティまで調べる先を広げたりもしました。 慣れない人にはちょっとしたハードルかもしれませんが、いまどきはDeepl翻訳やChatGPTを使えば言語の壁は感じません。なんとかなります。
終わりに
フロントエンドフレームワークをHotwireに決めるにあたっては、開発理念や背景を調べた上で素早く構築してサービスローンチを目指せるフロントエンドとしてHotwireを選択しましたし、その選択のおかげかサービスはほぼ形にすることができました（サービスは現在レビュー中）。
とはいっても、トレンドの覇者Reactとこんなにもユーザー数に大差があるなかでHotwireをチョイスして、自分の技術をRailsに特化させていいのかなーと悩んだりもしました。
答えは無いですが、せっかくRailsで小規模開発するならHotwireを使った「モダンなRails」を触らないのは勿体無いかなーと思います。
リンク集
おまけのリンク集です。
Hotwire公式
公式サイトです。まずはこれで概要を押さえましょう。公式ドキュメントもこちらから。 hotwired.dev
Hotwire: Turbo Handbook の日本語訳
株式会社万葉さんがやられている公式ドキュメントの和訳Project。Turboは完訳？されてるっぽいです。 everyleaf.github.io
Hotwire Discussion
公式の掲示板です。ハマったときはここをよく見てました。 discuss.hotwired.dev
Hotwire.love
国内唯一？のHotwire専門コミュニティです。 株式会社ソニックガーデンさんのメンバーが中心になって運営されています。 小規模でアットホーム、聞き専というROM参加も可能なので私もそれで数回参加しています。
猫でもわかるHotwire入門 Turbo編
国内では公式ドキュメントと並んで利用されているであろう入門解説です。 Turboを総括してまとめているのでまさに入門です。わたしも繰り返しお世話になりました。
