【2025年新卒研修】 React・Next.js は何であるのか

~ React・Next.js は何であるのか ~ 2025年新卒研修

今回の GOAL ➔ React と Next.js がどういう課題を解決しているか理解できる ➔ React と
Next.js のメインコンセプトを理解できる予想聴者 ➔ React とか Next.js とか WEB とか全然わからない人

今回話すこと ➔ React と Next.js が登場するまでの経緯 ➔ React と Next.js
のメインコンセプト今回話さないこと ➔ React と Next.js の具体的な文法・書き方など ➔ 2016~2017年以降から登場した技術の話（時間の関係で省略します）

今回話すこと ➔ React と Next.js が登場するまでの経緯 ➔ React と Next.js
のメインコンセプト今回話さないこと以外にここらへんって自分で調べたりしない限りあまり知る機会がないので、今回詳しく話したい ➔ React と Next.js の具体的な文法・書き方など ➔ 2016~2017年以降から登場した技術の話（時間の関係で省略します）

その他 ➔ 3時間よりは早く終わると思います（多分、、？） ➔ 途中休憩挟んだりします ➔ 反応は Teams のリアクションやチャットでご自由に ➔
このスライドは公開するのでいつでも見れます

職業自己紹介韓国人。美術大学で視覚デザインを専攻したが、勢いだけでエンジニアになって今に至る。大学時代にはげしくアニメオタクをやってたおかげで日本語流暢。フロントエンドエンジニア（2020/11 ~） React、Typescript メインでやってます
名前李庭旻 (イジョンミン) 講師紹介

CONTENTS 1. 初期のWEB 2. Ajax と jQuery 3. SPA の登場
4. React 5. SPA + SSR 6. Next.js

Quiz. WEBはいつ誕生したでしょうか？ (1) 1990年ごろ (2) 1980年ごろ (3) 1970年ごろ (4) 1960年ごろ

Quiz. WEBはいつ誕生したでしょうか？正解 (1) 1990年ごろ (2) 1980年ごろ (3) 1970年ごろ (4)
1960年ごろ

1990年ごろ、WEBが誕生する CERN (欧州原子核研究機構) 所属科学者の Tim Berners-Lee が初めて WWW、ブラウザ、HTTP などを考案。彼は研究所内の数多くのドキュメントを共有する方法を探してたと知られてる
image from https://en.wikipedia.org/wiki/Tim_Berners-Lee ウェブの生みの親

世界初のWEBサイト（復元したものだけど）テキストに資料のリンクが付与されたハイパテキストの登場 HTML (HyperText Markup Language) の名前もここからきてる HyperText

1995年、JavaScript の誕生 Netscape Communications Corporation 社の Brendan Eich が1995年5月に10日間（!!）で開発。

1996年、CSS の誕生文書の構造とスタイルを分離させるという理念を実現するために誕生

当時 WEB の動作まず登場人物（?）である Client と Server を紹介する google.com のページください！
はいどうぞ情報をリクエスト情報を提供

当時 WEB の動作 Client がリクエストを送ると、Server が HTML を生成して送る (1) リクエスト
(2) HTML 生成 (3) HTML 送信

MPA（Multi-Page Application）このように動く WEB アプリケーションを、MPA（Multi-Page Application) と呼んでた (1) リクエスト (2)
HTML 生成 (3) HTML 送信

MPA（Multi-Page Application） (1) リクエスト (2) HTML 生成複数ページのアプリケーション… ってどういうこと？ (3)
HTML 送信このように動く WEB アプリケーションを、MPA（Multi-Page Application) と呼んでた

(1) Aページ開く (2) Aページ表示 (4) Bページ表示 (6) Cページ表示 (8) Dページ表示
(10) Eページ表示 (3) Bページ開く (5) Cページ開く (7) Dページ開く (9) Eページ開く

(10) Eページ表示 (3) Bページ開く (5) Cページ開く (7) Dページ開く (9) Eページ開くページ遷移する度に新たに HTMLを生成して送る

当時主流の動的 MPA の多くは SSR する SSR とは、Server side rendering (＝
サーバー側のレンダリング) の略称。 (1) リクエスト (2) HTML 生成 PHP、Java などがよく使われていたクライアントはもらった HTMLを表示するだけ (3) HTML 送信

しかし、MPA には限界があり画面更新のためにサーバーにリクエストしてHTMLを送信してもらう必要がある (1) リクエスト (2) HTML 生成 (3) HTML
送信

