Hotwire: HTML over the wire技術

 (hotwired.dev)
2 ポイント 投稿者 GN⁺ 2024-06-03 | 1件のコメント | WhatsAppで共有
  • Hotwireは、JSONの代わりにHTMLを送信して最新のWebアプリを作るアプローチで、多くのJavaScriptなしでも高速な初回ロードと高い応答性を狙う
  • レンダリングをサーバーテンプレート側に残しておくため、使用する言語に関係なく開発フローをシンプルに保てる
  • 37signalsがHEYのために作ったフレームワーク群は組み合わせて使うことで、Webから複数のプラットフォームまでつながるHotwireエコシステムを構成する
  • 中核コンポーネントであるTurboは、ページ遷移、フォーム送信、コンポーネント分割、WebSocketベースの部分更新をJavaScriptを書かずに処理する
  • Turboだけでは足りないカスタムな相互作用はStimulusが補い、Hotwire Nativeは既存のWebアプリをもとにネイティブモバイルアプリを作れるようにする

HTMLをサーバーでレンダリングして送るアプローチ

  • Hotwireは、HTML-over-the-wire方式で最新のWebアプリケーションを構築する代替的なアプローチ
  • JSONの代わりにHTMLをネットワーク越しに送信し、多くのJavaScriptなしでアプリケーションを作れるようにする
  • 高速な初回ページロード、サーバーサイドのテンプレートレンダリング維持、よりシンプルで生産的な開発体験を目指す
  • 従来のシングルページアプリケーションで期待される速度と応答性を諦めない方向性
  • HTML-over-the-wireは独自ツールを作るための参考手法として使うこともでき、37signalsがHEYのために作ったHotwireフレームワーク群をそのまま使うこともできる

Turbo、Stimulus、Hotwire Nativeの役割

  • TurboはHotwireの中核コンポーネント
    • ページ遷移とフォーム送信を高速に処理する補完的な手法を提供する
    • 複雑なページをコンポーネントに分割し、WebSocketで部分的なページ更新をストリーミングする
    • これらの機能をJavaScriptを書かずに提供する
  • Stimulusは、Turboだけでは十分でないカスタムコードが必要なときに使われる
    • Turboは、従来JavaScriptが必要だった相互作用の少なくとも80%を通常処理する
    • Stimulusは、状態と接続をHTML中心の方式で扱えるようにする
  • Hotwire Nativeは、ネイティブモバイルアプリを作るためのWebファーストなフレームワーク
    • 既存のWebアプリを活用してモバイルアプリを構築するために必要なツールを提供する

関連記事

