😎
React, Next.js何を使うべきか：過去ではなぜReactだったのか、今はなぜNext.jsが必要か

2025/05/13に公開
1件
Next.js
React
tech
 前置き今回は具体的な技術の話をする前に、

まず二つの疑問について議論したいと思っています。
一つ目は、なぜReactを今まで使っているか

二つ目は、今はなぜNext.jsを使っているかと言う疑問点になります。
これによって技術に対する理解度を向上、何を選択する方が良いかの根拠にもなると自分は思っています。
もちろん、この背景を知らなくても結論を出すことも可能ですが、

特に今回、議論対象になるReactはバニラJavaScriptを改善するために作られたライブラリであり、

Next.jsはReactをどの部分を改善するために作られたフレームワークのため、

この機会にしっかり議論したいと思います。
本記事はの第一回目の記事として、技術的な話題よりも、

まずはこうした技術が登場するに至った背景についてお話したいと思っています。
もちろん、ここで話す内容はあくまで私個人の経験や考えに基づくものであり、

事実とは異なる可能性もありますので、ぜひご自身でのクロスチェックいただけたらと幸いです。

 CSRが登場/発展した背景
 概要背中では流行というものが存在します。

もちろんプログラミング言語の世界でも流行は存在します。
ファッションの世界でスタイルとか洋服とかにも流行があることと同様です。

現在、フロントエンドに限ってはReactが流行と言っても過言ではないでしょう。
自分はこの流行って言うものは大分何かの飽きから来ていると思っています。
IT業界でこの飽きは技術的な限界から大分来ていると考えております。
では、当時、Reactが世界に現れる前、流行になった前は

どのような技術的な限界があるのでしょうか。
これを理解するためには、約20年前に何の言語を使っているかを含めて

当時の技術的な問題をまず確認する必要があります。
当時に使った技術スタックは以下の通りです。

 20年前の技術スタックについてバックエンド

PHP, JAVA
フロントエンド

JavaScript、HTML、CSS
ご存知の通り、当時はSSR(Server Side Rendering)技術を利用しており、

ほぼ全ての処理,つまりロジック処理からHTML変換(Rendering)まで担当していて

フロントエンドはほぼそのまま表示するだけのため、

いわゆる、フロントエンド作業はマークアップしかなかったです。
そのため、バックエンドエンジニアがフロントエンドを開発する時もありましたし

デザイナが開発場合もたまたまありましたね。
なので、明確なバックエンド/フロントエンドが分類された時代ではありません。
この時代に開発されたソリューションを確認してみましょう。

 20年前のソリューション

画像は22年前、2003年のYAHOOサイト[1]になります。

ご覧の通り、画面にはほぼリンクしか存在しません。


こちらは、現在世界的に良く使われている

2006年当時のYouTube[2]になります。
2003年のYAHOOと同様にリンクだらけですね。

この通り、フロントエンド側での作業はほぼサーバーでもらった内容を表示するだけです。

 その以後についてその以後、Ajax, jQueryなど非同期通信技術の向上はありましたが、

パラダイムシフトが起きるぐらいではありませんでした。
しかし、2000年代後半、パラダイムシフトがついに発生しました。
Apple社のIPhoneの登場です。

 過去ではなぜReactだったのかこう言う流れでCSR技術が発展した背景について、

大きく以下の3点かと思います。
パラダイムシフト
SSRに対する技術的な限界
当時のサーバーの限界
この3点についてもう少し詳細に話して見ましょう。

 パラダイムシフトこのIPhoneという超小型デバイスの登場は、

単純な新しいハードウェアの登場ではなく、パラダイムシフトを発生させました。
なぜかと言うと、IPhoneは超小型PCだからです。
全体的なPC利用者は増加され、ビジニスエリアの拡張。

インターネット速度増加・整備拡張、IDCからクラウドへ転換、

単純なアプリからフラットフォームまで色んな新たなビジニスが生まれました。
ビジニス的に良く活用している会社はGoogleやAppleではないかと思っています。
次は、フロントエンド観点で見て見ましょうか。

単純なページを集まったWebサイトからWebアプリケーションまで向上されたと思います。
具体的には、PC/モバイル両方対応できるレスポンシブウェブの普遍化から

柔らかなアニメション挙動のための、状態管理、DOM操作、ロジック処理などまで

フロント側の作業量が多くなり、
JavaScript基盤のライブラリ/フレームワークである、

SPA(Single Page Application)と言う概念で、Angularから初めて

React、Vueが開発され今まで、フロントエンド開発ツールで使われています。
あと、Apple社が柔らかなアニメション挙動、デザインと言う

いわゆる、利用者観点で上品のUI・UXが求めているため、

