はじめに
こちらは エーピーコミュニケーションズ Advent Calendar 2025 4日目の記事です。
突然ですが、Web技術を触り始めた頃はいわゆる LAMP 環境が主流で、PHP＋jQuery＋WordPress でコーポレートサイトを作ったりカスタマイズしたりしていました。
HTML5 / CSS3 や viewport を触り始めたあたりを最後に、フロントエンドからはしばらく離れています。
その後はインフラエンジニアとしてオンプレやクラウド関連の仕事が中心で、「フロントも多少はわかるインフラエンジニア」くらいの気持ちでいました。
しかしながら技術のモダン化進んでいき、IaC やクラウド、生成 AI の普及もあってフロントとインフラの境界が曖昧になり、生成 AI に Web UI や管理画面のコードを出力させると、ほぼ React＋TypeScript 前提になることも増えてきました。
このまま雰囲気で読み続けるのは厳しいと感じたため、一度最低限レベルでキャッチアップしてみることにしました。
本記事はその中で整理した、JavaScript / TypeScript / React の関係や React の考え方、LAMP 時代との違いなどのメモです。
JavaScript / TypeScript / React の関係
JavaScript、TypeScript、React は、それぞれ別レイヤの役割を持っています。
言語レイヤ
前提となる言語は JavaScript で、ブラウザや Node.js が実行する本体です。
TypeScript はそこに型付けなどを足した言語で、そのままでは動かず、JavaScript にコンパイルされてから実行されます。
ざっくり言うと、実際に動いているのはいつも JavaScriptで、TypeScript は開発中に安全性や補完を効かせるための言語という整理です。
ライブラリ／フレームワークレイヤ
その上に、UI を構築するためのライブラリとして React があります。
React は JavaScript や TypeScriptから利用する形で動きます。
さらに React を基盤に、ルーティングや SSR など、Web アプリ全体を包括するフレームワークとして Next.js があるようです。(他にもたくさんありそうです)
React や Next.js はあくまでJavaScript のライブラリ・フレームワークであって TypeScript そのものではありませんが、最近のプロジェクトでは最初から TypeScript で書かれることが多く、React のコードを読む＝TypeScript も一緒についてくるくらいの感覚になっている、と理解しました。
React の本質として UI は状態（State）から導出される
React を理解するため公式ドキュメントを読んでみました。
なんとこれだけで80%の内容がわかるそうなので、表層をだけを学習するのであればピッタリですね！
このページでは、日々の開発で使用する React のコンセプトのうち 80％ の部分を紹介します。
React とは、DOMを直接操作することではなく、状態から UI を決める「宣言的 UI」のとなっているそうです。
jQuery 的なやり方では、UI を変えたい → DOM を探す → 中身やクラスを直接書き換えるという流れですが、React では状態を変化させることで、あらかじめ決めているUIを状態に合わせて表示するようです。
コンポーネントの状態が変わると、React が差分を見て UI を再レンダリングするので、自分は最終的にどう見えていてほしいかだけを宣言し、実際の変更は状態の更新に寄せるイメージになります。
| 概念 | 役割 |
|---|---|
| コンポーネント | UI の部品 |
| props | コンポーネントへの入力値 |
| state | UI の変化元となるデータ |
| hooks | state や副作用を扱う仕組み |
| 再レンダリング | state の変化によって自動で発生する更新 |
レガシー（LAMP＋jQuery）時代との比較
自分が触れていた頃の LAMP＋jQuery の世界と、現在主流の React＋周辺技術の構成を比較すると、役割の置き方がだいぶ違うことが分かります。
| 観点 | レガシー時代（LAMP＋jQuery） | モダン（React＋周辺） |
|---|---|---|
| 画面の生成 | PHP が HTML をサーバー側で組み立てる | Next.js などが SSR/SSG を担い、必要に応じてクライアント側で React が描画 |
| UI の構築 | サーバーサイドテンプレート＋生 HTML | React コンポーネントで宣言的に定義 |
| 動きの実装 | jQuery で DOM を直接操作 | state が変われば React が自動で再描画 |
| ページ遷移 | URL ごとに PHP スクリプトを用意 | Next.js がルーティングを担当 |
| ビジネスロジック | PHP が UI とロジックを両方抱える | UI（React）と API（Node.js / Serverless）が分離 |
| データ取得 | PHP が DB にアクセスし HTML に埋め込む | フロントは API を叩き、DB は API 側に閉じる |
| ステート管理 | セッションや jQuery プラグインなどが散在 | state、React Query、状態管理ツールに整理 |
| デプロイ | Apache / Nginx に PHP アプリを配置 | Vercel や Cloudflare、AWS などにビルド済みアセット＋関数を配置 |
以前はひとつの LAMP スタックとしてもう少しぐちゃっとした役割を、UI・API・インフラに分けたと整理しました。
レンダリングと認証
こちらはまだきちんと比較したわけではないのですが、触っている時に気づいたことと頭の整理です。（SPAのJWTトークンは安全なのかが気になりました）
レンダリングに仕組みの違いがあることは知っていたのですが、合わせてバックエンド側の認証などはセキュリティ的な観点から考慮する必要がありそうです。
-
SSR（Server-Side Rendering）
リクエストごとにサーバー側で HTML を生成する方式で、LAMP 時代の PHP や、Next.js のSSRもここに含められそうです。サーバー側セッション＋httpOnly Cookie で認証状態を持つ構成と相性が良く、昔ながらのセッション管理をそのまま引き継ぎやすい印象でした。
-
SPA（いわゆるクライアントサイドレンダリング）
最初に HTML と JS を返し、ブラウザ側の JavaScript が動いてから UI を組み立てる方式です。Cognito のような IDaaS と組み合わせると、アクセストークンをブラウザのどこに置くか（メモリ／ストレージ／Cookie）が設計ポイントになり、XSS を前提にトークンをブラウザストレージに置きっぱなしにしないことが重要そうだと感じました。
-
SSG（Static Site Generation）＋API サーバー
ビルド時に HTML を静的に生成して CDN から配る方式ですが、裏側に API サーバーを用意しておけば、そこでサーバー側セッション＋httpOnly Cookie を使うこともできるようです。フロントは静的ホスティングのまま、認証だけは SSR に近い形で扱える構成になりそうです。
技術的なところだけを見ると、以下かなと思います。
- SSR であれば、サーバー側でセッションを持って httpOnly Cookie でブラウザとやり取りする
- SPA／SSG の場合でも、裏側に自前の API サーバを挟んで、そこでセッションと Cookie を扱う
このような構成にしておけば、少なくともブラウザストレージに長命なトークンをそのまま置くパターンよりは、一般的に問題になりにくそう、というのが現時点での理解です。
Cognito のようなサービスを使う場合も、トークンをブラウザから直接触る構成なのかいったん自分の API サーバで受けて、サーバー側だけで持つ構成なのかという見方で整理しておくと、自分としては考えやすいと感じました。
まとめ
React と TypeScript を少し触ってみて、「React が何者なのか分からない」という状態はひとまず抜けられたかな、という感覚です。
まだ基礎をなぞっただけですが、今後フロントに関わる可能性も増えていくのかなと思うので、その都度もう少し深掘りしながら手を動かしていきたいと思っています。
生成 AI が出すコードを読んだり、クラウド側とアプリ側の関係を考えたりするうえでも、今回ざっと整理した内容はすぐに使えそうかなと思いました。
まずはこのあたりを足がかりにしつつ、少しずつキャッチアップを続けていくつもりです。