1件のコメント

 
GN⁺ 2024-06-03
Hacker News の意見

  • この機能のあまりマーケティングされていない版として htmx がある: https://htmx.org/
    JavaScript ファイル1つでこうした機能を可能にしてくれる。主に Go バックエンドと組み合わせて使われているのをよく見たが、かなり柔軟そうに見える。1年ほど前から一度使ってみようと思っていた

    • 少なくとも Hacker News 基準では、htmx のほうがはるかに露出が多いと思う
      この1年だけでも HN への投稿が数百件あり 0、1000点を超えた記事もあった。一方 Hotwire はこの1年の投稿が30件にも満たず 1、その中で最も人気があるのがこの記事
    • htmx があまりマーケティングされていないというのは理解できない。Hotwire は初耳だが、htmx はあちこちで見かけすぎる
      YouTube を少し見るだけでも、プログラマー系インフルエンサーたちが顔サムネイル付きで htmx をずっと推しているレベル
    • ほかの機能も含む https://unpoly.com も言及に値する
    • HTMX はどのフレームワークよりもマーケティングがうまくいっている部類かもしれない
      Twitter も非常に活発で、The Primeagen の YouTube チャンネルにもよく登場し、かなり人気がある
    • あまりマーケティングされていない？ あらゆるソーシャルプラットフォームで htmx があふれている感じがする

  • PHP/Laravel で似たものを探しているなら、Livewire を強くおすすめする: https://laravel-livewire.com/
    より複雑なプロジェクトでは今でも React を使うが、リアクティブな UI 要素を保ちながら Blade/PHP だけで全部書けるのはいつも新鮮だ。必要なときに Livewire の中で React/Vue コンポーネントをレンダリングできるようにするパッケージも見た覚えがある: https://minglejs.unitedbycode.com/。既存パッケージを引っ張ってこなければならないときの興味深い脱出口に見える

  • 以前は Hotwire/Livewire にかなり否定的だったが、今では状況に応じたツールだと思っている
    ワイヤ越しに部分テンプレートを送るのはハイパーメディア方式であり、最近はハイパーメディアアプリをうまく作らなくなっているだけだ。htmx と RTF の REST 論文を読み返すうちにここまで来た。ハイパーメディアが本質的により優れたアーキテクチャだとは思わないが、複数の選択肢の中の正当な仲間であり、ゆっくりでも進化し続けているのは良いことだ

  • React/Vue/Svelte の沼にハマらずに PWA を作る最も簡単な方法に近い
    それらも使ったことがあるし素晴らしいと思うが、htmx と比べると、技術中心というより開発者体験中心のように感じる。両者の競争は結局、どのバックエンドフレームワークとうまく統合できるかにかかっていそうだ

    • モバイルアプリが単なる WebView ならそうかもしれない。そうでなければ、モバイルアプリ用の REST API と、HTML 断片を渡す Hotwire/Livewire のリクエストハンドラの両方を維持しなければならない
      個人的には PWA はクライアント側の問題であり、サーバー依存を追加せずクライアント側で処理すべきだと思う
    • この方式が挙げられた代替案より沼ではない理由が何なのか気になる

  • これが最初に出た時期により近い、2020年の HN での会話はこちら: https://news.ycombinator.com/item?id=25507942

  • ほぼ一周して戻ってきたような感覚がある。2005年か2006年ごろ、クリックを横取りしてパラメータを付け、レンダリング済みの HTML の部分断片だけを受け取って .innerHTML で本文を差し替える方式を使っていた記憶がある

    • 2000年代初頭、AJAX が出てくる前に、Adam Rifkin が自分のスタートアップ KnowNow のデモを見せてくれた。当時は、Web ページがリロードなしで自動更新されるのが衝撃的だった
      コツは HTTP リクエストを開きっぱなしにして、サーバーが時々更新を送ることだった。その更新も HTML だった。当時は DOM 操作すらできなかったかもしれないので、文字どおり閉じないタグのあるページだったのかもしれない
    • 一周したというより、別々の Web UI パラダイムが適用範囲を広げていると見るほうが正確だと思う
      サーバーレンダリングのフレームワークはクライアント側のインタラクションをより簡単にしているし、React は RSC によってサーバーレンダリングをより簡単にしている。非常にインタラクティブな Web アプリなら、依然として SPA が有利
    • Hotwire や類似ライブラリが話題になるたびにこういう話を聞くが、現実には AJAX ベースの単純な CRUDが消えたことはない
      SPA プロジェクトは非常に多いとはいえ、それが世の中のすべての Web サイトを説明するわけではない
    • https://animasci.com/ で似た方式を使っている
      ページネーションは、スクロールして「Show more」を押すと、サーバーから次のページを HTML 断片としてリクエストし、見えない iframe にロードして、ロード完了後に現在のページへ追加する形で実装した
    • 2000年代後半には Wicket がかなり好きで JavaScript は嫌いだったが、サーバー側で UI 状態とテンプレートを管理するのは、チーム環境では性能とスケーラビリティ面の落とし穴になりがちだった
      その間に Web、JavaScript、TypeScript が大きく良くなったことを考えると、このアプローチに再び興奮するのは難しい

  • 高度にインタラクティブなフロントエンドを必要とする Web アプリはあまり扱ってこなかったが、EC ストアや社内 Rails アプリでは、Turbo と Stimulusが新しい開発者が学ぶべき量を大きく減らしてくれた

    • スタックをシンプルに保てば、もともとそこまで難しいものではなかった
      たとえば、ある Django プロジェクトでは、実績のある KnockoutJS を使ってオフィス用ツールを丸ごと素早く作ったが、これは HTMX の精神ともある程度通じるものがある。まだ初期段階の Arrow.JS も似ている。複雑さ、特に UI 側の複雑さは、たいてい自分たちで作り出したものだった。古いやり方はまったく時代遅れではなく、むしろ戻ってきている。業界が、あらゆる Web アプリケーションを過度に複雑で耐えがたい塊にしなければならないと説得していた、最も愚かな時期に入門した若い開発者世代がいる
    • Stimulus を使った立場から言うと、Stimulus はひどかったので二度と使わない。Hotwire は悪くなかった

  • Hey はローンチ時から有料で使っているが、Hey の Web アプリ体験が Hotwire の最高事例だというなら遠慮したい
    遅い接続では良くない。開発者がローディング状態やエラー状態を入れていないせいかもしれないし、複雑性が高いせいかもしれないし、Hey のバグかもしれない。分からないが、良くはない
    中〜高レイテンシでは、動作が予測不能だったりバグのように感じたりする。中身のないボックスが開き、リンクが期待どおりに動かず、複数の操作を素早く連続で行ったときに直感的な形で中断されない。単にズレている感じがする
    SPA がどれほど悪いとしても、これは UI がネイティブで自然に感じられる方向から一歩遠ざかったように思える

  • この記事が今また浮上した理由は、先週、誰かが Hey のモーダルを開く速度が遅いと投稿したため: https://x.com/noahflk/status/1795758603577545035
    Hey は DHH が作り、DHH は Hotwire と Rails も作った。その後、元の動画は制限されたネットワークで撮影されたという DHH の反論、モーダルのロードに時間がかかるなら Hotwire はネットワークに依存しすぎているという反応、Rails/Hotwire 擁護、このアプローチへの反対などが入り混じり、熱い議論になった。先週の Twitter で大きな話題だった

    • DHH が元の動画は制限されたネットワークで撮影されたと言ったのは正しい
      投稿者も「デモのために意図的に遅くした」と書いている: https://x.com/noahflk/status/1795855075526471915。「サンフランシスコの良い MacBook とギガビットインターネット」を使う人の体験を見せたかったのではなく、遅いモバイルインターネットと安いノート PC を使う人の話をしたかったのだという。Google Calendar の SPA のほうがずっと遅いという指摘もあり、「サンフランシスコのギガビットインターネット」と「強く制限された 3G」だけが選択肢というわけでもない。元の投稿は非常に誤解を招く内容で、実質的には嘘に近かった
    • DHH の直接の回答リンク: https://x.com/dhh/status/1796163806650868149
    • 約1年前に Hey を見たときは、太平洋の反対側からでもかなりきびきびして見えた
      特にページ構造が印象的だった。たとえばコンテキストメニューのオーバーレイに details/summary/anchor の組み合わせをプログレッシブエンハンスメント方式で適用しており、JavaScript をオフにしたりアセットがロードされなかったりしても、単純なレイアウトでメニュー内容を上品に読み込むようになっていた。そのほかにも Web API を慎重に使っている部分が多く、クライアントコードもほとんど難読化されておらず、ソースマップが付いていた記憶がある。DHH のファンでもないし、その週の騒動を追うつもりもないが、今回は 37signals がうまくやったと感じた
    • すでに修正済み。更新はこちらで確認できる: https://x.com/dhh/status/1797370923391357143

  • 同じアイデアをよりミニマルに実装した Swap JS を2年前に作った: https://github.com/josephernest/Swap
    いくつかのプロジェクトで使ってみたが、うまく動いている