Hotwireがその複雑さから私たちを解放してくれる

(かもしれない)



by YoshitsuguFujii

だいぶHotwireに偏った意見を展開しています。若干思想強めなので惑わされないでください。

Rails World 2025

DHH氏は基調講演の冒頭で、かつてのWebアプリケーションは1人のITエンジニアが書いたPHPファイルをサーバに置くだけ、わずか5秒でデプロイできていたのに、2025年現在では50人の開発チームが15分かけてデプロイしていると指摘。

「これは深刻なほど何かが大きく間違っている」（DHH氏）

https://www.publickey1.jp/blog/25/rails_81dbmarkdown.html

非常によくわかる

サンプルの画像

🤔

個人的にもPHPで書かれた1ファイルでBBSを作って一喜一憂していたところからずいぶん遠くに来てしまったものだと思う。

なぜこれほどまでにシステムは複雑化してしまったのだろうか。

そしてDHHがいうように、この複雑さを享受した上で15年以上前のアプリケーションがもたらしていた価値に比べて何が変わったんだろうか。

Ruby on Railsの思想は、「規約」というレールを敷くことで、開発者を迷わせず、本質的な開発に集中させること。
迷わずに本質的な開発できています？

複雑化したシステムにDHHのひとつの解

Hotwire(HTML Over The Wire)

Hotwire is an alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire.

つまりフロントにJSONではなくてHTMLをネットワーク越しに送る

  • Railsアプリケーションの複雑さの多くは、フロントエンドやwebpackのようなインテグレーションからきている。
  • 開発体験を犠牲にすることなく、高速で素晴らしいWebアプリケーションをいかにして作るかという問題に対する我々の答え

Hotwireの動作の例を見てみよう(1)

Hotwireの動作の例を見てみよう(2)


部署選択によりformのパラメータ全部を使ってリクエスト(Sitimulus使用)

Hotwireの動作の例を見てみよう(3)

受け取ったパタメータを使ってもう一度formのviewを再生成する。
この時使うviewは初回に表示していたのと同じview。

リクエストパラメータによりグループは選択済みとなり、
ユーザーはグループにより絞り込まれた状態のhtmlが生成される。

Hotwireの動作の例を見てみよう(4)

サーバーから送られてきたhtmlを使って画面を置換する(Turbo Frame)
ユーザーから見るとSPAのような体験となる。

Hotwireがもたらすもの

プレゼンテーション層のロジックの集約

  • ステートをフロントエンドとバックエンドで持たない
  • viewを全てバックエンドで生成し、必要に応じて再利用する。
  • フロントとバックエンドでのバリデーションロジックの重複実装の回避
  • 導出ロジックの一元化
  • その他いろいろ

本質的でない部分への対応がへる

  • セッションやトークンなどのフロントとバックエンドが分離していることにまつわる本質的でない問題を考えなくてよくなる
  • SEOへ親和性
  • 常に最新のデータを元に描画が可能。
  • たった一つのルーティング(バックエンドとフロントエンドが別々のルーティングでうんざりしたことは?)

開発体験

  • 言語の一元化(大部分がrubyになる)
  • JSON APIの設計、構築、共有、バージョン管理が不要に。
  • フロントとバックエンドでの思考の分断（お互いのことを意識した開発）が起きない

コスト削減

  • フロントとバックエンドをわけるやり方だと、フロントとバックエンドであらゆるものが2重でコストがかかる
    • それぞれでの実装のコスト
    • ライブラリのアップデートコスト
    • 脆弱性キャッチアップのコスト
    • 最新情報のキャッチアップや学習のコスト
    • 実行環境の構築、保守コスト
    • テスト環境の構築、保守コスト
    • e2eテストなんて大変。

もちろん表現力はSPAの方が高い。しかしそのリッチさはあなたが作ろうとしているシステムに本当に必要なものですか？
色々な複雑さやコストに目をつぶってまで本当に必要なものなのですか？

多種多様な技術やレイヤーを入れたくなるのはエンジニアの性だし、
より難易度の高い仕事に魅力を感じてしまうのは日本人の業だし、
より複雑なシステムを構築して乗りこなしたほうが満足感と仕事の達成感を感じてしまいますよね。

しかし得られるメリットは少ないのに、莫大なコストかけて開発していませんか？

1個のパンを食べたいだけなのに、10キロ離れたコンビニに買いにいってませんか？ 🍞🏃‍♂️‍➡️

終わり

FTPで5秒でデプロイしていた昔の方法から、 1時間かかる現代へと逆行しているとは、何かが深刻に、狂ったように間違っている。
今日では、何かをリリースするだけで、常に全ての要素が相互に依存し、関係者の全員が関与する必要があるように思える
現代のWebアプリケーション構築に必要な可動部品やコンポーネントの数も、完全に爆発的に増えている
いったい何のために？
宇宙時代の技術で輝かしいことを成し遂げ、1999年より魔法のように素晴らしいアプリケーションを作っているのか？違う。相変わらずクソみたいな作業だ。
データベースから読み込み、データベースに書き込む。
そして出力形式を整え、HTMLを挿入する。
この複雑さと数多くの可動部品の中で、私たちは物事をより残酷なものにしてしまった。私たちはものをよくしているわけではない。

Rails World 2025 Opening Keynote - David Heinemeier Hansson

引用・参考文献一覧

Rails 8.1は顧客ごとにDBを分離できるマルチテナント対応に。オフライン対応、Markdownレンダリング搭載など新機能
DHHが語る、Railsの強みとは？Hotwireとの関係に迫る。- Forkwell
Hotwire光の道とStimulus
猫でもわかるHotwire入門 Turbo編
Rails World 2025 Opening Keynote - David Heinemeier Hansson