概要

• SPA開発 の従来手法とHTML over WebSocketsの比較
• HTML over WebSockets の仕組みと利点・欠点
• 既存フレームワーク の状況と用途別の選択指針
• SSEやHTTP との違いと使い分け
• フロントエンド・バックエンド統合 による開発効率化

HTML over WebSocketsによるSPA構築の新しいアプローチ

• SPA（Single-page Application） の伝統的構成はJavaScriptフレームワーク＋API（JSON）＋2つの独立コードベース
• HTML over WebSockets では、サーバーが組み立て済みHTMLを送信、クライアントは配置のみ担当
• レンダリングロジック はすべてバックエンド（単一言語）で完結、APIや契約不要
• このパターンは hypermedia または HTML over the wire と呼ばれる
• 通信方式 はアーキテクチャに大きな影響を与え、HTTP・SSE・WebSocketの3種類
  • HTTP：htmxやUnicornなど、リクエスト単位
  • SSE：Datastarなど、サーバーからクライアントへの一方向チャネル
  • WebSocket：Phoenix LiveViewやDjango LiveViewなど、双方向かつ常時接続

WebSocketsによるHTML over the wireの仕組み

• Chris McCord （Phoenix開発者）がElixirConf 2019でLiveViewを発表し話題に
• クライアント側のJavaScriptは レンダリング担当ではなく、WebSocketチャネルの維持やHTML配置 が役割
• サーバーは JSONではなくHTML を生成し、そのまま送信
• WebSocket を使うことで、常時接続・リアルタイムな双方向通信・サーバーからのプッシュが可能
• 従来のSPA（API＋JSON＋レンダリング）との比較
  • 従来：HTTPリクエスト→JSON受信→クライアントでHTML生成
  • WebSocket版：WebSocket経由でリクエスト→HTML受信→クライアントで配置のみ

HTML over WebSocketsのメリット

• レンダリングエンジン1つ で完結、複雑性削減
• API不要、契約や中間データ構造も不要
• 状態管理はサーバー側、各クライアントごとに状態を保持
• DBへ直接接続、JSONやGraphQLの中継なし
• リアルタイム性 が高く、ポーリング不要
• サーバーからのブロードキャスト （全クライアント同時更新）が容易
• 低レイテンシ・低トラフィック、TCPハンドシェイクやHTTPヘッダの繰り返しが不要
• 最小限のJavaScript でSPA構築、重いフレームワーク不要
• SEOにも一定対応、初回ロードのHTMLはインデックス化可能
• XSS耐性、サーバー側でHTMLエスケープ済み

HTML over WebSocketsのデメリット

• サーバーリソース増大、各クライアントごとにWebSocketと状態を保持
• 水平スケール時 は状態共有（例：Django Channels＋ASGI＋Redis）が必要
• 大量同時接続時 にリソース設計が重要
• 高レイテンシ環境 では「即時」感が損なわれる
• オフライン非対応、接続断時は利用不可
• 学習コスト、WebSocketサーバーやLiveViewパターンの理解が必要

主要フレームワークと現状

• Elixir ：Phoenix LiveView（WebSocket、成熟・1.x系）
• Ruby ：Hotwire（HTTP＋WebSocket/SSE）、Live/Lively（WebSocket、ニッチ）
• Python/Django ：Django LiveView、Reactor、djust（全てWebSocket）、django-unicorn（HTTP/AJAX）、Tetra（AJAX＋WebSocket）
• C#/.NET ：Blazor（WebSocket/SignalR）
• PHP/Laravel ：Livewire 3＋Reverb（WebSocket、2024年リリース）
• Agnostic（JS） ：htmx（HTTP＋WS/SSE拡張）、Datastar（SSE）

SSEやHTTPとの使い分け

• WebSocket ：双方向・低レイテンシが必要な場合（チャット・協働編集・ゲーム等）

• SSE ：サーバーからの一方向プッシュのみで十分な場合（ライブフィード・通知・ダッシュボード等）

• HTTP ：リクエスト/レスポンス単位で十分な場合やシンプルなWebアプリ

  • SSEの特徴
    • 一方向通信のみ、クライアントからの送信は別HTTPリクエストが必要
    • テキストのみ（バイナリ非対応）
    • 高頻度の双方向や重いやりとりには不向き
    • htmxやDatastarなど、SSE利用のフレームワークも存在

まとめと指針

• HTML over WebSockets は万能解ではないが、用途によっては非常に有効
• 要件ごとに最適な通信方式 （WebSocket, SSE, HTTP）を選択
• HTMLを直接送るアーキテクチャ で、APIや契約、フロントエンドの複雑性を大幅削減
• トレンドや流行のフレームワーク よりも、問題に適した堅実な設計が重要

参考資料

• Phoenix LiveView公式ドキュメント
• Phoenix LiveView 1.0リリース記事
• Hotwire公式サイト
• htmxドキュメント
• Turbo Handbook
• idiomorph（DOMモーフィングライブラリ）
• Datastar（SSE型ハイパーメディアフレームワーク）
• MDN: Using server-sent events
• Laravel Reverb（2024年リリース）