なぜフロントエンドが必要なの? 〜Web進化の歴史〜

学習シリーズ

Reactを学ぶ前に、そもそもなぜ「フロントエンド」という分野がWeb開発において重要視されているのでしょうか?

その理由は、Webの歴史と「ユーザー体験」の進化にあります。

初期のWebサイトと現代のWebアプリでは何が違うのか。
その仕組みの変化を追いながら、フロントエンドの役割を整理していきましょう!


初期のWebサイト(静的サイト)の時代

初期のWebサイトは、あらかじめ用意されたファイルをそのまま表示する仕組みでした。これを 「静的サイト」 と呼びます。

静的サイトは、とてもシンプルな流れで表示されます。

表示の流れ

  1. ブラウザ(ユーザーの画面):サーバーにページを要求する(リクエスト)
  2. サーバー :保存してあるHTMLファイルをそのまま返す(レスポンス)
  3. ブラウザ :HTMLを読み取って画面に表示する
ブラウザがサーバーにページを要求し、保存されているHTMLファイルがそのまま返される仕組みの図解

このように、静的サイトはサーバーは特別な処理を行わず、
ファイルをそのまま渡すだけです。

サンプルコード

<!DOCTYPE html>
<html>
<head>
<title>初期のサイト</title>
</head>
<body>
<h1>こんにちは!</h1>
<p>これはサーバーに置かれた固定のHTMLファイルです。</p>
</body>
</html>

誰がいつ見ても内容は同じで、常にファイル通りの情報が表示されます。

これは例えるなら、印刷されたパンフレットのようなものです。
決まった情報を正確に届けることが、当時のWebの役割でした。


掲示板やSNSの登場(動的サイト)の時代

やがて掲示板やSNS、ECサイトのように、
情報が頻繁に更新されるサービスが登場します。

すると、事前にHTMLを用意しておく方法では対応できなくなりました。
そこで生まれたのが、アクセスのたびにサーバー側でHTMLを生成する 「動的サイト」 です。

動的サイトでは、サーバーが状況に応じてページを作り直します。

表示の流れ

  1. ブラウザ :「最新データ」を要求する
  2. サーバー :プログラムを実行し、データベースから情報を取得する
  3. サーバー :取得したデータをHTMLに埋め込み、その場でHTMLを生成する
  4. サーバー :完成したHTMLをブラウザへ返す
  5. ブラウザ :HTMLを読み取って画面に表示する
ブラウザの要求に対し、サーバーがデータベースから情報を取得してその場でHTMLを生成し、ブラウザへ返す仕組みの図解

このように動的サイトは、HTMLは事前に用意されているわけではなく、
アクセスされた瞬間にサーバー側で生成されています。

サンプルコード

<!DOCTYPE html>
<html>
<head>
<title>動的なサイト</title>
</head>
<body>
<h1>最新の投稿一覧</h1>
<ul>
<!-- ① サーバー側でデータを埋め込む場所 -->
<!-- 例:post1 = "ユーザーA:今日はいい天気ですね!(10:00)" -->
<li>{{ post1 }}</li>

<!-- 例:post2 = "ユーザーB:Reactの勉強を始めました!(10:05)" -->
<li>{{ post2 }}</li>
</ul>
</body>
</html>

この仕組みにより、
・ユーザーごとに内容が違うマイページ
・常に更新されるニュース一覧
といった「最新状態のページ」を表示できるようになりました。

しかしこの方式には、ユーザー体験の面で大きな弱点がありました。


動的サイトが抱えていた課題

動的サイトでは、たとえ1箇所の情報を更新するだけでも、ページ全体を作り直して再読み込みする必要がありました。

その結果、
・通信量が多く、表示が重い
・更新のたびに画面が白くなる
・操作のたびに待ち時間が発生する
といった問題が起きます。

例えば、いいねボタンを押すたびにページ全体が再読み込みされる……。
今の感覚だと、かなりストレスのある挙動ですよね。

この課題を解決するために登場したのが、JavaScriptによるフロントエンド処理です!


JavaScriptによるフロントエンドの進化

JavaScriptの登場により、ブラウザ側でページの一部だけを書き換えることが可能になりました。

これが、現代のフロントエンド開発の出発点です。

表示の流れ

  1. ブラウザ :サーバーへ「必要なデータだけ」を要求する
  2. サーバー :データベースから情報を取得し、JSON(データ交換用の軽量な形式)として返す
  3. ブラウザ :JavaScriptがそのデータを処理し、画面の一部だけを書き換える
ブラウザが特定のエンドポイントからJSONデータのみを取得し、JavaScriptで画面の一部だけを更新する仕組みの図解

このように、サーバーはページ全体を作るのではなくデータだけを返し、表示の更新はブラウザ側で行われます。

サンプルコード

<!DOCTYPE html>
<html>
<head>
<title>モダンなサイト</title>
</head>
<body>
<!-- ① 投稿一覧を表示する場所 -->
<ul id="post-list">
<li>読み込み中...</li>
</ul>

<script>
// ② サーバーへ投稿データを要求する
fetch('/api/posts')

// ③ 受け取ったレスポンスをJSON形式に変換
.then(response => response.json())

// ④ JSONデータを受け取って画面を書き換える
.then(posts => {

// ⑤ 表示先の要素を取得
const list = document.getElementById('post-list');

// ⑥ 配列データをHTMLのリストに変換して反映
list.innerHTML = posts.map(text => `<li>${text}</li>`).join('');
});
</script>
</body>
</html>

このようにJavaScriptを使うことで、ページ全体ではなく一部だけを更新する仕組みが実現し、Webの操作性は大きく変わっていきました。


JavaScriptがもたらした変化

JavaScriptによって、ページ全体を読み込み直さなくても、必要な部分だけを更新できるようになりました。これによって、Webの操作性は大きく向上しました。

✔ 通信量の削減
ページ丸ごとではなく、必要なデータだけを取得する

✔ スムーズなUI
ページを再読み込みせず、操作に応じて画面を更新できる

✔ 非同期処理
裏側でデータを取得し、準備ができたら画面に反映できる

こうした仕組みにより、Webは単に情報を表示するためのページではなく、ユーザーの操作に応じて動作する仕組みへと発展しました。
そして、この体験を支える役割を担うのがフロントエンドです。


まとめ

Webがどのようにして現在のような操作性を持つ仕組みへ発展してきたのか、その流れが見えてきたかと思います。

\\ 今回のまとめ //

昔のWebは、HTMLを丸ごと読み込む「文書中心」の仕組みだった
動的サイトは便利だが、再読み込みによるUXの課題があった
JavaScriptにより、画面の一部だけを更新できるようになった

Webは「文書」から「操作できるツール」へと進化しました。
この変化を支えているのがフロントエンド技術です。

次は、このフロントエンド開発を効率化する仕組みとして、
なぜReactのようなライブラリが必要になったのかを見ていきましょう♬*°

コメント

タイトルとURLをコピーしました