フロントエンドフレームワーク詳細ガイド

はじめに

HTML、CSS、JavaScript の基礎を学び、簡単な Web ページを作れるようになりました。しかし、Web ページの機能が複雑になるにつれて、気づくことがあるでしょう。生の JavaScript でコードを書くのは保守が難しく、一箇所の変更が多くの場所に影響し、複数人での共同作業では頻繁にコンフリクトが発生します。

これがフロントエンドフレームワークが必要な理由です。コードを整理し、保守しやすく、効率的に開発できるようにしてくれます。vibecoding では、AI がほとんどのコードを書いてくれます。しかし、少なくとも異なるフレームワークのコードスタイルを読み取れ、それぞれの長所短所を理解していれば、AI が最適な技術スタックを選ぶ手助けができます。

この記事を読めば、次のことができるようになります：

フロントエンド技術がなぜ進化し続けるのかを理解する
Vue、React、Svelte、Angular の各特徴を知る
「データ駆動」「コンポーネント化」といったコア概念を理解する
プロジェクトに応じて適切なフレームワークを選べる

この記事で学ぶこと

章	内容	学んだ後にできること
第 1 章	フロントエンドの進化に注目する理由	技術の進化がどのような問題を解決するのか理解する
第 2 章	静的 Web ページの時代	最も初期の Web 開発手法を知る
第 3 章	jQuery 時代	「命令型」プログラミングの課題を理解する
第 4 章	Vue/React 時代	「宣言型」と「データ駆動」の考え方を習得する
第 5 章	レンダリング戦略	CSR、SSR、SSG の違いと適用シーンを知る
第 6 章	エンジニアリングツール	Webpack、Vite などのビルドツールの役割を理解する

各章は「なぜこの技術が必要なのか」から始まり、技術進化の背後にあるロジックを理解できるように構成されています。

1. なぜフロントエンドの進化史に注目するのか？

🤔 核心的な問い

なぜ Web ページはますます複雑になっているのか？フロントエンド技術はなぜ進化し続けるのか？ この問いが、シンプルな Web ページから現代の Web アプリケーションへの技術的変遷を理解する手がかりとなります。

1.1 「電子ポスター」から「デスクトップアプリ」へ

街で見かけるポスターを想像してみてください：

✅ 内容がある（文字、画像）
✅ デザインがある（色、レイアウト）
❌ しかし、話しかけても反応しない
❌ どこかをクリックしても何も起こらない

最も初期の Web ページは、まさにこのような「電子ポスター」でした。見るだけで、変更できず、内容は固定されていました。

現代の Web ページはまったく異なります。それらはデスクトップアプリ（VS Code、Figma）のようです：

✅ ドキュメントの編集、お絵かき、ゲームができる
✅ あらゆる操作にリアルタイムで反応する
✅ オフラインでも作業できることもある

この変化の核心的な理由：Web ページの機能がますます複雑になり、より効率的な技術と開発手法が必要になったのです。

1.2 身近なたとえ：家を建てる

フロントエンド技術の進化は、家の建て方の進化に似ています：

時代	🏠 家づくりのたとえ	実際の特徴	長所と短所
2000s	ポスターを貼る	静的 Web ページ、HTML を書くだけ	✅ 簡単 ❌ インタラクション不可
2010s	職人を呼んで手作業で改装	jQuery 時代、各要素を手動操作	✅ インタラクション可能 ❌ コードが乱雑で保守が困難
2020s	レゴで家を組み立てる	Vue/React 時代、コンポーネント化開発	✅ 効率的・保守しやすい ❌ 学習曲線あり

💡 表から何が読み取れるか？

段階 1 → 段階 2：「動かない」から「動く」へ。これは質的な飛躍です。Web ページにインタラクションが生まれましたが、その代償としてコードが混乱しました。

段階 2 → 段階 3：「使える」から「使いやすい」へ。コンポーネント化により、コードがブロックのように再利用可能になり、開発効率が大幅に向上しました。