しかし、MPA には限界があり画面更新のためにサーバーにリクエストしてHTMLを送信してもらう必要がある (1) リクエスト (2) HTML 生成 (2) と
(3) が行われる間、Client は何してる？ (3) HTML 送信

しかし、MPA には限界があり画面更新のためにサーバーにリクエストしてHTMLを送信してもらう必要がある (1) リクエスト (2) HTML 生成 (1) と
(2) が行われる間、Client は何してる？何もしてない（白くなってる） (3) HTML 送信

しかし、MPA には限界があり画面遷移するときも、同じ画面の一部だけ更新するときもフルリロードが必要がある (+ 画面遷移する度にサーバーにHTML作ってもらうから時間かかる) Aページの一部更新フルリロード Aページの一部が更新される

そして新しい技術の動きが始まる

整理 • 1990年初期に WEB 技術が誕生する • 初期の WEB は MPA（Multi-Page
Application）だった ◦ MPA → サーバーが HTML を生成、クライアントに送信して表示するアプリケーション • 当時の MPA は SSR（Server side rendering）方式だった ◦ SSR → リクエスト時にサーバーサイドでHTMLを生成する手法 • 当時の MPA は画面遷移や画面の一部だけ更新するとき、フルリロードが必要で UX が良くなかった

2005年、WEB 業界に革命がおきる Google Map リリース: 画面遷移せず画面の一部だけを更新できる技術を採用する Google Map をドラッグしたらその部分だけ読み込むあれ

Google Map リリース: 画面遷移せず画面の一部だけを更新できる技術を採用する Google Map をドラッグしたらその部分だけ読み込むあれ Ajax（Asynchronous JavaScript And
XML） 2005年、WEB 業界に革命がおきる

Ajax（Asynchronous JavaScript And XML）非同期

補足）同期・非同期処理とは同期処理 ➔ タスクを順番に処理する（= 前のタスクが終了するまで待つ）作業１作業2 作業3 Time 非同期処理
➔ 現在タスクが実行中でも、次のタスクを実行する（= 前のタスクが終了することを待たない）作業１作業2 作業3 Time

Ajax（Asynchronous JavaScript And XML）非同期 JavaScript サーバーとデータをやり取りするための技術（今はあまり使われないけど…） JavaScript が非同期でサーバーとデータをやり取りする技術
= サーバーが返すレスポンスを待たずに画面の色んな操作ができる（ページの応答性が向上） Google Map をドラッグしたらその部分だけ読み込むあれ

Aページの一部更新フルリロードなしで更新される Ajax が解決した課題 - ページ一部更新のためにフルリロードしなくてよし（UX向上） - 毎度サーバーにリクエストせず済むからサーバーの仕事が減る

しかし JavaScript には問題があった当時（2000年代初期）の JavaScript は難しいしコード長くなるしとにかく使いづらかったのだなので Ajax が登場はしたものの、実装が難しい（10日でつくった言語だしね…）

そして 2006年、jQuery の登場「write less. do more.」というスローガン通りに、JavaScript の実装を簡潔にしてくれるライブラリー

補足）言語？ライブラリー？フレームワーク？言語コンピュータに命令を書くための道具ライブラリー言語を書くための便利ツール。自由度↑ フレームワーク言語を書くための便利ツール。自由度↓ ライブラリー: 便利ツールがあるので好きな時に好きなように使ってくださいエンジニア:
はい！フレームワーク: 便利ツールがあるので必ずこのガイドラインに従って使ってくださいエンジニア: はい！

補足）言語？ライブラリー？フレームワーク？言語コンピュータに命令を書くための道具ライブラリー言語を書くための便利ツール。自由度↑ フレームワーク言語を書くための便利ツール。自由度↓ ライブラリー: 便利ツールがあるので好きな時に好きなように使ってくださいエンジニア:
はい！フレームワーク: 便利ツールがあるので必ずこのガイドラインに従って使ってくださいエンジニア: はい！ちなみに何のライブラリーもフレームワークもない素の JavaScript を Vanilla JavaScript と言う

Ajax 通信を実装してみよう 2006年の Vanilla JS jQuery

jQuery が解決した課題 - Ajax処理を簡単に実装できる - クロスブラウザ対応（当時はブラウザ間の互換性が良くなかった） - DOM操作も簡単にできる

