■ 1. 記事の問題提起
- Webアプリケーションの開発を続けていると「いつの間にかフレームワークの学習ばかりしている」と感じたことはないか
- ReactであればuseEffectの依存配列を正しく書くために時間を費やし状態管理ライブラリの選定で悩みサーバーサイドレンダリングの設定ファイルと格闘する
- 本来はユーザーに価値を届けるためのアプリケーション開発に集中したいはずなのにフレームワーク固有の知識やベストプラクティスの習得に多くの時間を取られてしまう
- この課題はフレームワークが「厚く」なることで生まれる
- 多機能で便利な反面学習コストが高くWeb標準から遠ざかった独自の概念が増えていく
- その結果フレームワークの外で培った知識が活かしにくくなりフレームワークのバージョンアップのたびに学び直しを強いられることになる
■ 2. AI時代における課題の深刻化
- AIツールが普及した現代ではこの問題はより深刻である
- ChatGPTやGitHub Copilotといったツールはシンプルで標準的なコードほど正確に理解し適切な提案をしてくれる
- しかしフレームワーク固有の複雑な概念や暗黙の前提が多いコードではAIの支援が十分に機能しないことがある
■ 3. Remix v3による解決策
- こうした課題に対して2025年5月28日のブログ記事「Wake up, Remix!」で予告されたRemix v3はまったく異なるアプローチを提示した
- それが「薄いフレームワーク」という選択である
- Remix v3はかつてReact Routerに吸収されて姿を消したRemixというブランドを復活させWeb標準へ回帰する新しいフレームワークとして生まれ変わった
■ 4. Remix v3の設計原則
- Remix v3の設計はいくつかの原則に基づいている
- その中核となるのが「Web標準の上に構築する(Build on Web APIs)」という原則である
- バンドラーやコンパイラへの依存を避け依存関係を最小化し単一目的で置き換え可能な抽象化を提供する
- これらの原則により独自の概念を増やすのではなくWeb標準のAPIを最大限活用することで学習コストを下げ長期的な保守性を高める設計が実現されている
- 本稿ではRemix v3の特徴を理解するためにランタイム非依存・React非依存・手動リアクティビティという3つの側面に着目する
■ 5. 薄いフレームワークの意味
- Remix v3が目指す「薄いフレームワーク」とは単に機能が少ないという意味ではない
- むしろフレームワーク自身が提供する独自APIを最小限に抑えWeb標準のAPIを積極的に活用することで開発者が既に持っている知識を最大限活かせる設計を指す
- これはRemix v1から一貫して受け継がれてきた哲学でもある
- Remix v1は「Web標準を活かす」というメッセージを掲げformタグやHTTP標準を尊重した設計で注目を集めた
- しかしv1/v2はReactへの深い依存など特定の技術スタックへの結びつきが強い面もあった
- Remix v3はこの哲学をさらに推し進める
■ 6. 薄いことの重要性
- なぜ「薄い」ことが重要なのか
- 第一に学習コストが大幅に下がる
- Remix v3を学ぶことはWeb標準を学ぶことと同義である
- 新しいフレームワーク固有の概念を覚える必要はなく既にHTMLやJavaScriptの知識があればすぐに理解できる設計になっている
- 第二に長期的な保守性が向上する
- Web標準はW3CやWHATWGといった標準化団体によって管理され後方互換性が重視される
- フレームワーク固有のAPIはバージョンアップで破壊的変更が起きるリスクがあるがWeb標準ベースの設計ならそのリスクを大幅に減らせる
- 第三にAIツールとの相性が良くなる
- AIは標準的で明示的なコードを得意とする
- フレームワーク固有の暗黙のルールや複雑な抽象化が少ないほどAIの支援が効果的になる
■ 7. 特徴1:ランタイム非依存
- Remix v3の最も重要な特徴の一つが特定のJavaScriptランタイムに依存しない設計である
- 従来の多くのフレームワークはNode.jsを前提として設計されていたがRemix v3はWeb標準APIのみに依存することでNode.js・Deno・Bun・Cloudflare Workersなどあらゆる環境で動作する
- この設計を実現する鍵がアダプターパターンの活用である
- フレームワークのコアはWeb標準のRequestとResponseオブジェクトのみを扱い各ランタイム固有の処理はアダプターが担当する
- この設計により開発者はランタイムの移行を容易に行える
- プロジェクトの初期はNode.jsで開発し後にパフォーマンスやコストの観点からBunやCloudflare Workersに移行するといったことがコアロジックを変更せずに実現できる
■ 8. 特徴2:React非依存
- Remix v1はReactに深く依存していたがv3では独自のJSXランタイム@remix-run/domを導入しReact非依存を実現した
- これは単にReactを置き換えたというより「本当に必要な機能だけを残した」という選択である
- React非依存によって開発者はuseStateやuseEffectといったフック機構から解放される
- フックは強力だが学習コストが高く誤った使い方をするとバグの温床になる
- Remix v3ではクロージャーを活用したシンプルな状態管理に置き換えられている
- React非依存の利点はバンドルサイズの削減だけではない
- より重要なのは「Reactのエコシステムに縛られない」という自由度である
- Reactのバージョンアップによる破壊的変更やサードパーティライブラリの互換性問題から解放されフレームワーク自身が進化のペースをコントロールできるようになる
■ 9. 特徴3:手動リアクティビティ
- Remix v3の最も特徴的な設計が手動リアクティビティである
- ReactやVueといった現代のフレームワークは状態が変わると自動的に画面が再描画される「自動リアクティビティ」を採用している
- Remix v3ではコンポーネント自身がthis.update()を呼び出すことで明示的に再描画をトリガーする
- この設計にはいくつかの重要な利点がある
- 第一にパフォーマンスの予測可能性が向上する
- 自動リアクティビティでは「いつどのコンポーネントが再描画されるか」がフレームワークの内部実装に依存するが手動リアクティビティでは開発者が完全にコントロールできる
- 第二にデバッグがしやすくなる
- 画面が期待通りに更新されない場合this.update()の呼び出しを確認すればよくフレームワークの複雑な依存関係解析を理解する必要がない
- 第三にフック機構が不要になる
- ReactのuseStateやuseEffectは自動リアクティビティを実現するための仕組みだが手動リアクティビティではクロージャーを使った素朴な状態管理で十分である
■ 10. React開発との比較
- 最も大きな違いは「フレームワークの学習」と「Web標準の学習」のバランスである
- Reactを使った開発ではコンポーネントライフサイクル・フックのルール・状態管理のパターンなどReact固有の知識が求められる
- 一方Remix v3ではこれらの知識の多くが不要になり代わりにHTMLフォーム・Web標準のイベント・クロージャーといったより普遍的な知識が活きてくる
- この違いは学習のハードルにも影響する
- Reactを初めて学ぶ開発者にとって「なぜuseEffectの依存配列が必要なのか」「なぜ状態の更新は非同期なのか」といった疑問は理解の壁になる
- しかしRemix v3なら「ボタンをクリックしたら変数を更新して画面を再描画する」という直感的な理解で十分である
■ 11. Remix v3が最適解となるケース
- Web標準を重視し長期的な保守性を優先するプロジェクト
- 複雑な状態管理が不要でシンプルなUIを持つアプリケーション
- AIツールを積極的に活用しコード生成やリファクタリングの支援を受けたいチーム
- ランタイムの移行可能性を保ちたいプロジェクト
- 逆にReactの豊富なエコシステムを活用したい場合や既存のReactコンポーネントライブラリを使いたい場合は従来のReact開発の方が適している
- Remix v3は「Reactの代替」ではなく「異なる価値観を持つ選択肢」として位置づけるべきである
- 重要なのは技術選定においてトレードオフを理解することである
- Remix v3はフレームワークの薄さと学習コストの低さを重視する代わりにReactエコシステムの広さを手放している
■ 12. まとめと次回予告
- Remix v3は独自のAPIを増やすのではなくWeb標準を最大限活用することで学習コストを下げ長期的な保守性を高める
- この思想はAIツールが普及した現代においてますます重要性を増していく
- 次回は実際に手を動かしながらRemix v3の特徴を体験する
- 手動リアクティビティによる状態管理・型安全なルーティング・そしてフォーム送信の仕組みを実装を通じて理解していく