核心的な考え方：技術の進化は「新しさのための新しさ」ではなく、前の段階の課題を解決するためにあるのです。

2. 第一段階：静的 Web ページと「スライス」（2000s）

🤔 核心的な問い

最も初期の Web ページはどのようなものだったのか？なぜ当時はフレームワークが必要なかったのか？ この段階の限界を理解して初めて、その後の技術進化の必然性がわかります。

I. The Static Era

Web pages were just digital documents. The server sent HTML, and the browser rendered it. Want new content? Refresh the whole page.

index.html

<html>
<body>
  <h1>Hello World</h1>
  <p>Static content served by server.</p>
</body>
</html>

Architecture Pattern

📄 HTML (Content)

↓

🌍 Browser (Display)

Server sends complete HTML

2.1 この時代はどのようなものだったか？

開発手法：

いくつかの HTML ファイルを書く
CSS と JavaScript を埋め込む
ファイルをブラウザに直接ドラッグすれば表示を確認できる
フォルダをサーバーにアップロードすればデプロイ完了

特徴：

✅ 長所：シンプルで直接的、学習コストがなく、書けばすぐ動く
❌ 短所：複雑なインタラクションが実現できず、コードが増えるとすぐに混乱する

当時のプロジェクト構造を見る

project/
├── index.html
├── login.html
├── css/
│   ├── bootstrap.css
│   └── custom.css
├── js/
│   ├── jquery.js
│   └── app.js
└── images/

直面した問題：

グローバル変数の汚染：すべての変数がグローバル名前空間にあり、互いに上書きしやすい
依存関係管理の混乱：JS ファイルを正しい順序で読み込まないとエラーが発生する
コードの再利用が困難：ある機能を再利用したい場合、コピー＆ペーストするしかない

2.2 「スライス」とは？

「スライス（切図）」という言葉を聞いたことがあるかもしれません。これは初期のフロントエンドの主な仕事でした：

スライスとは？

デザイナーが Photoshop でページをデザイン → フロントエンドがデザインを小さな画像に切り分ける → HTML で画像を組み合わせてページを作る

なぜこんなに遅いのか？

Web ページ上の小さな画像はそれぞれ、ブラウザがネットワークリクエストを送信する必要があります。リクエストが多いほど、読み込みは遅くなります。

👇 実際に試してみよう：画像リクエストが読み込みパフォーマンスに与える影響を観察する

Slice count:12 images Merge into a sprite

Total requests

Estimated load time

750 ms

💡 スプライト画像（Sprite）

リクエスト数を減らすために、「スプライト画像」という技術が登場しました。多数の小さな画像を 1 枚の大きな画像にまとめるものです。

長所はリクエスト数が減ること、短所は作成と保守が面倒なことです。

この段階の教訓：リクエストが多すぎることがパフォーマンスの大敵。

3. 第二段階：jQuery 時代 - 「手動のレンガ運び」（2010s）

🤔 核心的な問い

なぜ jQuery が必要だったのか？それはどのような問題を解決し、どのような新しい問題をもたらしたのか？ jQuery の限界を理解して初めて、Vue/React の価値がわかります。

3.1 なぜ jQuery が必要だったのか？

Web ページが複雑になるにつれて、生の JavaScript の問題が露呈しました：

❌ API が煩雑：簡単な操作でも多くのコードを書く必要がある
❌ ブラウザ互換性：ブラウザごとに API が異なり、多くの互換コードを書く必要がある
❌ セレクタが弱い：要素を見つけるのが面倒

jQuery が誕生しました。JavaScript をシンプルにしたのです：

javascript

// 生の JavaScript（煩雑）
const element = document.getElementById('title')

// jQuery（簡潔）
const element = $('#title')

3.2 jQuery の考え方：手動でページを書き換える

jQuery の核心的な考え方は命令型です：「どのようにやるか」をブラウザに指示します。

javascript

// タイトル要素を見つける
$('#title').text('新しいタイトル')

