【ITニュース解説】Web Transition: Part 4 of 4 — The Return to Simplicity

Web開発の進化は、技術の進歩とともに常に変化してきた。かつてWebサイトのほとんどの機能はサーバーサイドで処理され、サーバーがページの表示内容を生成し、ユーザーからのリクエストに応じてページ全体を送り出していた。これが「Part 1: バックエンド中心」の時代である。

その後、Webの使い勝手を向上させる技術としてAJAXとjQueryが登場し、ページ全体を再読み込みすることなく、ページの一部だけを更新することが可能になった。例えば、掲示板の新しいコメントをページをリロードせずに表示するようなことができるようになったのだ。これは「Part 2: 部分更新」の時代と言える。

そして、Webアプリケーションはさらに進化し、SPA（Single Page Application）が主流となっていった。SPAでは、Webページを最初に一度だけ読み込んだ後、その後の画面遷移やデータのやり取り、表示の更新をすべてJavaScriptで行う。まるでパソコンのアプリケーションのようにスムーズな操作感を実現できるのが魅力だった。しかし、このSPAの時代は、フロントエンドのJavaScriptの役割が爆発的に増大し、ルーティング、データの検証、画面の描画といった多くの処理がフロントエンド側に移管された。これにより、JavaScriptのエコシステムは非常に複雑になり、「Part 3: SPAの複雑化」という課題を生み出した。

SPAは、スムーズな画面遷移やリッチなインタラクティブ性といったユーザー体験の向上に貢献したが、その代償も大きかった。例えば、HTMLのフォーム送信時にJavaScriptで挙動を乗っ取る必要があったり、データの取得や状態管理が複雑なフックで絡み合ったりした。ルーティングは完全にJavaScriptに依存し、データの入力検証（バリデーション）はフロントエンドとバックエンドの両方で二重に行う必要があった。

さらに、SPAでは、JavaScriptの読み込みと実行が完了するまでページが真っ白のまま表示されない「ハイドレーション」の問題や、大量のJavaScriptコード（バンドル）がダウンロードされることでページの表示速度や読み込み時間が遅くなる問題も発生した。検索エンジン最適化（SEO）に関しても特別な対策が必須だったり、ビルドプロセスが非常に複雑で壊れやすかったりした。このように、より良いユーザー体験を追求する中で、開発は難しくなり、Webサイトはかえって遅くなってしまうケースも少なくなかったのである。

そこで現在、Web開発は新たな転換期を迎えている。それは「シンプルさへの回帰」というアプローチであり、これまでのサーバー中心の考え方と、SPAで培われたクライアントサイドの技術を融合させることで、それぞれの利点を最大限に活かす方向である。この新しいアプローチは「サーバーファースト、クライアントスマート」と呼ばれ、サーバーに従来から得意としてきた役割、つまりルーティング、データの検証、データの処理、UI（ユーザーインターフェース）のレンダリングといった責任を再び与えることに焦点を当てている。

しかし、これは単に過去に戻ることを意味しない。私たちはJavaScriptを引き続き使用するが、その使い方はより選択的で、必要最小限に、そして賢明に行う。この考え方は「プログレッシブエンハンスメント（漸進的機能強化）」や「HTML-over-the-wire（HTMLを回線越しに送る）」とも呼ばれる。このアプローチにより、初期ページの読み込みが速くなり、ダウンロードするJavaScriptの量が減り、SEOが改善され、全体のアーキテクチャもよりシンプルになるというメリットがある。

この新しいバランスでは、サーバーとフロントエンドが明確な役割分担を持つ。サーバーは、フォームデータの受け付けと検証、ルーティングの処理、HTMLやJSONの返却、アプリケーションの状態管理とUIのレンダリングロジックを担当する。一方、フロントエンドは、ユーザーインタラクションの強化、fetch()などの機能を使ったフォームの送信、DOM（Document Object Model、Webページの構造）の要素を賢く更新するといった役割を担う。サーバーのロジックをフロントエンドで再実装することはしない。

これは、ページ全体が完全にリロードされる昔の方式に戻るわけではない。単に、ブラウザとサーバーがそれぞれ本来得意とする役割を担い、JavaScriptが必要なインタラクティブ性を補完するという形である。

