Remix は『Web 標準』に忠実なフルスタックフレームワーク
Remix は HTML フォーム・Fetch API 等の Web 標準を活かす設計で、2024年に React Router と統合されました。本記事では編集部の視点で、実務での使い方を公開情報をもとに整理します。Next.js App Router もご参考に。
Remix の特徴
(1) loader/action：データ取得+書込みの宣言的記述。(2) Form 重視：JS なしでも動く。(3) ネストレイアウト：ルート単位。(4) エラー境界：宣言的なエラーハンドリング。(5) Progressive Enhancement：JS 無効でも基本動作。
React Router 7 統合
(1) Remix が React Router 7 にマージ(公開情報をもとに)。(2) Library mode：従来の React Router 利用。(3) Framework mode：Remix 相当のフルスタック。(4) 移行パスが明確に。(5) 長期的に統合進む見込み。
loader / action の使い方
(1) loader：データ取得(サーバー側)。(2) action：書込み処理(サーバー側)。(3) useLoaderData：取得データ利用。(4) useFetcher：UI 状態+書込み統合。(5) 型安全：TypeScript で。
Form と Progressive Enhancement
(1) Remix Form：通常のHTML Formと同様。(2) method=POSTで action 呼出。(3) JS 無効でも動く。(4) useNavigation：状態遷移把握。(5) validation：Zod 等と統合。Zod-Valibot 実践 もご参考に。
Next.js App Router との比較
(1) 哲学：Remix が Web 標準寄り、Next.js は機能豊富。(2) RSC：Next.js が先行。(3) 採用市場：Next.js > Remix。(4) 学習コスト：Remix の方がシンプル。(5) パフォーマンス：両者とも高水準。プロジェクト要件で使い分けます。
デプロイの選択肢
(1) Vercel：React Router 7 対応。(2) Netlify：Adapter 提供。(3) Cloudflare Pages/Workers：Edge SSR。(4) Node.js セルフホスト。(5) AWS Lambda：Serverless Adapter。CDN/Edge 実践 もご参考に。
失敗しがちなパターン
(1) loader 大量データ取得：シリアライズ重い。(2) Form 利用しない設計：Remix の利点喪失。(3) クライアント側state 多用：Server Round-trip 多発。(4) SSR error 放置：ユーザー体験低下。(5) React Router 古い API 混在：v6/v7 で混乱。対策は、(1)必要データのみ、(2)Form 駆使、(3)Server source of truth、(4)error.tsx、(5)v7 統一、です。