// ボタンを見つけて無効化する
$('#submit-btn').attr('disabled', true)

// リストを見つけて項目を追加する
$('ul').append('<li>新しい項目</li>')

問題点：ページ上にどのような要素があるかを覚えておき、データが変わるたびに関連するすべての要素を手動で更新する必要があります。

👇 実際に試してみよう：jQuery とデータ駆動の方法を比較する

jQuery mindset: update DOM everywhere

Cart page count: 1

Checkout button:

Simulated commands

✅ All three places are consistent.

Command log

(No actions yet)

Vue/React mindset: update State only

Cart page count: 1

Checkout button:

You only need one action

When State changes, all three UI locations sync automatically. You do not manually find and update DOM nodes.

Two terms here

DOM: The page structure inside the browser, including buttons, text, and images

State: Page data, such as the cart count

⚠️ jQuery の課題

ショッピングカートを想像してください：

javascript

// ユーザーが「カートに追加」をクリック
function addToCart() {
  cartCount++ // データが変化

  // 関連するすべての場所を手動で更新しなければならない
  $('#cart-count').text(cartCount) // 右上のバッジ
  $('#cart-page-count').text(cartCount) // カートページ
  $('#checkout-price').text(calculatePrice()) // 決済ボタン

  // 一箇所でも更新を忘れると、ページの表示が不整合になる！
}

これが「手動のレンガ運び」の代償です：ミスが起こりやすく、保守が困難です。

3.3 モバイル普及：レスポンシブデザインの登場

この段階ではもう一つ重要な変化がありました：スマートフォンとタブレットの普及です。

Web ページは異なる画面に対応しなければならなくなりました。これにはレスポンシブレイアウトが必要です。同じ HTML/CSS で、画面幅に応じて自動的にレイアウトが変化します。

レスポンシブレイアウトの核心：メディアクエリ（Media Query）

css

/* PC 画面（640px 以上） */
@media (min-width: 640px) {
  .container {
    display: flex;
  }
}

/* スマートフォン画面（640px 以下） */
@media (max-width: 640px) {
  .container {
    display: block;
  }
}

👇 実際に試してみよう：ブラウザの幅を調整して、レスポンシブレイアウトの効果を観察する

Viewport width:860 px

Card 1

Card 2

Card 3

Card 4

Card 5

Card 6

Current columns:2

💡 レスポンシブは「スマートフォトフレーム」のようなもの

異なる部屋で同じ写真を見ることを想像してください：

広いリビング（PC 画面）では、写真を大きく飾り、横に他の装飾品も置ける
狭い寝室（スマートフォン画面）では、写真を縮小し、他の装飾品はしまわなければならない

レスポンシブレイアウトは「スマートフォトフレーム」です。部屋の大きさに応じて自動的に表示方法を調整します。

4. 第三段階：「手動のレンガ運び」から「データ駆動」へ（Vue/React）

🤔 核心的な問い

なぜ Vue/React が必要なのか？それらと jQuery の本質的な違いは何か？ 「宣言型」と「データ駆動」を理解することが、現代のフロントエンドフレームワークを習得する鍵です。

4.1 なぜ新しいフレームワークが必要なのか？

jQuery 時代の問題が臨界点に達しました：

コードが増えるとすぐに混乱する：いたるところに DOM 操作があり、保守が困難
バグが発生しやすい：一箇所の更新漏れでページの表示が不整合になる
共同作業が困難：複数人で同じファイルを修正するとコンフリクトが発生しやすい

Vue / React の核心的な考え方：データだけを変更すれば、ページは自動的に更新される。

4.2 Vue/React の考え方：宣言的 UI

jQuery（命令型）：

javascript

// ブラウザに各ステップの実行方法を指示する
$('#title').text('新しいタイトル')
$('#title').css('color', 'red')
$('#title').show()

Vue（宣言型）：

javascript

// 「何を表示するか」だけをブラウザに伝える
data() {
  return {
    title: "新しいタイトル",
    color: "red",
    visible: true
  }
}