jQuery が解決した課題 - Ajax処理を簡単に実装できる - クロスブラウザ対応（当時はブラウザ間の互換性が良くなかった） - DOM操作も簡単にできる Netscape Navigator
(1994) Internet Explorer (1995) Google Chrome (2008) Mozilla Firefox (2002) Safari (2003) Opera (1996)

jQuery が解決した課題 - Ajax処理を簡単に実装できる - クロスブラウザ対応（当時はブラウザ間の互換性が良くなかった） - DOM操作も簡単にできる DOM…とは？

HTML は人のためのもの HTML HTMLはただのテキストなので、NOT人間（JavaScript、ブラウザなど）は HTML ままだと扱えないタイトルとテキストががある ?

HTML は人のためのもの HTML なので、NOT 人間も分かる形式に変換する必要がある、それが DOM だ！タイトルとテキストががある変換
タイトルとテキストががある DOM

DOM（Document Object Model） HTML をツリー構造のオブジェクト（object model）に変換したデカい JavaScript オブジェクト HTML DOM
変換

DOM（Document Object Model） HTML をツリー構造のオブジェクト（object model）に変換したデカい JavaScript オブジェクト実際の DOM
概念的には木構造

JavaScript の HTML 操作 HTML を DOM に変換したら JavaScript が
HTML を操作できるようになるボタンクリックしたらテキスト追加する、などの動的な動きが実装できる

