フレームワークが生まれた理由
このページで学ぶこと
Section titled “このページで学ぶこと”- 従来型のWebページから、JavaScriptを多用する画面へ変化した流れ
- MPA・Ajax・SPAという考え方
- コンポーネント化と状態管理が必要になった理由
- フレームワークが解決する問題と、新たに増やす複雑さ
- フレームワークを使わない選択も成立すること
Webのフロントエンド技術は、単純な文書表示から、アプリケーションに近い操作を行うために発展してきました。
flowchart LR
A[HTML中心のページ] --> B[サーバーでページ生成]
B --> C[JavaScriptで部分更新]
C --> D[SPA・複雑な画面状態]
D --> E[コンポーネント型フレームワーク]
E --> F[SSR・SSG等を統合するフレームワーク]
フレームワークは、単にコードを新しい書き方へ変えるものではありません。
画面が複雑になり、複数人で長期間保守するために、部品、データ、画面遷移、ビルド、テスト等の作り方を一定のルールへそろえる役割を持ちます。
初期のWebはページ単位だった
Section titled “初期のWebはページ単位だった”従来のWebサイトでは、リンクやフォームを操作すると、ブラウザがサーバーへリクエストを送り、サーバーが新しいHTMLを返す形が中心でした。
sequenceDiagram
participant U as 利用者
participant B as ブラウザ
participant S as サーバー
U->>B: リンクを押す
B->>S: 次のURLを要求
S-->>B: 完成したHTMLを返す
B-->>U: ページ全体を表示
このような複数ページ型の構成は、一般にMPA（Multi Page Application）と呼ばれます。
MPAは現在も広く使われています。コーポレートサイトやメディアでは、URLごとにHTMLを返す単純さが、SEO、アクセシビリティ、障害時の分かりやすさ、長期保守へ有利な場合があります。
JavaScriptでページの一部を更新する
Section titled “JavaScriptでページの一部を更新する”Webサイトに検索候補、地図、入力補助等が増えると、ページ全体を読み直さずに一部だけ更新する必要が生まれました。
JavaScriptからサーバーへ通信し、取得したデータで画面を書き換える方式が広がりました。
sequenceDiagram
participant U as 利用者
participant P as 表示中のページ
participant A as API・サーバー
U->>P: 条件を変更
P->>A: 必要なデータだけ要求
A-->>P: データを返す
P-->>U: 一部分だけ更新
この時代には、ブラウザ差異を吸収し、HTML操作や通信を簡単にするため、jQuery等のライブラリが広く使われました。
ただし機能が増えるにつれ、どの操作がどの要素を書き換えるか、現在どの状態かを管理することが難しくなりました。
SPAが目指したこと
Section titled “SPAが目指したこと”SPA（Single Page Application）は、最初にアプリケーションの土台を読み込み、その後の画面遷移や更新を主にJavaScriptで行う構成です。
flowchart LR
B[ブラウザ] --> APP[JavaScriptアプリ]
APP --> R[ルーター]
APP --> STATE[画面状態]
APP --> API[API]
STATE --> UI[表示]
SPAには、画面遷移を滑らかにしやすい、入力内容や状態を保ちやすい、複雑な操作画面を作りやすい等の利点があります。
一方、初回に多くのJavaScriptを読む、エラーの影響が大きい、URL・履歴・SEO・アクセシビリティを意識して実装する、状態管理が複雑になる等の課題もあります。
管理画面や業務アプリには相性がよい一方、すべてのWebサイトをSPAにする必要はありません。
コンポーネント化が必要になった
Section titled “コンポーネント化が必要になった”画面が大規模になると、ボタン、カード、検索欄、モーダル等を部品として再利用する考え方が重要になります。
flowchart TD
PAGE[ページ]
PAGE --> HEADER[ヘッダー]
PAGE --> SEARCH[検索エリア]
PAGE --> LIST[カード一覧]
LIST --> CARD1[カード]
LIST --> CARD2[カード]
CARD1 --> BUTTON1[ボタン]
CARD2 --> BUTTON2[ボタン]
コンポーネントには、見た目だけでなく、表示するデータ、操作、状態、エラー、読み込み中、空の場合、アクセシビリティ、レスポンシブ表示等が含まれます。
部品化すると再利用しやすくなりますが、粒度や責任を誤ると、汎用的すぎて使いづらい部品や、似た部品の乱立が起きます。
状態管理が必要になった
Section titled “状態管理が必要になった”状態とは、画面が現在どのような状況かを示す情報です。
- メニューが開いている
- 読み込み中
- ログインしている
- 検索条件が選ばれている
- 入力エラーがある
- カートに商品が入っている
- API通信に失敗した
複数の部品が同じ状態を参照・変更すると、個別のJavaScriptで直接書き換えるだけでは把握しにくくなります。
フレームワークは、データや状態が変わったら表示を更新する流れを整理します。
flowchart LR
D[データ・状態] --> U[UIを生成]
U --> E[利用者の操作]
E --> D
フレームワークが提供するもの
Section titled “フレームワークが提供するもの”UIライブラリ・フレームワークによって範囲は異なりますが、一般に次の仕組みを提供します。
- コンポーネント
- 状態に応じた表示更新
- イベント処理
- 部品間のデータ受け渡し
- 開発ツールとの連携
- テストしやすい構造
さらにNext.jsやNuxt等のアプリケーションフレームワークは、URLルーティング、データ取得、SSR・SSG、サーバー側処理、ビルド、画像最適化、キャッシュ等も統合します。
「フレームワーク」という言葉が何を指すかは製品ごとに異なるため、名称だけで判断しません。
フレームワークの利点
Section titled “フレームワークの利点”開発の共通ルールを持てる
Section titled “開発の共通ルールを持てる”複数人が同じ部品・データ更新・ページ構成のルールで開発しやすくなります。
複雑なUIを管理しやすい
Section titled “複雑なUIを管理しやすい”状態変化が多い検索、予約、管理画面等を構造化できます。
エコシステムを利用できる
Section titled “エコシステムを利用できる”ルーター、フォーム、テスト、UI部品、開発支援等の周辺ツールを利用できます。
採用・引継ぎの手掛かりになる
Section titled “採用・引継ぎの手掛かりになる”広く使われる技術では、経験者や情報を探しやすい場合があります。ただし、同じフレームワークでも設計品質はプロジェクトによって異なります。
フレームワークによって増えるもの
Section titled “フレームワークによって増えるもの”- ビルド工程
- 依存ライブラリ
- 学習と人材依存
- ブラウザへ送るJavaScript
- 公開・障害経路
- メジャーアップグレード
フレームワーク本体だけでなく、Node.js、ビルドツール、ルーター、UI部品等の保守も発生します。
フレームワークを使わない選択
Section titled “フレームワークを使わない選択”静的な数ページのサイト、短期のランディングページ、既存CMSのテンプレート改修等では、フレームワークを導入しない方が単純な場合があります。
また、一部の検索UIだけReactを使う等、段階的に導入できる製品もあります。
判断軸は「モダンかどうか」ではありません。
- 画面の複雑さ
- 再利用する部品数
- ページ数
- 更新頻度
- チーム人数
- 運用期間
- 対応できる人材
- SEO・性能
- ホスティング
- 予算
に対して、導入コストを上回る価値があるかで判断します。
実案件ではどう考えるか
Section titled “実案件ではどう考えるか”コーポレートサイト
Section titled “コーポレートサイト”ヘッドレスCMSと組み合わせるためにAstroやNext.js等を使うことがあります。しかし、動的UIが少ない場合、ブラウザへ大量のJavaScriptを送る必要はありません。
施設検索サイト
Section titled “施設検索サイト”地図、条件絞り込み、お気に入り、予約等がある場合、コンポーネントと状態管理が有効です。ただし、すべてをSPAにするか、検索部分だけJavaScript化するかは要件次第です。
既存WordPressサイト
Section titled “既存WordPressサイト”全面的にフロントエンドフレームワークへ移行すると、CMSプレビュー、フォーム、検索、公開フロー、ホスティング等を作り直すことがあります。「新しくなる」以外に、移行費用と運用価値を比較します。
PMチェックリスト
Section titled “PMチェックリスト”- フレームワークを採用する目的を一文で説明できる
- フレームワークなしの構成と比較している
- UIの複雑さ・状態・再利用部品を整理している
- SPAにする範囲と通常ページ遷移の範囲を整理している
- ブラウザへ送るJavaScript量を性能要件として扱っている
- ビルド・公開・キャッシュの工程を把握している
- フレームワーク経験者と保守担当を確保している
- 本体・周辺ライブラリの更新方針がある
- 長期運用でアップグレードが必要になる前提を持っている
- JavaScriptエラー時の影響と代替表示を確認している
よくある誤解・失敗
Section titled “よくある誤解・失敗”「Reactを使えばSPAになる」
Section titled “「Reactを使えばSPAになる」”ReactはUIを構築するライブラリであり、ページの一部分にも、SSR・SSGサイトにも利用できます。構成は別途決まります。
「SPAはページ遷移が速いので常に優れている」
Section titled “「SPAはページ遷移が速いので常に優れている」”初回読み込み、SEO、アクセシビリティ、JavaScript障害、開発・運用コストとの比較が必要です。
「コンポーネント化すれば改修が簡単」
Section titled “「コンポーネント化すれば改修が簡単」”適切な粒度・仕様・テスト・ドキュメントがなければ、部品の影響範囲が分かりにくくなる場合があります。
「有名なフレームワークなら長期保守も安心」
Section titled “「有名なフレームワークなら長期保守も安心」”利用者が多くても、プロジェクトの更新を止めれば依存関係は古くなります。採用技術と自社体制が合うことが重要です。
「フレームワークなしは古い」
Section titled “「フレームワークなしは古い」”ブラウザ標準やサーバー側テンプレートだけで十分な案件もあります。単純さは長期保守上の利点です。
理解度チェック
Section titled “理解度チェック”Q1. フレームワークが広がった背景を説明してください。
Section titled “Q1. フレームワークが広がった背景を説明してください。”回答と解説
JavaScriptで扱う画面・状態・部品が増え、個別のDOM操作だけでは複数人・長期の保守が難しくなったため、コンポーネントや状態更新の共通ルールが求められました。Q2. MPAとSPAの大きな違いは何ですか。
Section titled “Q2. MPAとSPAの大きな違いは何ですか。”回答と解説
MPAはURL遷移ごとにサーバーから新しいページを受け取る構成が中心です。SPAは読み込んだJavaScriptアプリが画面遷移・更新を多く担当します。実際の構成は混在することもあります。Q3. 小規模なキャンペーンページでも必ずフレームワークを使うべきでしょうか。
Section titled “Q3. 小規模なキャンペーンページでも必ずフレームワークを使うべきでしょうか。”回答と解説
必ずではありません。操作の複雑さ、再利用、運用期間、チーム、ビルド・更新負荷を踏まえ、導入価値があるか比較します。Q4. コンポーネント化によって何が改善し、何が難しくなりますか。
Section titled “Q4. コンポーネント化によって何が改善し、何が難しくなりますか。”回答と解説
再利用・共通変更・分業がしやすくなる一方、部品の粒度、依存関係、状態、影響範囲、デザインとの同期を管理する必要があります。Q5. フレームワーク採用時に、開発費以外で確認する費用は何ですか。
Section titled “Q5. フレームワーク採用時に、開発費以外で確認する費用は何ですか。”回答と解説
ビルド・ホスティング、保守人員、ライブラリ更新、メジャーアップグレード、性能改善、テスト、障害対応等の継続費用を確認します。- リクルート「React研修 2024」
https://speakerdeck.com/recruitengineers/react-yan-xiu-2024 - React「Creating a React App」
https://react.dev/learn/creating-a-react-app - React「Add React to an Existing Project」
https://react.dev/learn/add-react-to-an-existing-project - Vue「Introduction」
https://vuejs.org/guide/introduction