👇 実際に試してみよう：命令型と宣言型の違いを比較する

🔄Imperative vs DeclarativeTwo programming mindsets: manual operations vs automatic response

ImperativejQuery style - manual operations

// Manually operate the DOM
 $('#count').text(val);
 if (val > 5) $('#msg').show();

Count: 0

Ready.

DeclarativeVue/React style - automatic response

// Bind data only
{{ count }}
 <div v-if="count > 5">...</div>

Count: 0

Framework handles DOM updates automatically.

💡Core idea:Imperative code tells the computer how to do each step. Declarative code tells it the desired result and lets the framework handle the updates.

💡 命令型 vs 宣言型

絵を描くことにたとえると：

命令型：画家に「筆を持って、赤い絵の具をつけて、座標（10,10）に丸を描いて」と指示する
宣言型：画家に写真を一枚渡して、「こう描いて」と伝える

Vue/React は「宣言型」です：「ページがどのように見えるか」を記述し、フレームワークが「どう描くか」を担当します。

4.3 コンポーネント化：レゴのようにページを作る

Vue / React の最も強力な特徴はコンポーネント化です：ページを独立した「ブロック」に分解します。

レゴを組み立てることを想像してください：

「各ブロックを一から削り出す」必要はない（HTML/CSS を一から書く必要はない）
「説明書通りにブロックを組み合わせる」だけでよい（コンポーネントを組み合わせる）
各ブロックは独立しており、異なるセットで再利用できる

コンポーネントの利点：

再利用：「商品カード」コンポーネントを一度書けば、100 回使える
カプセル化：コンポーネント内部の状態は他に影響しない
保守：コンポーネントを修正すれば、それを使っているすべての場所が更新される

💡 識別のコツ

<ComponentName /> を見たら → これはコンポーネント
import xxx from './xxx.vue' を見たら → コンポーネントをインポートしている
props: {...} を見たら → コンポーネントが受け取るパラメータ
emit('xxx') を見たら → コンポーネントが親コンポーネントにイベントを送信している

4.4 SPA：シングルページアプリケーションの誕生

Vue / React 時代のもう一つの重要な変化：MPA から SPA へ。

MPA（Multi-Page Application）：

リンクをクリック → ページ全体がリロード → 新しいページを表示
本をめくるようなもの：ページをめくるたびに古い本を閉じて、本棚から新しい本を取る

SPA（Single-Page Application）：

リンクをクリック → コンテンツ領域だけが更新 → ページはリロードされない
同じ本の中で章を切り替えるようなもの：古い内容を消して、新しい内容を書くだけ

👇 実際に試してみよう：MPA と SPA の違いを体験する

Current page:Home

MPA: each navigation performs a full-page reload.

SPA の長所：

✅ 滑らかな体験：ページ遷移が速い
✅ 状態管理がしやすい：入力内容やスクロール位置が保持される
❌ 初回表示が遅い可能性：JavaScript を先にダウンロードする必要がある
❌ SEO に追加対応が必要：検索エンジンがコンテンツを取得できない可能性がある（SSR/SSG が必要）

5. レンダリング戦略：CSR から SSR/SSG へ

🤔 核心的な問い

ページはサーバーで生成されるのか、ブラウザで生成されるのか？ 異なるレンダリング戦略にはそれぞれ長所短所があり、適切な戦略を選ぶことがパフォーマンスと SEO にとって重要です。

CSR（Client-Side Rendering）クライアントサイドレンダリング：

ブラウザが JavaScript をダウンロード → コードを実行 → ページを生成
長所：インタラクションが滑らか、サーバー負荷が小さい
短所：初回表示が遅い、SEO に不利

SSR（Server-Side Rendering）サーバーサイドレンダリング：

サーバーが HTML を生成 → ブラウザに送信 → ブラウザが直接表示
長所：初回表示が速い、SEO に有利
短所：サーバー負荷が大きい、実装が複雑