DOM 操作: Vanilla JS vs jQuery (2000年代初期）要件ボタンをクリックすると <div
id="content"> に新しい <p> 要素を追加する（テキストは "こんにちは" ）実装 Vanilla JS jQuery

jQuery が解決した課題 - Ajax処理を簡単に実装できる - クロスブラウザ対応（当時はブラウザ間の互換性が良くなかった） - DOM操作も簡単にできる jQuery すごすぎる！
ということでjQuery の人気が約10年ほど続く

永遠はないのだ…、jQuery の限界 (1) DOMを直接操作することはコストが高い（可能性がある） DOM が変更される度にブラウザはレイアウトを再計算・再描画する

例）

ここで先頭 <li> のテキストを変更。ブラウザは「再計算が必要」というフラグだけ立てる (計算はまだ行わない) 例）

「再計算が必要」というフラグが立ってるので、ブラウザは「よし、一覧を最初から数え直そう！」と <li> たちを順番に高さを測って合計し、<ul> の新しい高さを計算・返す＊oﬀsetHeight: 要素の高さの一種例）

永遠はないのだ…、jQuery の限界 (1) DOMを直接操作することはコストが高い（可能性がある） DOM が変更される度にブラウザはレイアウトを再計算・再描画する規模が小さくいアプリケーションでは問題になりにくいけど、規模が大きくて複雑なアプリケーションだと深刻な問題になる

永遠はないのだ…、jQuery の限界 (2) クロスサイトスクリプティングのリスクがあるクロスサイトスクリプティング（Cross-site scripting、XSS） : 悪意あるコードをウェブサイトに挿入するセキュリティ攻撃

永遠はないのだ…、jQuery の限界 (2) クロスサイトスクリプティングのリスクがあるクロスサイトスクリプティング（Cross-site scripting、XSS） : 悪意あるコードをウェブサイトに挿入するセキュリティ攻撃悪い人: ククッ…ここに
JavaScript コードを入力してやる悪い人が入れたコードが実行されちゃう！エスケープ処理したら（= ただの文字列として扱うようにしたら）安全だけど、わすれたりミスったりしたらやられる

永遠はないのだ…、jQuery の限界 (3) 状態がどんどん増えて複雑になる状態（UIの情報）を追跡し、DOMがその状態を正しく反映させる手作業がとても手間こんなUIを考えてみましょう： - 商品一覧が表示されていて - 「お気に入り」ボタンを押すとアイコンが変わる
- 「表示モード（一覧 / グリッド）」でレイアウトが変わる - 商品の在庫がなくなると、自動的に「売り切れ」表示になる

永遠はないのだ…、jQuery の限界 (3) 状態がどんどん増えて複雑になる状態（UIの情報）を追跡し、DOMがその状態を正しく反映させる手作業がとても手間こんなUIを考えてみましょう： - 商品一覧が表示されていて - 「お気に入り」ボタンを押すとアイコンが変わる
- 「表示モード（一覧 / グリッド）」でレイアウトが変わる - 商品の在庫がなくなると、自動的に「売り切れ」表示になる大体これより状態全然多い・複雑なので実装・メンテがとても大変しかも状態が JS の方にあったり HTML タグの方にあったりしてもうよくわからない

永遠はないのだ…、jQuery の限界 (3) 状態がどんどん増えて複雑になる大規模アプリケーションになればなるほどスパゲッティが爆増 image from https://www.bbcgoodfood.com/howto/guide/how-cook-spaghetti スパゲッティコード（Spaghetti code）
コードがめちゃくちゃ絡まっててカオスでメンテがとてつもなく大変なコード

補足）jQuery の人気が落ちが他の理由 (1) モダンブラウザの進化 jQuery 登場当時はブラウザ同士互換性がよくなかったけど、モダンブラウザ同士の互換性が改善されて互換性対応がやりやすくなり、jQuery の存在意義が薄くなった (2) JavaScript
の進化 jQuery 登場当時は Vanilla JS を書くことが大変だったけど、JavaScript 自体もどんどん改善を重ねて今は Vanilla JS でも分かりやすくきれいなコードが書けるようになった 2006年の Vanilla JS 2017年ぐらいの Vanilla JS

整理 • Ajax の登場でで UX が向上した ◦ Ajax（Asynchronous JavaScript And
XML）: 画面遷移せず画面の一部だけを更新できる技術 • 2000年代の JavaScript は使い心地がとてもよくなかった • jQuery の登場でクロスブラウザ対応、Ajax、DOM 操作などが簡単に実現できるようになった • jQuery の DOM を直接操作する方式は以下の限界があった ◦ パフォーマンス悪化（DOM が変更される度にレイアウトを再計算・再描画する） ◦ セキュリティ的なリスク（XSS のリスクあり） ◦ 状態とか、そもそも WEB が複雑化（なのに構造はちゃんと整備されず）

SPA の登場（2000年代後半〜 2010年代前半頃）より複雑で大規模なWebアプリケーションを構築する需要が高まるまた、この頃スマートフォンが普及し始めていて、モバイルアプリも作られ始める WEB もモバイルアプリみたいにサクサクと動いたらよさそう！ということで、SPA という概念が登場 SPA
とは、Single-Page Application (＝単一ページのアプリケーション) の略称。

SPA の登場（2000年代後半〜 2010年代前半頃）単一ページとは？より複雑で大規模なWebアプリケーションを構築する需要が高まるまた、この頃スマートフォンが普及し始めていて、モバイルアプリも作られ始める WEB もモバイルアプリみたいにサクサクと動いたらよさそう！ということで、SPA という概念が登場
SPA とは、Single-Page Application (＝単一ページのアプリケーション) の略称。

初期の MPA SPA の動作今回もまずは登場人物紹介から NEW!

初期の MPA SPA の動作今回もまずは登場人物紹介から NEW! WEBサイトがもっとインタラクティブでリッチなUIを求められ、フロントエンドという領域が生まれる

SPA の動作サーバーが HTML を生成して送信するのではなくクライアント側で Javascript が HTML を生成する (1)
ページリクエスト (2) データリクエスト (3) JSON 返す (5) 空の HTML に JS で画面を描画する JSON → データフォーマット (4) アプリケーションに必要な　すべてのJS と空の HTML 返す

(5) Bページ開く (7) Cページ開く (9) Dページ開く (2) Aページ表示クライアントのJSが新しい画面描画クライアントのJSが新しい画面描画クライアントのJSが新しい画面描画 (3) Bページ開く JSON JSON データリクエスト

(5) Bページ開く (7) Cページ開く (9) Dページ開く (2) Aページ表示クライアントのJSが新しい画面描画クライアントのJSが新しい画面描画クライアントのJSが新しい画面描画＊この時点でアプリケーション全体に必要な　すべてのJSをクライアントに送信する (3) Bページ開く JSON JSON データリクエスト

(5) Bページ開く (7) Cページ開く (9) Dページ開く (2) Aページ表示クライアントのJSが新しい画面描画クライアントのJSが新しい画面描画クライアントのJSが新しい画面描画＊サーバーにリクエスト送らない (3) Bページ開く JSON JSON データリクエスト

(5) Bページ開く (7) Cページ開く (9) Dページ開く (2) Aページ表示クライアントのJSが新しい画面描画クライアントのJSが新しい画面描画クライアントのJSが新しい画面描画＊追加データが必要な　場合はリクエスト送る (3) Bページ開く JSON JSON データリクエスト

(5) Bページ開く (7) Cページ開く (9) Dページ開く (2) Aページ表示クライアントのJSが新しい画面描画クライアントのJSが新しい画面描画クライアントのJSが新しい画面描画＊受け取ったデータでクライアント側の JS が画面描画 (3) Bページ開く JSON JSON データリクエスト

(5) Bページ開く (7) Cページ開く (9) Dページ開く (2) Aページ表示クライアントのJSが新しい画面描画クライアントのJSが新しい画面描画クライアントのJSが新しい画面描画 (3) Bページ開く JSON JSON データリクエスト WEBアプリケーションに初めてアクセスしたときだけ HTML を返す = HTML が1つ（単一ページアプリケーション）

初期の SPA は基本的に CSR CSR とは、Client side rendering (＝クライアント側のレンダリング)
の略称。 (1) ページリクエスト (2) データリクエスト (3) JSON 返す (4) アプリケーションに必要な　すべてのJS と空の HTML 返す (5) 空の HTML に JS で画面を描画する画面を描画するのはクライアントで読み込まれたJavascript

SPA のよさ初期アクセス時点でアプリケーションに必要なすべてのコードが揃ってる＝Javascriptで一部だけ更新ができるので、フルリロードせず画面更新ができる Aページの一部更新フルリロードなしで更新される (+ 画面遷移するときサーバーまでいかなくてもいいのでサクッと画面遷移できる)

SPA を実現するためのフレームワーク & ライブラリーの登場 React (2013) Vue.js (2014) Angular (現行版
2016) 各技術はそれぞれ違うやり方でコードの構造化や状態管理の難しさという課題を解決している

React (2013) Vue.js (2014) やっと React の話ができる各技術はそれぞれ違うやり方でコードの構造化や状態管理の難しさという課題を解決している SPA を実現するためのフレームワーク
& ライブラリーの登場 Angular (現行版 2016)

整理 • 複雑・大規模なWeb構築の需要が高まる中、SPA（Single-Page Application）が登場 ◦ SPA → 初期アクセス時に空のHTMLとJSを受け取り、JS画面を描画するアプリケーション • 当時の
SPA 基本 CSR（Client side rendering）方式だった ◦ CSR → クライアントサイドでDOMを更新する手法 • SPA はスムーズな操作体験ができることが良い • SPA を実現するためによく使われる技術は React、Vue.js、Angular などがある

React UI を構築するための JavaScript ライブラリ Meta（旧Facebook）が2011年から社内用に開発していたライブラリを2013年に一般に公開

React のメインコンセプト (1) コンポーネントベースアーキテクチャ (Component-Based Architecture) 複雑なUIを「コンポーネント」と呼ばれる小さく、独立し、再利用可能な部品に分割して構築する考え方 image from https://react.dev/learn/thinking-in-react

React のメインコンセプト (1) コンポーネントベースアーキテクチャ (Component-Based Architecture) 複雑なUIを「コンポーネント」と呼ばれる小さく、独立し、再利用可能な部品に分割して構築する考え方 image from https://react.dev/learn/thinking-in-react
それぞれのコンポーネントは、自分自身の見た目や動作のロジックを持っているメリット (1) 複雑なUIも管理しやすくなる (2) コンポーネントの再利用ができる

React のメインコンセプト (2) 宣言的UI（Declarative UI） UIがどのようになってほしいかを React に伝えるだけで実装できる命令的な jQuery
宣言的な React 作りたいこと↓

宣言的な React fruits 配列定義して、 <ul>タグ取得して、 <li> タグ生成して(テキストは配列の要素にする) 取得した <ul> に作った <li> 足して「どう作るか」の手順を全部書く作りたいこと↓

宣言的な React fruits 配列定義して、こういう見た目で出して手順じゃなくて、あるべきをそのままかく（UIの構造がそのままコードの形になる）作りたいこと↓

React のメインコンセプト (2) 宣言的UI（Declarative UI） UIがどのようになってほしいかを React に伝えるだけで実装できる宣言的な React
もし状態に変化があったら React が勝手に探知してUIをアップデートしくれる (className や id などで DOM を取得する必要がない) 後でログイン状態が変わっても React が出し分けしてくれるメリット (1) よりシンプルで予測可能なコード (2) 状態管理がやりやすくなった

React のメインコンセプト (3) 仮想 DOM（Virtual DOM）実際のDOMの軽量なコピー（JavaScript Object）を用いて、DOM操作を最小限にする

React Code Virtual DOM 仮想 DOM

Virtual DOM 仮想 DOM Like ボタンを押していいね数が増えたとしましょう React Code

Like ボタンを押す前の Virtual DOM 仮想 DOM の動き Like ボタンを押した後の Virtual
DOM 比較（reconciliation）差分はここだけだから最小限の範囲だけDOM操作しよう！

DOM 直接操作 vs 仮想 DOM DOM 直接操作 jQuery などで直接DOM操作すると、書きと読みを同タスクで混在しやすくなるそのため無駄に再計算・再描画が多発することがある
仮想 DOM DOMを直接操作する前に仮想DOMで差分を探知して、まとめて1回だけ直接 DOM 操作するその後ブラウザが再計算・再描画をを1回走らせれば済むので、ムダが激減ブラウザ: DOMが変わったから最初から計算しないと、、え、また変わった？じゃまた最初から計算しないと（これをムダにいっぱいやる） React: (仮想DOMで差分をまとめる) この部分だけ変更されたので反映してください。読みは反映終わった後に実行されるので気にせず。ブラウザ: はい！再計算・再描画しました！（終了） (最適化しようとしたらできるけど手動でやるのが大変に)

React が解決した課題 - 複雑で大規模なアプリケーションも体系的に開発できる – DOM操作も最小限に抑えられる

React が解決した課題 - 複雑で大規模なアプリケーションも体系的に開発できる – DOM操作も最小限に抑えられる +) XSS が起こりにくくなった（完全防止ではないが）悪い人:
ククッ…ここに JavaScript コードを入力してやる React がデフォルトで文字列にしてくれるので実行されない！

