Hotwireの良かった点、辛かった点、向いているケース、向いていないケース - 猫Rails

（自分はRailsを書くことが多く、フロントエンドの経験は乏しいです。見方にだいぶ偏りがあると思いますので、そのあたり差し引いてお読みいただければと思います〜🙇‍♂️） こんにちは〜。Hotwireを仕事で使う機会があったので、実際に使ってみて感じた、良かった点、辛かった点、向いているケース、向いていないケースを共有します〜。 Hotwireとは？ Turbo Driveとは？ Turbo Framesとは？ Turbo Streamsとは？ Stimulusとは？ Hotwireのデモ 良かった点 サーバーサイドに集中できる Railsの資産をフルに活かせる 後付けで段階的にSPA風の挙動を追加できる 学習コストが低い 開発コストが低い WebSocketは必須ではない 辛かった点・辛くなりそうな点 DOM更新時にレスポンスを待たないといけない SPAのユーザー体験とはだいぶ違う He

[masatomo-m]

とてもわかる。Server-Side-Heavyな業務アプリ（内部でRDBMSを使い大きなトランザクションを必要とするようなもの）だとこれくらいのSPA感で十分喜ばれると思う

[gabill]

“SPAの2割の労力で8割の利益を取りに行くのがHotwireだと思います”

[motchang]

“最終的にSPAにするからという理由で最初からSPAを作るのは、場合によっては仮説検証のサイクルを回す速度を落としてしまう可能性があります” はい。

[akymrk]

“HotwireはRailsの受託会社にとてもハマる技術”

[iga_k]

shita さんの良いまとめ！

[mizdra]

めっちゃ良い

[YassLab]

"自分が関わる案件だとこれで十分なことが殆どで、まさにこういうものが欲しかった / ただ、ReactやNextで実現できるようなユーザー体験とは差があります。SPAの2割の労力で8割の利益を取りに行くのが #Hotwire だと思います"

[vottie]

hotwireについて

[yo_waka]

めちゃよいまとめ。違和感や不自由なものがある人は使わない方がいいし、そうでない人にはちょうどいいツール

[efcl]

TurboだけだとOptimistic Updatesがやりにくいという話

[iwasiman]

Rails+フロント開発のフロント部分をラップするような仕組みらしい。確かに世のトレンドの逆方向を向いてる感はありますが、こういうアプローチもあるんですね。

[circled]

レスポンスはReact/Vueの方が断然速い。React/Vueできる人はそっちの方が幸せなんだけど、Railsは「個人や小さなチームが世界を変えれる」的なフレームワークなので、SPAの2割の労力で済む存在の方が設計思想に合ってるのよ。

[patorash]

Hotwireが向いている規模が、Railsの向いている規模になっていくと考えている

[onesplat]

こんな妙なことするくらいならMPAでいいんじゃないのかね。管理画面でしょ。

[razokulover]

小さめチームで受託開発くらいに向いてるというのはなんか分かる気がする

[kazuph1986]

少なくともこの方のように特定の開発者がピッタリの機能だと思ってるなら、成功と言えるのではないかと思った。