SSG（Static Site Generation）静的サイト生成：

ビルド時にすべてのページの HTML を生成
長所：極めて高速、完全に静的、CDN との相性が良い
短所：動的コンテンツに不向き

👇 実際に試してみよう：異なるレンダリング戦略の特徴を比較する

TTFB

450 ms

Time to interactive

1600 ms

SEO friendly

Fair

The page renders only after JavaScript loads and fetches data.

💡 どのように選ぶか？

コンテンツサイト（ブログ、ドキュメント）：SSG を優先
SEO が必要な動的サイト（EC、ニュース）：SSR を使用
管理画面：CSR を使用
混合要件：Nuxt/Next.js のハイブリッドレンダリングを検討

6. 第四段階：エンジニアリングとビルドツール（2015s-2020s）

🤔 核心的な問い

なぜフロントエンドに「エンジニアリング」が必要なのか？ビルドツールは一体何をしているのか？ エンジニアリングを理解して初めて、現代のフロントエンドプロジェクトのワークフローが見えてきます。

6.1 なぜ「エンジニアリング」が必要なのか？

フロントエンドプロジェクトはますます大規模になり、「手動でスクリプトを導入する」だけでは済まなくなりました。

エンジニアリングとは、ツールと規範を使って、開発をより効率的にし、コードをより信頼性高くし、共同作業をよりスムーズにすることです。

💡 エンジニアリング = 「手作業の工房」から「近代的な工場」へ

自宅で料理をするのとレストランを経営するのを想像してください：

自宅で料理：食べたいものを自由に作れる
レストラン経営：標準化されたレシピ、規範化された作業手順、統一された材料調達が必要

フロントエンド開発も同じです：

小規模プロジェクト：どう書いてもよい
大規模プロジェクト：統一されたコード規約、自動化ツール、標準化されたプロセスが必要

6.2 ビルドツール：Webpack → Vite

Webpack（従来型）：

動作方式：先にバンドル、後で配信
起動時：すべてのコードをバンドル → サーバーを起動
問題点：遅い。プロジェクトが大きいほど、起動が遅くなる（30 秒かかることも）

Vite（モダン）：

動作方式：オンデマンドコンパイル
起動時：バンドルせず、直接サーバーを起動
ブラウザがリクエストしたファイルだけをリアルタイムでコンパイル
利点：速い。通常 1 秒以内に起動

比較項目	Webpack	Vite	向上
コールドスタート	30s+	<1s	30 倍高速
ホットリロード	3-5s	<100ms	30 倍高速
設定ファイル	数百行	数十行	大幅に簡略化

💡 なぜ Vite はこんなに速いのか？

Webpack は家財道具をすべてまとめて引っ越しするようなものです。まずすべてを梱包してから出発します。

Vite は身軽な旅のようなものです。必要なものだけを持ち、必要になったらその場で調達します。

開発環境では、ほとんどの場合数ファイルだけを修正するので、Vite はその数ファイルだけをコンパイルします。当然速いのです。

7. 主要フレームワーク比較

🤔 核心的な問い

Vue、React、Svelte、Angular にはそれぞれどのような特徴があるのか？自分に合ったフレームワークをどう選ぶか？ それぞれの設計思想とユースケースを理解して初めて、賢明な選択ができます。

7.1 四大フレームワーク比較

特性	Vue	React	Svelte	Angular
設計思想	プログレッシブフレームワーク	UI ライブラリ	コンパイル時フレームワーク	完全なプラットフォーム
学習曲線	⭐⭐ 簡単	⭐⭐⭐ 中程度	⭐⭐ 簡単	⭐⭐⭐⭐ 急峻
パフォーマンス	速い	速い	極めて速い	速い
エコシステム	充実	最も充実	成長中	充実
バンドルサイズ	小さい	中程度	最小	大きい
適したシーン	中小規模プロジェクト	大規模プロジェクト	高パフォーマンス要求	エンタープライズアプリ
企業サポート	Evan You（独立）	Meta	コミュニティ	Google

