12/23の朝方、DHHが以下のツイートを発信しました。
Hotwire aka NEW MAGIC is finally here: An alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire. This includes our brand-new Turbo framework and pairs with Stimulus 2.0 😍🎉🥂 https://t.co/Pa4EG8Av5E
— DHH (@dhh) December 22, 2020
取りあえず様子を知りたかったのでDHHのツイートを追ってみました。お気づきの点がありましたら@hachi8833までお知らせください🙇。
⚓ Hotwireとは
サイト: HTML Over The Wire | Hotwire
上のツイートの要点は以下のとおりです。
- Hotwireは、モダンなWebアプリケーションを構築する新しい手法
- JavaScriptの利用を抑える
- JSONではなくHTMLを送信する（HTML over the wire）
- 先ごろリリースされたStimulus 2.0を利用する
- 新しい「Turbo」フレームワークを取り入れている
StimulusStumulusが2.0になったことで、Stimulusサイトもhotwire.devのサブドメインに移行したようです↓。
サイト: Stimulus: A modest JavaScript framework for the HTML you already have.
Hotwireはhey.comでも使われているそうです。
- Basecampが開発運営しているhey.comのフロントエンド構築のすべてがHotwireに注ぎ込まれている
- 数年がかりの研究や実験
- HTML中心のリリース
- Webの他にBasecampのネイティブアプリにも使う
なお、hotwire.devページの下の方を見ると「Strada」というものも2021年にリリースされるそうです。Stradaについてまだ具体的な記載はありません。
⚓ Hotwireの構成
BTW, this release includes two new JavaScript libraries, three new Rails gems, two different native adapter integrations, three different websites, new organizations on GH and NPM, or 13(!!) new repos in total 😄 https://t.co/z29MrLOjN2
— DHH (@dhh) December 22, 2020
GitHubに新たに作成された上のHotwiredアカウントには、現時点で以下を含む13個のリポジトリがあります。
- 新しいJavaScriptライブラリ: 2つ
- 新しいRails gem: 3つ
- デモWebサイト: 3つ
AndroidやiOS向けのTurboもあるんですね。
⚓ デモ動画やリポジトリ
以下で公式のデモ動画やデモアプリケーションのリポジトリも公開されています。ちなみにしっかりRails 6.1が使われています。
I also pushed out the repository from the screencast that shows just how little code is needed to make this all tick. It's pretty shabby though. Please help me polish it up! https://t.co/SufIHIlXKU
— DHH (@dhh) December 22, 2020
gorails.comが早くもHotwireのスクリーンキャストを公開しています。
⚓ Turbo
That Turbo framework is a set of complimentary techniques for speeding up page changes and form submissions, dividing complex pages into components, and stream partial page updates over WebSocket. All without writing any JavaScript at all. https://t.co/fatmjrUIdm
— DHH (@dhh) December 22, 2020
Turbo: The speed of a single-page web application without having to write any JavaScript.
- Turboはフレームワーク
- Turboはページの動的な変更やフォーム送信を高速化する
- Turboは複雑なページをコンポーネントに分割し、WebSocket上でパーシャルページの更新をストリーム化する
- TurboではJavaScriptをまったく書く必要がない
⚓ FAQ
DHHのツイートがFAQ的なので、拾ってみました。
What used to be Turbolinks is now Turbo Drive, one of several techniques included in Turbo. https://t.co/uRdzfqPsJI
— DHH (@dhh) December 22, 2020
- Q: Tubroは新しいTubolinksなのか？
- A: 以前TurbolinksだったものがTurbo Driveになった。Turbo DriveはTurboに盛り込まれているさまざまな手法のひとつだ。
Any framework with a job queue, web socket manager, and template rendering can do what we do in Rails. pic.twitter.com/Q8EQM1xRnm
— DHH (@dhh) December 22, 2020
- Q: HotwireはRailsと密結合するのか、それともバックエンドフレームワークを選ばないのか？
- A: 「ジョブキュー」「WebSocketマネージャ」「テンプレートレンダリング」を備えるフレームワークならRailsのHotwireと同じことができる。
No. We use WebSockets in HEY and Basecamp, and have for years. But also, generally, treat it as a progressive enhancement. So if it's not there, it's just not live, not broken.
— DHH (@dhh) December 22, 2020
- Q: WebSocketで何か困難があったかどうか知りたい。特に、WebSocketコネクションが許可されない企業環境やモバイル環境ではどうか？
- A: 困難はない。WebSocketはHEYやBasecampで何年も普通に使われている。ただし、一般にはプログレッシブ表示の機能拡張として使う。そうすればWebSocketが使えない場合は単に動的でなくなるだけで、壊れたりはしない。
It’s not a thing. We have many tens of thousands of active web socket connections for Basecamp. We don’t have tens of thousands of servers 😄
— DHH (@dhh) December 22, 2020
- Q: HEYやBasecampがHotwireで更新されたことで、Action Cableを介したWebSocketのスケールはどのぐらいうまくやれるのか？Hotwireを採用するうえで、Webサイトに数百人がアクセスした場合に単体のWebサーバーのメモリが枯渇しないかどうかが唯一気になる点だ。
- A: 特に問題ではない。BasecampのWebSocketコネクションは数万個に達しているが、数万台のサーバーなど使っていない。
HEY used to have five different channels. Dumped them all once we hit the spot with Turbo Streams. So: Yes 😄
— DHH (@dhh) December 22, 2020
- Q: 既存のAction CableチャネルをTurbo Streamsで置き換えられるか？
- A: HEYでは5つのチャネルを使っていたが、Turbo Streamsが最適だったので既存のチャネルはまとめて廃止した。したがって答えはイエス。
Normal HTML. No virtual dom. No diffing. Just browsers doing what they’re built to do!
— DHH (@dhh) December 22, 2020
- Q: ページのコンテンツは「通常の」HTMLドキュメントとしてビルドされるという理解でよいか？それとも影でまた面倒なDOMが糸を引いているのか？
- A: 通常のHTMLで合っている。バーチャルDOMも
ドリフティングdiffing（差分検知）も存在しない。ブラウザは普通どおりに動く。
追記（2020/12/24）ご指摘を受け誤訳を訂正しました。ありがとうございます！
For frames, it's already there. https://t.co/SNQjOR6H7k pic.twitter.com/tCosajVt75
— DHH (@dhh) December 22, 2020
- Q: フェッチにちょっと時間がかかりそうなときに使えるオプションのローダーはあるか？
- A: フレームになら既にある: Turbo Handbook: Decompose with Turbo Frames
It’s the triumph of turbolinks!
— DHH (@dhh) December 22, 2020
- Q: Turbolinksは死んじゃうの？
- A: Turbolinksが勝利したのです。
⚓ ruby-jp Slackやツイートより
Hotwireに似たものとして、Laravel LivewireやPhoenix LiveViewがあるようです。
・似たような技術としてはPhoenix LiveView(Elixir)やLaravel Livewire(PHP)がある
・JSONではなくHTMLを直接送り付ける
・通信にWebSocketを使う— おんがえし (@ongaeshi) December 23, 2020
view_componentとHotwireの関係はどうなるのだろうという書き込みもruby-jp Slackで目にしました。
同じくruby-jp Slackで、Hotwireと前後して発表されたReact Server Componentsも見かけました。
参考: Introducing Zero-Bundle-Size React Server Components – React Blog
以下のツイートも目にしました。
#RubyWorld の DHH & Matz インタビューで挙げられた『１つのシステムでアプリ全体を作りたい』という話と、今回リリースされた『Hotwire』を見ると、点と点がつながっていく感じがある 👀💭
DHH & Matz インタビュー https://t.co/9cgMW8DCSu
Hotwire - HTML over the Wire https://t.co/N65CaRykdd https://t.co/gfeSK8sKGc
— 安川要平/Yohei Yasukawa (@yasulab) December 23, 2020
少し前にQuoraでMatzの回答に以下の文がありましたが、今思えばHotwireのことだったのかもしれないとruby-jp Slackで見かけました。
参考: (177) Rubyやrailsは今後革新的な進化をする事はあるのでしょうか？それとも、安定・停滞していくのでしょうか？に対するYukihiro Matsumotoさんの回答 - Quora
こないだDHHと話したら「フロントエンドを簡単に記述することができるアプローチにアイディアがある」って言ってました。私はAPIでフロントエンドとバックエンドを分離するのかと思っていたので、ちょっと意外でした。
jp.quora.comの同回答より
⚓ 最後に
上述のデモアプリのGemfileにはWebpackerが含まれていませんでした。
その後でDHHの以下のツイートを見つけました。HotwireではWebpackは必須ではなく、アセットパイプラインをWebpackで置き換えることもできるんですね。
You can absolutely use Hotwire with Webpack without the asset pipeline. I’m just excited that Webpack is now optional.
— DHH (@dhh) December 23, 2020
- お知らせ: TechRachoではRubyやRailsの最新情報などの記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます（例:週刊Railsウォッチ）
morimorihoge注
「JSONではなくHTMLを送信する」について
近年のフロントエンド開発ではサーバーサイドはHTMLを返さずJSONデータを返すAPI/GraphQLサーバーとしての動きを期待され、HTMLを作成するのはブラウザ側のJavaScriptで行う方式が主流となっています。
一方で、フルスタックフレームワークとしてのRailsのフロントエンドはHTMLの生成をサーバーサイドで行うという方式を採用しているため、根本的に設計思想が異なるという点に注意が必要です。
※API mode等でRailsを単なるAPIサーバーとして使うことはできますので、こうしたRails提供のフロントエンドライブラリの利用はRailsを使う上で必須というわけではないことを付け加えておきます。