自然的にウェブアプリケーションも良いクオリティーの求める必要があると言う状況も一つの理由になるかと思います。
こう言う状況はフロントエンド/バックエンドをしっかり区分するきっかけになったと自分は思っています。
そのため、iPhoneと言うスマートフォンの登場を産業革命とは言えませんが、

パラダイムシフトと認識しても十分ではないでしょうか。
もちろん、この記事を作成している現時点ではNN(Neural Network)基盤のAIによって、

新しいパラダイムシフトが起ころうとしていると言っても過言ではありません。
これは、別の話にはなりますが、

機会があれば別の記事で紹介したいと思います。

 サーバーサイドレンダリング(Server Side Rendering, SSR)の限界次は、主にサーバー観点でSSRに対する設備/技術的な限界についてお話したいと思います。
まずはSSRについて簡単に紹介してから本論に行きましょう。
SSRで開発されている前提でYahooサイトに接続すると裏ではどんな処理が行いますでしょうか。

 SSRについて
上の画像の通り、

基本的にSSRの場合サーバー側でデータ含まれているHTMLを

ブラウザー(クライアント)に送信する特徴があります。
そのため、初期ページが早く開ける特徴がありますが、

ページ遷移の時、サーバーから新たなHTMLをもらう必要ありと言うデメリットも存在します。
このデメリットよって当時は色んな問題が発生しまいます。

 SSRに対する技術的な限界/当時のサーバー設備の限界SSRの限界については技術的な限界だけではなく、

サーバー側の設備的な問題も繋がっているのでまとめてお話したいと思っています。
以下のように大きく3点になります。
サーバー増設や管理による運用コストの増加
データ取得に伴う長いローディング時間
スムーズなインタラクティブ機能実装不可

 サーバーの増設・管理による運用コストの増大/データ取得のための長時間のロードスマートフォンの登場によって、

サーバーに接続するデバイス（クライアント）も増加されるので

既存の設備だとサーバーが耐えられないことは当然なものです。
ただ、SSRのレンダリングプロセスはサーバー負荷を増加してしまうデメリットが存在します。
もう一度、レンダリング図を確認して見ましょう。
画像の上では、

Userがwww.yahoo.co.jpに接続するようにする時のプロセスになります。
ただ、SSRの場合は他のページに遷移する時、



例えば、メインページからニュースページに遷移する時にサーバーはプロセスを再度実施します。
これはページのテキストが一文字変更されても、ページをリフレッシュしても、

サーバーはDBからデータを取得して、データをHTMLに取り組む作業を行います。
そのため、SSRは必然的にサーバー負荷を増加する特徴を持っています。
あと、サーバー側はDBからデータを取得して、HTMLファイルにデータを取り込む時間が必要なため、

状況によってChromeはサーバーからファイルが届く前待機する必要があります。
現在はインターネット速度が早くて

SSRで実装されているページに接続してもあまり感じられませんが、
20年前頃では、上の画像みたいに頻繁にページが開くまで1分ぐらい待ったサイトが多かったです。
もちろん現在もSSRを採用しているサイトは同じ特徴持っています。

ただ、ネットのスピードが早い時代になったので、一瞬ページがブランクされます。

 インタレクティブ機能実装の限界SSRではインタレクティブ機能も実装がかなり難しいです。


良く使われている機能としてはオートコンプリート機能があります。
今の状況で文字一つでも入力すると



上の画像通り、ボックス内のリストが新たに表示される機能になります。
もちろん、SSRでも十分実装は可能ですが少し問題があります。
サーバーの状況によってリスト切り替えが遅くなる
強制にページがリフレッシュされる/一瞬白い画面がブランクされる
上の理由でスムーズなリスト転換ができません。
そのため、インタレクティブ機能はサーバー側ではなく、

クライアント(ブラウザー)でレンダリングする必要があります。
結論的には、SSRで機能実装は可能ですが、UX観点では良いとは言えないです。
この問題を解決するために選ばれたものが、

皆さんもご存知のAJAX(Asynchronous JavaScript and XML)です。
今はAJAXはどのサイトでも入っている当然な技術にはなったんですが、

役20年前、Googleが2000年代にGmail, Mapsでスムーズな挙動感を与えて有名になった技術が

このAjaxと言う非同期通信技術になります。

 過去ではなぜReactだったのかこの状況で、過去から今までReactを使っているかについて回答ができるかなと思います。
データ取得に伴う長いローディング時間、インタラクティブ機能実装不可と言うSSRの技術的な問題、

スマートフォンと言うクライアントデバイスの急速な増加によるサーバー拡張必要と言う設備的な問題が当時には存在したと自分は思っています。
Reactに転換する場合は、インタレクティブ機能はもちろん、

画像DOMと言う新たな概念によって綺麗なデータ/UIの切り替え

コンポーネント単位でUIを開発することで、再利用性向上も可能です。
さらに、新しい技術を使いたいと言うエンジニアなら誰でも持っている病気も解消できるので、