7.2 Vue：プログレッシブフレームワーク

核心理念：プログレッシブ採用、一部だけ使うことも、フルスタックで使うことも可能

vue

<template>
  <div>{{ message }}</div>
</template>

<script>
export default {
  data() {
    return {
      message: 'Hello Vue'
    }
  }
}
</script>

長所：

✅ 学習曲線が緩やか、中国語ドキュメントが充実
✅ テンプレート構文が直感的で理解しやすい
✅ 単一ファイルコンポーネント（.vue）の構造が明確
✅ 迅速な開発に適している

短所：

❌ 大規模プロジェクトの状態管理には Vuex/Pinia の追加学習が必要
❌ 柔軟性は React にやや劣る

適用シーン：

中小規模の Web アプリケーション
迅速なプロトタイプ開発
中国語チーム（ドキュメントが充実）

7.3 React：UI ライブラリ

核心理念：ビュー層のみを担当し、その他の問題はコミュニティに任せる

jsx

function App() {
  const [message, setMessage] = useState('Hello React')
  return <div>{message}</div>
}

長所：

✅ エコシステムが最も充実、コンポーネントライブラリが豊富
✅ JSX 構文が柔軟で表現力が高い
✅ 仮想 DOM のパフォーマンスが優れている
✅ 大規模プロジェクトに適している

短所：

❌ 学習曲線がやや急で、追加の概念を習得する必要がある
❌ さまざまなライブラリを自分で選択・組み合わせる必要がある
❌ JSX はコンパイルが必要で、ブラウザで直接実行できない

適用シーン：

大規模で複雑なアプリケーション
豊富なエコシステムが必要なプロジェクト
クロスプラットフォーム開発（React Native）

7.4 Svelte：コンパイル時フレームワーク

核心理念：仮想 DOM なし、コンパイル時にコンポーネントを効率的なネイティブコードに変換

svelte

<script>
  let message = 'Hello Svelte'
</script>

<div>{message}</div>

長所：

✅ パフォーマンスが最適（仮想 DOM のランタイムオーバーヘッドなし）
✅ バンドルサイズが最小
✅ 構文がシンプルで直感的
✅ リアクティブシステムをネイティブサポート

短所：

❌ エコシステムが比較的小さい
❌ コミュニティ規模が Vue/React に及ばない
❌ サードパーティライブラリが少ない

適用シーン：

極めて高いパフォーマンスが要求されるアプリケーション
バンドルサイズが重要なプロジェクト
新しい技術に挑戦する意欲のあるチーム

7.5 Angular：完全なプラットフォーム

核心理念：完全なソリューションを提供し、すぐに使える

typescript

@Component({
  selector: 'app-root',
  template: '<div>{{ message }}</div>'
})
export class AppComponent {
  message = 'Hello Angular'
}

長所：

✅ 機能が完全、ルーティング、HTTP、フォームがすべて揃っている
✅ TypeScript をネイティブサポート
✅ 大規模チームとプロジェクトに適している
✅ コード規約が統一されている

短所：

❌ 学習曲線が急峻
❌ 概念が多く、複雑性が高い
❌ バンドルサイズが大きい
❌ 小規模プロジェクトに不向き

適用シーン：

大規模エンタープライズアプリケーション
厳格な規範が必要なチーム
既に TypeScript 技術スタックを持つプロジェクト

8. まとめ：進化の本質

フロントエンド技術の進化は、本質的に二つの問題を解決しています：

8.1 効率：手動から自動へ

時代	開発手法	効率
2000s	HTML/CSS/JS を手書き	⭐
2010s	jQuery + 手動 DOM 操作	⭐⭐
2020s	Vue/React + データ駆動	⭐⭐⭐
現在	コンポーネント化 + エンジニアリング + 自動化	⭐⭐⭐⭐⭐

8.2 規模：個人からチームへ