具体的な例として、JavaScriptのfetch()機能を使ったフォームの拡張を見てみよう。一般的なHTMLフォームは、送信するとページ全体がリロードされてしまう。しかし、JavaScriptでこのフォームを少しだけ「強化」することで、ページのリロードなしにデータを送信し、サーバーからの応答をページの一部に反映させることができる。

例えば、enhanceFormという関数を使って、特定のフォームの送信イベントを傍受する。ユーザーがフォームを送信すると、JavaScriptが通常の送信処理をキャンセルし、フォームデータを取得する。そして、fetch()を使って、このデータをサーバーに非同期で送信するのだ。サーバーからの応答がHTMLであれば、そのHTMLを指定されたページ内の要素に挿入する。

この場合、サーバーはフォームの送信を受け取り、データの検証を行い、データベースにデータを永続化し、新しい情報を含むHTMLの断片（例えば、新しく登録されたユーザーのカード表示）をレンダリングして返す。フロントエンドのJavaScriptはそのHTMLを受け取り、既存のWebページ内の特定の場所を、サーバーから送られてきた新しいHTMLに置き換える。これにより、ユーザーはページ全体がリロードされたような感覚を持つことなく、コンテンツがスムーズに更新される体験を得られるのだ。

クライアント（ブラウザ）の役割は、SPA時代のようにすべてを抱え込むのではなく、あくまで「強化」と「補完」に留まる。クライアントは、モーダルの表示・非表示、入力フィールドの自動フォーカス、楽観的UIといった、ユーザー体験を向上させるためのUI（ユーザーインターフェース）強化を行う。また、fetch()を使ってフォームを送信し、ページ全体のリロードを防ぎ、ローディング表示を行い、HTMLスニペットを挿入したりJSONを処理したりする。

DOMの更新も、Reactの仮想DOMがコンポーネントツリー全体を比較して差分を反映させるのではなく、ページ内の特定のリスト、フォームの一部、メッセージ表示領域など、ピンポイントで必要な部分だけを更新する。これにより、処理はより正確で高速になる。ドロップダウンメニューの開閉、ドラッグアンドドロップ、キーボードショートカットなど、サーバーとの通信を必要としない純粋なクライアントサイドのインタラクションも、引き続きクライアントの責任である。さらに、ページ読み込み後にデータが必要になった場合でも、クライアントはfetch()を使ってAPIと通信できる。ただし、これを複雑なライブラリで管理する必要はない。

この「サーバーファースト、クライアントスマート」というアプローチは、理論だけでなく、すでに多くのモダンな技術スタックで採用されている。JavaScriptの世界では、Remix、SolidStart、SvelteKitといったフレームワークが、フォーム駆動でプログレッシブエンハンスメントを組み込んだり、サーバーレンダリングとスマートな強化を組み合わせたりしている。PHPのエコシステムでは、Laravel LivewireがHTML-over-the-wireでバックエンドロジックを駆動し、Inertia.jsがVue/Reactを使用しつつもバックエンドルーティングに依存する。HTMXは純粋なHTML-over-the-wire強化、Alpine.jsはサーバーレンダリングされたHTMLの上に軽量なインタラクティブ性を追加する。ASP.NETではBlazor Serverがサーバー駆動のコンポーネントとリアルタイムDOM更新を提供し、Razor Pagesとfetchの組み合わせもこの哲学に近い。

何年にもわたる実験と複雑化を経て、私たちはよりシンプルな真実にたどり着いた。それは、データ永続化、ルーティング、バリデーション、ビジネスロジック、レンダリングといったコアな役割はバックエンドが担い、DOM更新、フォームの強化、選択的なインタラクティブ性といったユーザーインターフェースの直接的な操作はフロントエンドが担うという、明確で合理的な分担である。

私たちは完全に過去に戻ったわけではない。むしろ進化を遂げたのだ。すべてをサーバーで処理するモノリシックなアプリケーションから、クライアントサイドに多くの機能を移管したSPAへ、そして今はサーバーとクライアントそれぞれの強みを融合させた、より賢いハイブリッドアプリケーションへと移行している。この結果、アプリケーションはよりシンプルに、より高速に、そしてより保守しやすくなり、Webは再びネイティブアプリケーションのようにスムーズで自然な感覚で使えるようになっていくのである。