【ITニュース解説】Web Transition: Part 1 of 4 — The Original Web

Webが今日の形になるずっと前、インターネットの世界はもっとシンプルだった。私たちが今、当たり前のように使っているウェブサイトやウェブアプリケーションは、かつてどのように動いていたのか。この解説では、初期のWebがどのように機能していたのかを、システムエンジニアを目指す人にもわかりやすく説明する。

Webの初期段階では、ごく少数の基本的な技術が使われていた。まず、HTTPという「情報をやり取りするためのルール」があった。これは、ブラウザとサーバーが会話するための共通言語のようなものだ。次に、HTMLという「ウェブページの骨格を作るための言語」があり、文字や画像をどこに配置するかを決めていた。ページの見た目を装飾するためにはCSSという「スタイルを決めるための言語」が使われ、色やフォント、レイアウトなどを制御していた。そして、JavaScriptは、ごく軽いインタラクティブ性、つまりちょっとした動きをページに加えるために使われていたが、その役割は限定的だった。

これらの技術の中でも、特に重要な要素が二つあった。一つは<a>タグ、いわゆる「リンク」であり、これを使ってユーザーはページからページへと移動できた。もう一つは<form>要素で、これはユーザーが情報を入力してサーバーに送信するための「入力フォーム」を作るために使われた。

この初期のWebでは、現代のような「クライアントサイドのルーティング」や「ハイドレーション」、「JavaScriptによるレンダリング」といった複雑な技術は存在しなかった。ウェブページの表示やデータの処理、ユーザーとのやり取りのほとんどすべてが、サーバーからの応答によって行われていたのだ。

当時のウェブアプリケーションは、以下のようなシンプルなサイクルで動いていた。

第一に「データの永続化」だ。アプリケーションで扱うすべてのデータ、例えばユーザー情報や投稿内容などは、MySQLやPostgreSQLのようなデータベースに保存されていた。このデータの読み書きは、すべてバックエンド、つまりサーバー側が担当していた。

第二に「ルーティング」だ。ユーザーがウェブサイト上のリンクをクリックしたり、フォームを送信したりすると、ブラウザはHTTPリクエストをサーバーに送った。サーバーはこのリクエストを受け取ると、その内容に応じてどの処理を行うべきかを判断し、適切なプログラム（ハンドラー）に振り分けていた。

第三に「データ取得」だ。サーバーは、ユーザーのリクエストに応じてデータベースから必要な情報を読み込み、ウェブページを表示するための準備をしていた。例えば、ユーザーのプロフィールページを表示するなら、データベースからそのユーザーの情報を取得する、といった具合だ。

第四に「データの変更」だ。ユーザーが新しい投稿を作成したり、自分のプロフィールを更新したり、何かを削除したりするような操作（データの作成・更新・削除）を行うと、サーバーが直接データベースを操作し、データを書き換えていた。

第五に「レンダリング」だ。サーバーはデータベースから取得したデータと、HTMLのテンプレートを組み合わせて、完全に整えられたHTMLを生成し、それをブラウザに送り返していた。このHTMLの生成には、PHPやASP、あるいはRuby on Railsで使われるERBのような「テンプレートエンジン」がよく使われた。ブラウザは、この送られてきたHTMLをただ表示するだけだった。

第六に「ロジック」だ。ウェブアプリケーションのほとんどすべての処理、例えば「特定の条件が満たされたら違う表示をする」「このユーザーは編集権限があるかチェックする」「入力された情報が正しい形式か検証する」といった複雑な判断や計算（アプリケーションロジック）は、すべてサーバー側で実行されていた。

第七に「UIフィードバック」だ。ユーザーがフォームを送信した後、例えば「登録が完了しました」という成功メッセージや、「パスワードが間違っています」というエラーメッセージ、あるいは警告などは、サーバーが生成して送り返す新しいHTMLページの中に埋め込まれて表示されていた。つまり、何か入力するとページ全体が再読み込みされ、その新しいページに結果が表示されるという仕組みだった。