時代	プロジェクト規模	共同作業の方法
2000s	数ファイル	一人で保守可能
2010s	数十ファイル	小規模チーム、コンフリクトしやすい
2020s	数百ファイル	中規模チーム、規範が必要
現在	数千ファイル	大規模チーム、完全なエンジニアリング体系が必要

9. 学習ロードマップ

9.1 未経験者の場合

ステップ 1：HTML/CSS/JavaScript の基礎

Web ページの三大基盤を理解する
簡単な静的ページを書けるようになる

ステップ 2：一つのフレームワークを学ぶ（Vue 推奨）

「データ駆動」の考え方を理解する
コンポーネント化開発を習得する

ステップ 3：実践プロジェクト

完全なシングルページアプリケーションを作る
ルーティング、状態管理、API 呼び出しに慣れる

9.2 経験者の場合

次のステップ：

エンジニアリング：Vite/Webpack を学び、ビルドプロセスを理解する
パフォーマンス最適化：遅延読み込み、コード分割、キャッシュ戦略を学ぶ
TypeScript：コードに型を付けて信頼性を向上させる
サーバーサイドレンダリング：Nuxt/Next.js を学び、SEO と初回表示の問題を解決する

10. あなたが今識別できるようになるべきコード

この章を読むことで、あなたは次のことができるようになるはずです：

✅ フロントエンド技術の進化の流れと理由を理解する
✅ Vue、React、Svelte、Angular の特徴を区別する
✅ 「命令型」と「宣言型」の違いを理解する
✅ 「データ駆動」の核心的な考え方を習得する
✅ コンポーネント化開発の価値を知る
✅ CSR、SSR、SSG の適用シーンを理解する
✅ ビルドツール（Webpack、Vite）の役割を理解する
✅ プロジェクトに応じて適切なフレームワークと技術スタックを選べる

💡 実践的な応用

AI でプロジェクトを行うとき、このように伝えることができます：

「これは SEO が必要なブログサイトなので、Nuxt（Vue の SSR フレームワーク）を使って」
「これは管理画面なので、Vue + Element Plus を使って、SSR は不要」
「これはパフォーマンス要求の高い Web アプリなので、Svelte の使用を検討して」
「プロジェクトはすでに React を使っているので、引き続き React エコシステムのライブラリを使って」

用語早見表

用語	英語	わかりやすい説明
DOM	Document Object Model	ドキュメントオブジェクトモデル。オブジェクトツリーでページを表現し、JS で読み書き可能。
jQuery	-	初期に流行した JS ライブラリ。DOM 操作を簡略化。
Vue/React	-	現代のフロントエンドフレームワーク。データ駆動とコンポーネント化開発を採用。
コンポーネント	Component	再利用可能な UI ユニット。ボタン、カード、ナビゲーションバーなど。
MPA	Multi-Page Application	マルチページアプリケーション。遷移のたびにページ全体を再読み込み。
SPA	Single-Page Application	シングルページアプリケーション。一度だけ読み込み、以降の切り替えでページをリフレッシュしない。
ルーティング	Routing	ページ間の切り替えを管理するルールとプロセス。
SSR	Server-Side Rendering	サーバーサイドレンダリング。サーバーが HTML を生成してブラウザに送信。
SSG	Static Site Generation	静的サイト生成。ビルド時にページを静的 HTML として事前レンダリング。
CSR	Client-Side Rendering	クライアントサイドレンダリング。ブラウザが JS でページを生成。
Webpack	-	従来のバンドルツール。先にバンドルしてから配信。
Vite	-	現代のビルドツール。オンデマンドコンパイルで非常に高速。
レスポンシブ	Responsive Design	ページが異なる画面サイズに自動適応するデザイン。
メディアクエリ	Media Query	CSS の条件分岐。画面幅に応じて異なるスタイルを適用。
命令型	Imperative	プログラムに「どのようにやるか」を指示する。
宣言型	Declarative	プログラムに「何が欲しいか」を伝える。
データ駆動	Data-Driven	データを変更するだけで、インターフェースが自動更新される。
Tree Shaking	-	ツリーシェイキング。未使用コードを自動削除し、バンドルサイズを削減。
コード分割	Code Splitting	コードを複数の小さな塊に分割し、オンデマンドで読み込む。