しかし、SPA には課題があった (1) 初回ロードが遅い初アクセス (空の)HTML ダウンロード Javascript ダウンロード Javascript
実行 APIデータフェッチ 1番時間かかる (アプリ全体のコードをこのときダウンロードするから＆JSは重いから) 初アクセス＊MPAの場合 HTML ダウンロード

しかし、SPA には課題があった (2) SEO に弱い初アクセス (空の)HTML ダウンロード Javascript ダウンロード
Javascript 実行 APIデータフェッチ

しかし、SPA には課題があった (2) SEO に弱い初アクセス (空の)HTML ダウンロード Javascript ダウンロード
Javascript 実行 APIデータフェッチクローラーは判断する「このページは中身がないからSEO点数低くていいっしょ」クローラー: Webサイトの情報を収集し、自動的にデータベース化するプログラム＊現在はCSRも対応できるクローラーもある

この２つの課題（初期ロード遅い＆SEO弱い）が場合によってはあまりにも致命的で、、特にtoC向けサイト

整理 • React はUI を構築するための JavaScript ライブラリ • React のメインコンセプト
◦ コンポーネントベースアーキテクチャ（Component-Based Architecture） ◦ 宣言的UI（Declarative UI） ◦ 仮想DOM（Virtual DOM） • ただ、SPA の課題感が高まる ◦ 初回ロードが遅い ◦ SEO に弱い

