WebSocketでHTMLを送る「HTML over WebSockets」：JavaScriptほぼ不要のリアルタイムSPA
HTML over WebSockets: real-time SPAs with barely any JavaScript
SPA開発の常識を覆す「HTML over WebSockets」パターンを紹介。サーバーがHTMLを組み立てて送信し、クライアントは配置するだけ。APIや契約が不要で、状態はサーバー側に保持。Phoenix LiveViewに始まり、Django LiveViewなど各言語に実装が広がる。WebSocketならではの双方向・低遅延・ブロードキャストが強みだが、サーバー負荷やオフライン非対応などの課題も。SSEやHTTPとの使い分けも解説。
クライアントはHTMLを適切な場所に配置し、イベントを待つだけ。サーバーが残りを処理する。クライアントの状態やレンダリングロジックを心配する必要はない。すべてはバックエンドにある。
HNでの議論
196- hackingonempty
> 簡単なルール：双方向で低遅延な通信が必要なら（チャット、コラボレーション、ゲーム）WebSocket、サーバーからプッシュするだけならSSEの方がシンプルで運用コストも低い。
ほとんどのアプリでは、WebSocket上でリクエストを送る独自のクライアントサイドJSを自作する代わりに、SSEとHTTPリクエスト用の組み込みコード（Fetch）を使うだけで十分だ。レイテンシは同じだ。なぜなら、現代のブラウザは開いたままの単一のTCP接続上でHTTPリクエストを多重化するからだ。
毎秒多数のクライアントリクエストを送るなら、各リクエストに完全なヘッダーやCookieなどを送らないことによる利点があるかもしれないが、ユーザーのクリックやタッチに応じてリクエストを送るだけなら、その利点はない。
十分に複雑なSPAは、Fetchの半分の機能を、場当たり的で、非公式に仕様化され、バグだらけで、遅い実装で含んでいる。
- xutopia
彼がこのテクニックの創始者としてクリス・マコードを挙げたのは面白い。しかし実際には、RailsのSyncでそれより前に存在していた。そして、そのSyncもクリス・マコードによるものだった。当時のRailsにはそれを処理する能力がなかったので、それは単なるテックデモに過ぎず、クリス・マコードがPhoenixに移った大きな理由でもあった。彼はかつて多作なRails開発者だった。その男がウェブを前進させているのだ。
- nchmy
この投稿への良い反応
- nzoschke
近いが、htmxとSSE、DOMスワップ、モーフィングを使えば、車輪の再発明をせずにそこに到達できる。
私が作るほぼすべてのWebアプリには、初日からこのパターンがある。なぜなら、それらはすべて、ワークフローとエージェントをサポートするために、リアルタイムの受信箱と通知サブシステムを持つようにすぐに拡張されるからだ。
- gwbas1c
このテクニックに反対する人の多くは、文脈を理解していない。問題に対する正しい解決策は、多くの場合、解決しようとしている問題を理解することを伴う。
私の場合、2つのBlazorウェブサイトで作業している。1つは標準的なブラウザ内WASMで、HTTP上のRESTful JSON（および一部CSV）を使用する。もう1つはサーバーサイドBlazorで、この記事で説明されているWebSocketテクニックを使用している。
サーバーサイドBlazorのアプローチは、以前はアドホックなデータベースクエリやアドホックなスクリプトを置き換えていた、迅速で間に合わせのページが多数ある社内Webアプリケーション用だ。これは「産業強度」のWebアプリケーションではなく、高いスケーラビリティを必要としない。なぜなら、使用するのはほんの一握りの従業員だけだからだ。また、作業するのが楽しい。具体的には、以前はスクリプトだったものの周りにUIをかぶせるためだけに、APIを設計し、コントラクトがシリアライズされることを確認するなどの作業を行う必要がない。
RESTful JSON（およびCSV）を使用するWASMページは、顧客向けのWebアプリケーションだ。JSON（およびCSV）はデバッグに役立つが、APIを作るコストは非常に高い。顧客向けウェブサイトの開発ははるかに遅いが、産業強度のサイトには「それだけの価値がある」。
WebSocket上でHTMLを使った高スケーラブルなウェブサイトを構築するだろうか？ たぶん。問題は市場投入までの時間だ。APIを構築する必要がないため、より速く進めることができるが、スケーラビリティの問題が発生するかどうかはわからない。
- aitchnyu
私は、DOMがデータの関数であるというVue/React/Svelteのモデルが好きだ。例えば、ショッピングカートでチョコレートを2つ追加すると、チョコレートの横の数字、上部のカウント、合計Xに達するよう促すバナーがすべてデータ構造を中心に展開される。
私はDjango Ninja、Zod、InertiaJS+Vueを使用しているが、Djangoのテンプレートエンジンを使うのと同じくらい簡単だ。しかし、静的型付けにより、ビューが表現できないデータを出力せず、TSが表現できないデータを受け入れず、Vue+TSがテンプレート内のロジックエラーを許可しないことが保証される。AIのおかげで簡単だ。繰り返すが、読み込まれたページはビューで提供されたデータの関数である。
HTMXでは、DOMを命令的に変更するために複数のサーバーサイド関数を書き、それらを呼び出すためにHTML属性を使用している。フォームには最適だが、そのショッピングカートの例では、複数の関数とテンプレートにコードを散らばせる必要がある。
- pjmlp
DHTML、ASP.NET Ajax、JSF Ajaxが再発明され続けているのが大好きだ。
- deepsun
> HTMLをそれに属する場所に置け
しかし、HTMLの一部を置き換える際に考慮されていない欠点がいくつかある：入力要素はフォーカスを失い、ビューがスクロールされていた場合はスクロールが解除され、ユーザーのポインターの下でジャンプするなど。