フロントエンドフレームワーク詳細ガイド ​

1. なぜフロントエンドの進化史に注目するのか？ ​

1.1 「電子ポスター」から「デスクトップアプリ」へ ​

1.2 身近なたとえ：家を建てる ​

2. 第一段階：静的 Web ページと「スライス」（2000s） ​

I. The Static Era

2.1 この時代はどのようなものだったか？ ​

2.2 「スライス」とは？ ​

3. 第二段階：jQuery 時代 - 「手動のレンガ運び」（2010s） ​

3.1 なぜ jQuery が必要だったのか？ ​

3.2 jQuery の考え方：手動でページを書き換える ​

3.3 モバイル普及：レスポンシブデザインの登場 ​

4. 第三段階：「手動のレンガ運び」から「データ駆動」へ（Vue/React） ​

4.1 なぜ新しいフレームワークが必要なのか？ ​

4.2 Vue/React の考え方：宣言的 UI ​

4.3 コンポーネント化：レゴのようにページを作る ​

4.4 SPA：シングルページアプリケーションの誕生 ​

5. レンダリング戦略：CSR から SSR/SSG へ ​

6. 第四段階：エンジニアリングとビルドツール（2015s-2020s） ​

6.1 なぜ「エンジニアリング」が必要なのか？ ​

6.2 ビルドツール：Webpack → Vite ​

7. 主要フレームワーク比較 ​

7.1 四大フレームワーク比較 ​

7.2 Vue：プログレッシブフレームワーク ​

7.3 React：UI ライブラリ ​

7.4 Svelte：コンパイル時フレームワーク ​

7.5 Angular：完全なプラットフォーム ​

8. まとめ：進化の本質 ​

8.1 効率：手動から自動へ ​

8.2 規模：個人からチームへ ​

9. 学習ロードマップ ​

9.1 未経験者の場合 ​

9.2 経験者の場合 ​

10. あなたが今識別できるようになるべきコード ​

用語早見表 ​

フロントエンドフレームワーク詳細ガイド

1. なぜフロントエンドの進化史に注目するのか？

1.1 「電子ポスター」から「デスクトップアプリ」へ

1.2 身近なたとえ：家を建てる

2. 第一段階：静的 Web ページと「スライス」（2000s）

2.1 この時代はどのようなものだったか？

2.2 「スライス」とは？

3. 第二段階：jQuery 時代 - 「手動のレンガ運び」（2010s）

3.1 なぜ jQuery が必要だったのか？

3.2 jQuery の考え方：手動でページを書き換える

3.3 モバイル普及：レスポンシブデザインの登場

4. 第三段階：「手動のレンガ運び」から「データ駆動」へ（Vue/React）

4.1 なぜ新しいフレームワークが必要なのか？

4.2 Vue/React の考え方：宣言的 UI

4.3 コンポーネント化：レゴのようにページを作る

4.4 SPA：シングルページアプリケーションの誕生

5. レンダリング戦略：CSR から SSR/SSG へ

6. 第四段階：エンジニアリングとビルドツール（2015s-2020s）

6.1 なぜ「エンジニアリング」が必要なのか？

6.2 ビルドツール：Webpack → Vite

7. 主要フレームワーク比較

7.1 四大フレームワーク比較

7.2 Vue：プログレッシブフレームワーク

7.3 React：UI ライブラリ

7.4 Svelte：コンパイル時フレームワーク

7.5 Angular：完全なプラットフォーム

8. まとめ：進化の本質

8.1 効率：手動から自動へ

8.2 規模：個人からチームへ

9. 学習ロードマップ

9.1 未経験者の場合

9.2 経験者の場合

10. あなたが今識別できるようになるべきコード

用語早見表