SPA に SSR を！ SPA の限界克服のために、SPA にも SSR 導入しよう！という流れが生まれる

SPA に SSR を！ SPA の限界克服のために、SPA にも SSR 導入しよう！という流れが生まれる (1)
ページリクエスト (2) データリクエスト (3) JSON 返す (4) アプリケーションに必要な　すべてのJS と空の HTML 返すリクエスト時にサーバーサイドでHTMLを生成する手法 SPA SSR（Server-side rendering）＋

SPA に SSR を！ SPA の限界克服のために、SPA にも SSR 導入しよう！という流れが生まれる (1)
ページリクエスト (2) データリクエスト (3) JSON 返す (4) アプリケーションに必要な　すべてのJS と空の HTML 返すリクエスト時にサーバーサイドでHTMLを生成する手法 SPA SSR（Server-side rendering）＋ 🤔

SPA に SSR を！初期SPAの課題: 初回ロードが遅い、SEOに弱いこの課題を解決するため、クライエント側の JS がレンダリングする代わりに、
各ページに対してリクエストがきたらサーバーで HTML を作ろう！という発想が登場する

SPA + SSR の動き (1) ページリクエスト (2) データリクエスト (3) JSON
返す (1)から(3)までは初期SPAと同じなので、　　のところを詳しく見ていく

SPA + SSR の動き (3) JSON 返す (4) HTML を作る
(5) HTML、JS送信 (7) JS実行 (6) HTML表示空のHTMLではなく、ページ表示に必要な HTML を作るこの時点では JS が実行されてないので、インタラクティブではないここでインタラクティブになる EX) ボタン押してもなにも起きない SPAだけど、サーバーでHTMLを作成してクライアントに送信する

