Webソフトウェアの未来はHTML-over-WebSocketだ

 (alistapart.com)
12 ポイント 投稿者 xguru 2021-03-02 | 7件のコメント | WhatsAppで共有

  • SPA + API + JSON は開発とリリースサイクルを遅くする

  • 双方向WebSocketを使うことで、サーバーレンダリング、高速なプロトタイピング、直感的なSEO、迅速な機能開発が可能だという主張

→ 変更されるHTMLまたは簡単なテキストをソケットで送信

→ クライアントの複雑な値検証やエラーオブジェクトの代わりに、サーバーが検証するようにする

→ ユーザーの接続有無は、ソケット接続が有効になっているかどうかでチェック

→ 複数ユーザーのチャットやドキュメント共同編集もすべて簡単にサポート

  • Railsの帰還: Turbolinks, Stimulus, StimulusReflex, CableReady, and GitHub’s ViewComponent

  • BasecampのHotwireも同じ技術

関連記事

7件のコメント

 
chanhee 2021-03-03

dotnet の server-side blazor も似たように動作している気がします。ただ、これを本番環境で実際に使ってみると、かなり面倒なケースを多く経験することになって…

Electron にサーバーとクライアントを両方載せて配布するのでなければ、特に利点はわからなかったですね。
 
kunggom 2021-03-04

もう少し具体的な使用経験について聞かせていただけますか？
 
andrewchaa 2021-03-03

しかし、APIエンドポイントはいったん作っておけばモバイル、Web、デスクトップのすべてで使えるので汎用性が高く、WebSocketを未来だと言えるのかは分かりませんね。
 
colus001 2021-03-02

Elixir Phoenix LiveView や RoR Stimulus Reflex も似たような概念ですね。

Chris McCord が Rails で作っていたものの、構造的な問題から Elixir に移行したという話もあります。
 
iolothebard 2021-03-02

ぐるぐる回す音…
 
xguru 2021-03-02

こういう主張もあるのだな、という感じで読むとよさそうです。

JavaScript がどこでも使われるようになって、SPA、SSR など何やら用語も増え、過度に複雑になったという点には同意します。

双方向処理ができるので、WebSocket は今後さらに活用されていきそうではありますが、私は Hotwire よりもっと使いやすい何かが出てくることに期待したいです。
 
galadbran 2021-03-04

（私の理解不足かもしれませんが）最近ちょっとおかしいと感じた点があって、React+LaravelのWebアプリでサーバー側だけが変更された場合、デプロイ内容はバージョン表記と変更されたコード数行だけなのに、フロントが変更されるとフロントアプリをビルドする必要があり、デプロイサイズも相対的にかなり大きくなって、なんだか笑ってしまうんですよね。緊急の一時的なカスタマイズ適用も難しいですし。以前の開発経験と比較してしまうから、そう感じるのかもしれませんが。