古典的なログインフローを例にすると、この仕組みはよく理解できる。まず、ユーザーがログインページ（例えば/login）にアクセスすると、サーバーはログインフォームを含むHTMLページをブラウザに返す。ユーザーがIDとパスワードを入力してフォームを送信すると、ブラウザはその情報を/authenticateというアドレスにPOSTリクエストとして送る。サーバーは、受け取ったIDとパスワードが正しいか確認し、正しければ「セッション」（ユーザーがログイン状態であることを示す情報）を設定し、次にユーザーをダッシュボードページ（例えば/dashboard）に移動させるよう指示（リダイレクト）する。するとブラウザは、改めて/dashboardにアクセスするためのリクエストをサーバーに送り、サーバーはダッシュボードのHTMLページをブラウザに返して表示する。この一連の動作には、JavaScriptや、フロントエンドでの状態管理、JSONといった現代の技術は一切使われていなかった。

今日の視点から見ると多くの制約があったこのシンプルなアーキテクチャにも、大きな強みがあった。一つは、すべてが線形に進むため「予測可能なフロー」だったことだ。また、最初からHTMLがサーバーで生成されるため、特別な工夫をしなくても「アクセシビリティ」や「検索エンジン最適化（SEO）」が自然と確保されていた。JavaScriptがなくても基本的な機能は動く「プログレッシブエンハンスメント」も、この設計の自然な特徴だった。さらに、複雑なJavaScriptのファイルをダウンロードしたり、それらが初期化されるのを待ったりする必要がなかったため、「初期ロードが速い」という利点もあった。

しかし、限界もあった。最も顕著だったのは、わずかな情報の更新でも「ページ全体が再読み込みされる」ため、ウェブサイトの動作が遅く感じられ、ユーザー体験がスムーズではなかったことだ。瞬時にエラーをチェックしたり、ページの一部だけを更新したりするような、現代のような「リッチなインタラクティブ性」は実現できなかった。また、より複雑で動的なアプリケーションを作る際には、開発者の作業効率（開発者エクスペリエンス）があまり良くなかったという側面もある。

要するに、初期のWebでは、ルーティング、データの保存と変更、そしてページのレンダリングに至るまで、すべての重要な処理がバックエンド、つまりサーバー側で一手に担われていた。ブラウザの役割は、サーバーから送られてくるHTMLをただ表示し、ユーザーの入力をサーバーに送信するだけだったのだ。それはまさに「ページからページへ」と遷移する世界だった。

なぜ今、こんなに昔の基本的な仕組みを振り返る必要があるのかと疑問に思うかもしれない。しかし、Webがどのように発展してきたか、その原点を知ることは、現代のWebの全体像を理解し、これからどこへ向かうのかを予測する上で非常に重要だ。

現在のWeb開発では、フレームワーク、コンポーネントライブラリ、クライアントサイドルーティング、ハイドレーション、部分的なデータ更新など、多様で高度な技術が使われている。しかし、根底にあるコアな責任、つまり「データの読み書き」「画面間の移動」「ユーザーインターフェースの表示」「ユーザーへのフィードバック提供」といった基本的な役割は、実は何一つ変わっていない。

変わったのは、これらの責任を、バックエンドとフロントエンドのどちらが、あるいは両者が分担して処理するようになったか、という点だ。初期のWebが、ほとんどすべての責任をサーバーに委ねていたことを理解することで、その後に起こった技術の進化や、現在のアーキテクチャの多様性をより深く理解できる。そして、このシリーズの今後の記事で見ていくように、将来のWebは、これらの初期の原則の一部を、現代の技術で強化しながら再び取り入れる方向に進む可能性もある。

この歴史を学ぶことは、Web開発の全体像を明確に理解することにつながる。過去のWebが経験してきた変遷を知ることで、私たちが今使っているツールや、これから構築するシステムについて、より賢明な選択ができるようになるだろう。