(3) JSON 返す (4) 空のHTML、 JS送信 (6) JS実行 (5) 空のHTML表示
SSR がない場合（素の SPA） (3) JSON 返す (4) HTML を作る (5) HTML、JS送信 (7) JS実行 (6) HTML表示 SSR がある場合

補足）Hydration という概念 (5) HTML、JS送信 (7) JS実行 (6) HTML表示 Javascript を実行してページをインタラク
ティブにすることを Hydration と言う＊Hydration は水分供給という意味（ドライな HTML に水分を供給する、で覚えたらいいかもしれない） (3) JSON 送信 (4) HTML を作る

SPA + SSR が解決した課題初アクセス (空の)HTML ダウンロード Javascript ダウンロード Javascript
実行 APIデータフェッチ初アクセス HTML ダウンロード Javascript ダウンロード Javascript 実行 APIデータフェッチ＊SSR のない SPA この時点でページのコンテンツが見れる (1) 初期表示速度の改善

SPA + SSR が解決した課題 (1) 初期表示速度の改善初期表示速度が改善され、SPAのメリットであるサクッとした画面更新・遷移ができることがデカい初アクセス HTML表示インタラクティブになる
SPAなのでページ更新はJSでさくっと（画面遷移も）

SPA + SSR が解決した課題 (2) SEO改善初アクセス (空の)HTML ダウンロード Javascript
ダウンロード Javascript 実行 APIデータフェッチ初アクセス HTML ダウンロード Javascript ダウンロード Javascript 実行 APIデータフェッチ＊SSR のない SPA 空のHTMLではないので、クローラーがちゃんとクローリングできる

SPA + SSR を実現できるフレームワーク & ライブラリー各技術はそれぞれ違うやり方でSPAの課題を解決している React Framework React
Framework React Framework Vue.js Framework

各技術はそれぞれ違うやり方でSPAの課題を解決している React Framework React Framework React Framework Vue.js Framework やっと
Next.js の話ができる SPA + SSR を実現できるフレームワーク & ライブラリー

2016年、Next.js の登場 Next.js は、WEB アプリケーション構築のための React フレームワーク

Next.js のメインコンセプト (1) ゼロコンフィグ (Zero Conﬁg) いい感じの設定がデフォルトで入っているので設定なしでもすぐ開発できる設定できないわけではない！必要な設定は自分で入れられる

Next.js のメインコンセプト (1) ゼロコンフィグ (Zero Conﬁg) いい感じの設定がデフォルトで入っているので設定なしでもすぐ開発できる設定できないわけではない！必要な設定は自分で入れられる react はライブラリーなので自由度高いけど、
その分高度なことをやるときはいちいち自分で設定したり作らないといけない

Next.js のメインコンセプト (2) ファイルシステムベースのルーティングファイル名とディレクトリ構造に基づいて自動的にルーティングを設定ディレクトリ URL ルーティング（Routing）: URLに応じて、どのページやコンテンツを表示するかを決める仕組み

Next.js のメインコンセプト (2) ファイルシステムベースのルーティングファイル名とディレクトリ構造に基づいて自動的にルーティングを設定ディレクトリ URL ルーティング（Routing）: URLに応じて、どのページやコンテンツを表示するかを決める仕組み React
はルーティング機能がないのでルーティングのためのライブラリー入れて自分で実装する必要がある（以下は React Router の実装例）ルーティングのためだけに Next.js つかいたいという声もある

Next.js のメインコンセプト (3) 多様なレンダリング戦略ページごとに最適なレンダリング手法を選べる

Next.js の Pre-rendering Next.js は基本的にすべてのページを Pre-rendering する = クライエント側の JS
がレンダリングする代わりに、各ページに対して HTML を予め作っておく＊pre = 事前に

Pre-rendering(= サーバー側でHTMLを生成する) には 2 種類がある • SG（Static Generation、静的生成） • SSR（Server-side
Rendering、サーバー側のレンダリング）

SG（Static Generation、静的生成） HTML がビルド時に生成され、ずっと同じHTMLが配信される

補足）ビルド（Build）とは人が開発用コードを、サーバーが使える形に変換する作業リクエストレスポンスビルド </> </> サーバーにアップ (デプロイ) これは人のための言語、フレームワーク
なのでこのままだとサーバーは扱えない </>