これは逆に使わない理由を探すのが難しいではないでしょうか。
JavaScriptライブラリー/フレームワーク内では人気があったので先占効果もあると思います。

 Client Side Renderingについてこの結論を認識した上で、CSRについて軽く紹介したいと思っています。
ご覧の通り、SSRと大分違うどころは

レンダリングとデータ取得がしっかり分離されていることが確認できます。
特徴として最初リクエストする時に、index.htmlファイルだけリクエストしますが、

その中には、普通のHtml内に以下のタグが含まれています。
<link rel="stylesheet" href="/style.css" />
					・・・
<div id="root"></div>
<script src="/bundle.js"></script>
Reactの場合、上の三つのタグがポイントになりますが、

React、Vue、Angularなどのライブラリー/フレームワークコードが含まれているBundleファイル、

ページのスタイルに対するCSSコードが含まれているCSSファイル、

最後はidがrootであるDivタグです。
恐らく、Reactを少しでも使ったことある方であれば、

以下のコードを見たことあると思います。
index.js
import React from 'react';
import ReactDOM from 'react-dom/client';
import App from './App';

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
);
つまり、idがrootであるDivタグはreactエンジンとindex.htmlを繋がるための、コードになります。

 CSRのメリットはデメリットCSRを利用することによってSSRを採用した時に現れた問題を大分解決できます。
特に、テキスト、ボタンなどのUIを綺麗に転換させる画像DOMの存在はUXを向上、

コンポーネント単位と言うルールはUIの再利用可能によって、

全体的な生産性が向上したことも重要なメリットかと思います。
ブラウザーはデータが取り込まれているHTMLファイルを待つ時間も必要ないし、

総合的にはサーバー負荷が減少するので、サーバー代も減ります。
ただ、CSRでも大きく3点のデメリットが存在します。
フロントエンド側のコードが重くなるほど、Bundleサイズが増加によって

初期ページローディング/コードパーシング・解析時間増加
index.htmlには実際のコンテンツが含まれてないため、

SEO（Search Engine Optimization／検索エンジン最適化）に不利
セキュリティー問題
3番は過去でも指摘されている問題のため、ご存知かと思いますが

この中で2番は場合によって結構クリティカルな問題になります。
特に、Zenn見たいなブログ系のサイトなら致命的ですね。
なぜかと言うと、Googleなどの検索エンジンクローラー（ボット）は

基本的にはページのindex.htmlファイルを参考して、

表示するタイトル、内容などを含めて、これを表示するかどうかもアルゴリズムによって決定します。
そのため、index.htmlにコンテンツが含まれてない
<link rel="stylesheet" href="/style.css" />
					・・・
<div id="root"></div>
<script src="/bundle.js"></script>
つまり、index.htmlファイル内に上の構成を持っている

CSRを採用しているウェブアプリはSEOに関しては上手く制御することができません。
もちろん、クローラーがJavsScriptを解析可能であれば問題ないかもしれませんが、

可能でもクローラーではしっかり読み込んでくれるでしょうか。
どんなアルゴリズムでクローリングしているか公開されておりませんので

クローリングする/しないページの条件などが確認できませんが、

もしかしたら、リソースの減少のため、大分のサイトは無視するかもしれません。
こう言うCSRの問題が認識された時にReactフーレムワークがNext.jsになります。

 終わり今回の記事は、技術的な分析というよりも、

あくまで個人的な視点に基づいた内容であるため、

一部に誤りや偏りがあるかもしれませんが、

各技術が必要とされた背景については、ある程度ご理解いただけたのではないかと思います。
結論的に、過去ではなぜReactだったのかについては

パラダイムシフト、当時のSSRの限界、サーバー増設問題とを言う三つで整理できます。
React見たいなJavaScriptライブラリー/フレームワークを利用、

つまり、SSRからCSRの転換は三つの問題を大分解決可能になりました。
特にサーバー増設問題に関してはトラフィックによって利用代請求される

クラウドサービス、AmazonのAWS、 MSのAzure、GoogleのGoogle Cloud Platformなどの大手クラウドサービスによって大分解決できました。
しかし、Reactコードが重くなるほどBundleサイズの増加、

初期ページのローディング時間も増加される問題と

特にSEOが上手くできないことは致命的なデメリットになります。
こう言う状況でリリースされたのが、Next.jsになります。
次回の記事では、いよいよNext.jsとReactを本格的に比較しながら、

Hydration、SSG(Static Site Generation),ISR(Incremental Static Regeneration)の紹介

そして得られるメリット・デメリットについて整理し、

この記事の最終的な結論を導き出したいと考えています。

脚注
https://techblog.yahoo.co.jp/entry/20190530678295/ ↩︎
https://www.webdesignmuseum.org/gallery/youtube-2006 ↩︎