画面・フロントエンド
利用者が見て、触る画面をつくる。ブラウザの中で動く部分
利用者にいちばん近い層。ここから裏側（サーバー）に頼み事をして、返ってきたデータを見せる。
最初に触るなら
Astro ：既定でJavaScriptを出さない静的サイト生成器。必要な部分だけ島として動かす
HTML と Markdown から始められ、JavaScript を書かなくてもサイトを公開できる。動く画面が必要になった時点で React を足せばよい。
隣の分野とのつながり
| 分野 | どうつながるか |
|---|---|
| サーバー・API | 画面は自分ではデータを持たない。API を呼んでデータを受け取り、表示する |
| 実行基盤・ホスティング | 作った画面は HTML・CSS・JavaScript のファイルになる。それを配信場所に置いて初めて他人が見られる |
| 認証・セキュリティ | ログイン画面はここにあるが、「本人かどうか」の判断はサーバー側が行う。画面は判断しない |
| 言語・実行環境 （から見ると） | 画面は JavaScript（TypeScript）で書く。ブラウザが動かせる言語はこれだけなので、画面を作るなら避けて通れない |
| サーバー・API （から見ると） | 画面に対して API（決まった形の窓口）を用意し、頼まれたデータを返す |
| 認証・セキュリティ （から見ると） | ログイン画面は画面側にあるが、判断はしない。トークンを預かって渡すだけ |
| ノーコード・SaaS （から見ると） | Notion の公開ページのように、画面を作らずに情報を公開できる |
この分野を理解する
画面は3つの材料でできている。 構造を書く HTML、見た目を決める CSS、動きをつける JavaScript。ブラウザはこの3つを受け取って画面を描く。フロントエンドの道具はすべて、この3つを効率よく作るためにある。
フレームワークと静的サイト生成器。 React は「JavaScript で画面の部品を組み立てる」ための道具で、ボタンを押したら表が更新されるような動きのある画面に向く。Astro のような静的サイト生成器は、公開前に HTML を作っておく道具で、ブログや資料サイトのように読むことが中心の画面に向く。Next.js は両方の性格を持つ。
「いつ HTML を作るか」が分岐点。 公開前に作っておく（静的生成）、リクエストのたびにサーバーで作る（サーバー描画）、ブラウザで作る（クライアント描画）の3通りがある。読み物なら静的生成、ログインして操作する画面ならサーバー描画かクライアント描画、と覚えておけば最初は足りる。
隣の分野との境界。 画面は「見せる」だけで、「決める」「保存する」はサーバーの仕事である。画面に書いたコードは利用者のブラウザに丸ごと届くので、秘密の鍵や判断のロジックを画面側に置いてはいけない。
最初の一歩。 Markdown で数ページ書き、静的サイト生成器で HTML にして、GitHub Pages で公開する。「作る」から「他人が見られる」までを一度通すと、フロントエンドとホスティングの関係が体で分かる。
この分野のツール（4件）
種別（自分で書く土台か、借りて使うサービスか）で分けている。「主要制約」は各ツールで最も先に当たる限界。
フレームワーク（4件）自分で書くコードの土台になるライブラリ。動かす場所は自分で用意する
| ツール | 学習 | 料金 | 成熟 | 主要制約 | 検証 |
|---|---|---|---|---|---|
| Astro 既定でJavaScriptを出さない静的サイト生成器。必要な部分だけ島として動かす | 低 | 無料 | 安定 | 島（Island）の間の状態共有：部分ハイドレーションされた島の間では React Context 等のコンテキストラッパーが使えない。共有には Nano Stores（1 KB 未満、依存なし）のような外部ストアが推奨される | |
| React コンポーネントと状態でUIを組む、ブラウザ画面向けのJavaScriptライブラリ | 中 | 無料 | 安定 | フック呼び出しの制約（Rules of Hooks）：フックは関数コンポーネントかカスタムフックの最上位でのみ呼べる。条件分岐・ループ・早期 return の後・イベントハンドラ・try/catch・useMemo や useEffect に渡す関数の中・クラスコンポーネントでは呼べない | |
| SvelteKit Svelteでルーティング・サーバー処理・静的出力までを完結させるフレームワーク | 中 | 無料 | 安定 | デプロイ先ごとのアダプタ選定：ビルド出力をデプロイ環境向けに変換する「アダプタ」の指定がsvelte.config.jsで必須。公式にNode・Cloudflare・Netlify・Vercel・静的サイト(adapter-static)向けがある | |
| Next.js Reactにルーティング・サーバー描画・APIを足した、Web アプリのフレームワーク | 高 | 無料 | 安定 | 静的エクスポートで使えない機能：output を export にすると Cookie、Rewrites・Redirects・Headers、Proxy、ISR、既定ローダーの画像最適化、Draft Mode、Server Actions、Intercepting Routes、generateStaticParams のない動的ルートが使えない。Route Handler は GET のみ、force-static の明示が必要 |
どれを選ぶか
| ツール | 種別 | どういう時に選ぶか／避けるか |
|---|---|---|
| Astro | フレームワーク | ブログ・ドキュメント・製品紹介など文書中心のサイトでは第一候補で、静的ホスティングにそのまま置ける。画面全体がアプリ的に動く（ログイン後のダッシュボード、常に状態を共有する UI）場合は島の分離が足かせになるため Next.js か React へ |
| React | フレームワーク | 操作の多いブラウザ画面（管理画面、ダッシュボード、フォーム主体のアプリ）では第一候補で、周辺ライブラリと情報の厚さが最大の利点。ルーティングやサーバー描画まで必要なら React 単体ではなく Next.js 等のフレームワークから始め、文書中心の静的サイトは Astro へ |
| SvelteKit | フレームワーク | ルーティング・データ取得・フォーム処理・静的出力までを1つのフレームワークで完結させたいプロジェクトでは第一候補。React の資産に乗る必要がある場合は Next.js、文書中心で操作の少ないサイトは Astro を検討する |
| Next.js | フレームワーク | React でサーバー描画・ルーティング・API を一体で持つ Web アプリでは第一候補。静的ホスティングだけに置きたい場合は静的エクスポートの制限に当たるため Astro か React 単体へ。Node.js サーバーを持てない、または年1回のメジャー追従ができない場合は避ける |
この分野が担う目的
目的ごとのページでは、他の分野のツールも含めて横断比較できる。
- ブラウザ向けの画面を作る （この分野から 4件）
- 静的サイトを生成する （この分野から 3件）
- HTTP API を公開する （この分野から 2件）