補足）ビルド（Build）とは人が開発用コードを、サーバーが使える形に変換する作業リクエストレスポンスビルドサーバーにアップ (デプロイ) サーバーが扱える形に変換 +) 色々最適化（JS・CSSファイルをまとめるなど）
</> </> </>

SG（Static Generation、静的生成） HTML がビルド時に生成され、ずっと同じHTMLが配信されるリクエストレスポンスビルドサーバーにアップ (デプロイ) この時点でもうHTMLが完成していて、
変わることはないこういう時に適切: - ページに必要なデータがビルド時点で揃っている場合 - ページが頻繁に更新されない場合例）ニュースページ、FAQページなど </> </> </>

SG（Static Generation、静的生成） HTML がビルド時に生成され、ずっと同じHTMLが配信されるリクエストレスポンスビルドサーバーにアップ (デプロイ) この時点でもうHTMLが完成していて、
変わることはないこういう時に適切: - ページに必要なデータがビルド時点で揃っている場合 - ページが頻繁に更新されない場合例）ニュースページ、FAQページなど </> </> </> 後発で ISR(Incremental Static Regeneration) という更新される SG も登場する

SSR（Server-side Rendering、サーバー側のレンダリング） HTML が各リクエストの度に生成され、毎回新しく生成したHTMLが配信されるリクエストレスポンスビルドサーバーにアップ (デプロイ) リクエストが来る度に
HTML 生成 </> </> </>

HTML 生成こういう時に適切: - リクエスト時にしかわからない情報に依存するページの場合 - ページが頻繁に更新され、常に最新の情報を表示する場合例）ログイン後のマイページ、検索結果ページなど </> </> </>

HTML 生成こういう時に適切: - リクエスト時にしかわからない情報に依存するページの場合 - ページが頻繁に更新され、常に最新の情報を表示する場合例）ログイン後のマイページ、検索結果ページなど MPA の SSR と完全に同じではない（こっちはサーバー側Reactコンポーネントをでレンダリングし、クライアント側でHydrationを行う） React のための SSR という感じ </> </> </>

もちろん、SPA + SSR にも課題がある (1) HTML作るに時間かかる & サーバーに負荷かかるサービスの規模が大きいほど課題感がたかまる＊ここで必要なデータをフェッチして、
　それをもとにHTMLをつくるリクエストの度にHTML作る = HTML作ってる間は画面が表示されない = サーバーが重労働

もちろん、SPA + SSR にも課題がある (2) HTML 描画から Javascript 実行まで時間かかる見えてるけど押せないんだが？の時間がある
HTML表示インタラクティブになるコンテンツが見えるまでは早くなったけど、 TTI (Time to interactive) になるまで時間かかる

この課題を解決するために React と Next.js はまた新しい技術やアプローチを導入し続けている

整理 • WEB アプリケーション構築のための React フレームワーク • Next.js のメインコンセプト ◦
ゼロコンフィグ (Zero Conﬁg) ◦ ファイルシステムベースのルーティング ◦ 多様なレンダリング戦略 ▪ SG（Static Generation）→ ビルド時に HTML 生成 ▪ SSR（Server-side Rendering）→ リクエスト時に HTML 生成 • SPA + SSR にも課題がある ◦ HTML作るに時間かかる & サーバーに負荷かかる ◦ HTML 描画から Javascript 実行まで時間かかる

最後に

フロントエンドという分野は比較的に新しく、現在進行形で激しく進化しています。ですが、どの技術であっても各技術は必ずなにかの課題を解決するため生まれました。それを理解したら、どの場面でどの技術を使えばいいか選べるようになります。一緒にフロントエンドアプリケーションいい感じにしていきましょう！

ご清聴ありがとうございました

- wikipedia, 「JavaScript」, https://ja.wikipedia.org/wiki/JavaScript - zenn, 「【レンダリング大全】CSR, SSR, SPA, MPA,
PPRの意味、そもそもレンダリングとは【2025 年始】」, https://zenn.dev/txxm/articles/f04b21949ddab3 - Tejas Kumar, 『Fluent React』, O’Reilly , 2024 - 大岡由佳, 『りあクト！ TypeScriptで始めるつらくないReact開発【② React基礎編】』、2025 参考資料 ChatGPT と Gemini にサンプルコード作ってもらいました

【2025年新卒研修】 React・Next.js は何であるのか

【2025年新卒研修】 React・Next.js は何であるのか

More Decks by Jeongmin LEE

Featured

Transcript