Remix v3とReactのトレードオフを徹底考察：AI時代に再評価される「Web標準」への回帰

Webアプリケーションの開発を続けていると、「いつの間にかフレームワークの学習ばかりしている」と感じたことはないでしょうか。

たとえばReactであれば、useEffectの依存配列を正しく書くために時間を費やし、状態管理ライブラリの選定で悩み、サーバーサイドレンダリングの設定ファイルと格闘する。本来はユーザーに価値を届けるためのアプリケーション開発に集中したいはずなのに、フレームワーク固有の知識やベストプラクティスの習得に多くの時間を取られてしまいます。

この課題は、フレームワークが「厚く」なることで生まれます。多機能で便利な反面、学習コストが高く、Web標準から遠ざかった独自の概念が増えていく。その結果、フレームワークの外で培った知識が活かしにくくなり、フレームワークのバージョンアップのたびに学び直しを強いられることになります。

さらに、AIツールが普及した現代では、この問題はより深刻です。ChatGPTやGitHub Copilotといったツールは、シンプルで標準的なコードほど正確に理解し、適切な提案をしてくれます。しかし、フレームワーク固有の複雑な概念や、暗黙の前提が多いコードでは、AIの支援が十分に機能しないことがあります。

• keyboard_arrow_down 学習コストを下げ、AIコーディングを効率化する「薄いフレームワーク」という選択
• keyboard_arrow_down Web標準APIを活かすための3つの要素
• keyboard_arrow_down React開発の豊かなエコシステムを手放すべきか
• keyboard_arrow_down まとめと次回予告

こうした課題に対して、2025年5月28日のブログ記事“Wake up, Remix!”で予告されたRemix v3は、まったく異なるアプローチを提示しました。それが「薄いフレームワーク」という選択です。Remix v3は、かつてReact Routerに吸収されて姿を消したRemixというブランドを復活させ、Web標準へ回帰する新しいフレームワークとして生まれ変わりました。

Remix v3の設計は、いくつかの原則に基づいています。その中核となるのが「Web標準の上に構築する（Build on Web APIs）」という原則です。バンドラーやコンパイラへの依存を避け、依存関係を最小化し、単一目的で置き換え可能な抽象化を提供する。これらの原則により、独自の概念を増やすのではなく、Web標準のAPIを最大限活用することで、学習コストを下げ、長期的な保守性を高める設計が実現されています。この設計思想は、フレームワークの肥大化に悩む開発者にとって、一つの解答となるかもしれません。

本稿では、Remix v3の特徴を理解するために、ランタイム非依存、React非依存、手動リアクティビティという3つの側面に着目します。これらを通じて、なぜ今「薄いフレームワーク」が必要なのか、従来のReact開発とどう異なるのかを解説します。

Remix v3が目指す「薄いフレームワーク」とは、単に機能が少ないという意味ではありません。むしろ、フレームワーク自身が提供する独自APIを最小限に抑え、Web標準のAPIを積極的に活用することで、開発者が既に持っている知識を最大限活かせる設計を指します。

これは、Remix v1から一貫して受け継がれてきた哲学でもあります。Remix v1は「Web標準を活かす」というメッセージを掲げ、formタグやHTTP標準を尊重した設計で注目を集めました。しかしv1/v2は、Reactへの深い依存など、特定の技術スタックへの結びつきが強い面もありました。

Remix v3は、この哲学をさらに推し進めます。Reactへの依存を取り除き、ランタイムをWeb標準ベースに再設計することで、より「薄く」、より「移植性の高い」フレームワークへと進化しました。フレームワークのコアはWeb標準APIのみに依存し、Node.js、Deno、Bun、Cloudflare Workersなど、あらゆるJavaScriptランタイムで動作します。

なぜ「薄い」ことが重要なのでしょうか。第一に、学習コストが大幅に下がります。Remix v3を学ぶことは、Web標準を学ぶことと同義です。新しいフレームワーク固有の概念を覚える必要はなく、既にHTMLやJavaScriptの知識があれば、すぐに理解できる設計になっています。

第二に、長期的な保守性が向上します。Web標準は、W3CやWHATWGといった標準化団体によって管理され、後方互換性が重視されます。フレームワーク固有のAPIは、バージョンアップで破壊的変更が起きるリスクがありますが、Web標準ベースの設計なら、そのリスクを大幅に減らせます。

第三に、AIツールとの相性が良くなります。AIは標準的で明示的なコードを得意とします。フレームワーク固有の暗黙のルールや、複雑な抽象化が少ないほど、AIの支援が効果的になります。

下図は、厚いフレームワークと薄いフレームワークの違いを表したものです。

厚いフレームワークでは、分厚い抽象化レイヤーがプラットフォームAPIを覆い隠してしまうため、開発者はフレームワーク固有のAPIの学習に追われ、プラットフォームAPIそのものを学ぶ機会を失ってしまいます。一方、薄いフレームワークは最小限のレイヤーのみを提供するため、開発者はプラットフォームAPIを直接学び、活用できます。この違いは、フレームワークを超えて通用する知識を身につけられるかどうかという点で、長期的なキャリア形成にも影響します。

この「薄さ」を実現するRemix v3の設計を理解するために、次のセクションでは3つの特徴的な側面に注目します。それぞれが何を意味し、どのような価値を提供するのかを詳しく見ていきましょう。

Remix v3の「薄いフレームワーク」という理念を理解するために、本稿では3つの特徴的な側面に注目します。これらの特徴は独立しながらも相互に補完し合い、Web標準へ回帰するという大きな目標に向かって統合されています。

1. ランタイム非依存：どこでも動くフレームワーク

Remix v3の最も重要な特徴の一つが、特定のJavaScriptランタイムに依存しない設計です。従来の多くのフレームワークは、Node.jsを前提として設計されていましたが、Remix v3はWeb標準APIのみに依存することで、Node.js、Deno、Bun、Cloudflare Workersなど、あらゆる環境で動作します。

この設計を実現する鍵が、アダプターパターンの活用です。フレームワークのコアはWeb標準のRequestとResponseオブジェクトのみを扱い、各ランタイム固有の処理はアダプターが担当します。例えば、server.tsでは以下のようにHTTPサーバーを起動します。

// server.ts - Node.jsの場合
import * as http from 'node:http'
import { createRequestListener } from '@remix-run/node-fetch-server'
import { router } from './app/router.tsx'

let server = http.createServer(
  createRequestListener(async (request) => {
    try {
      return await router.fetch(request)
    } catch (error) {
      console.error(error)
      return new Response('Internal Server Error', { status: 500 })
    }
  }),
)

let port = process.env.PORT ? parseInt(process.env.PORT, 10) : 3000
server.listen(port, () => {
  console.log(`Server is running on http://localhost:${port}`)
})

このコードで注目すべきは、router.fetch(request)がWeb標準のRequestオブジェクトを受け取り、Web標準のResponseオブジェクトを返している点です。Node.jsに依存するAPIはhttp.createServerとcreateRequestListenerのみで、ビジネスロジックを含むルーター部分は完全にWeb標準のみで記述されています。つまり、このルーター部分は他のランタイムでもそのまま動作するのです。

この設計により、開発者はランタイムの移行を容易に行えます。プロジェクトの初期はNode.jsで開発し、後にパフォーマンスやコストの観点からBunやCloudflare Workersに移行する、といったことが、コアロジックを変更せずに実現できます。

ランタイム非依存の思想は、単なる移植性の向上だけでなく、フレームワーク自体の寿命を延ばす効果もあります。特定のランタイムに依存していると、そのランタイムが衰退したときにフレームワークも影響を受けますが、Web標準ベースなら、JavaScriptが動く限り使い続けられます。

2. React非依存：JSXをシンプルに

Remix v1はReactに深く依存していましたが、v3では独自のJSXランタイム@remix-run/domを導入し、React非依存を実現しました。これは単にReactを置き換えたというより、「本当に必要な機能だけを残した」という選択です。

React非依存によって、開発者はuseStateやuseEffectといったフック機構から解放されます。フックは強力ですが、学習コストが高く、誤った使い方をするとバグの温床になります。Remix v3では、クロージャーを活用したシンプルな状態管理に置き換えられています。

コンポーネントの型も変わります。ReactのReact.FCやJSX.Elementではなく、Remix.RemixNodeという型が使われます。この型は、Remix v3のJSXランタイムが返す仮想DOMノードを表します。実際の使い方としては、次のような形になります。

// Layout.tsx
import type { Remix } from '@remix-run/dom'

export function Layout({ children }: { children?: Remix.RemixNode }): Remix.RemixNode {
  return (
    <html lang="ja">
      <head>
        <meta charSet="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Hello Remix v3</title>
      </head>
      <body>
        {children}
      </body>
    </html>
  )
}

JSXの仕様には従っているので、Reactで見慣れた形にかなり近いものになっていますね。

React非依存の利点は、バンドルサイズの削減だけではありません。より重要なのは、「Reactのエコシステムに縛られない」という自由度です。Reactのバージョンアップによる破壊的変更や、サードパーティライブラリの互換性問題から解放され、フレームワーク自身が進化のペースをコントロールできるようになります。

3. 手動リアクティビティ：明示的な制御

Remix v3の最も特徴的な設計が、手動リアクティビティです。ReactやVueといった現代のフレームワークは、状態が変わると自動的に画面が再描画される「自動リアクティビティ」を採用していますが、Remix v3ではコンポーネント自身がthis.update()を呼び出すことで、明示的に再描画をトリガーします。

この設計には、いくつかの重要な利点があります。第一に、パフォーマンスの予測可能性が向上します。自動リアクティビティでは、「いつ、どのコンポーネントが再描画されるか」がフレームワークの内部実装に依存しますが、手動リアクティビティでは開発者が完全にコントロールできます。

第二に、デバッグがしやすくなります。画面が期待通りに更新されない場合、this.update()の呼び出しを確認すればよく、フレームワークの複雑な依存関係解析を理解する必要がありません。

第三に、フック機構が不要になります。ReactのuseStateやuseEffectは、自動リアクティビティを実現するための仕組みですが、手動リアクティビティではクロージャーを使った素朴な状態管理で十分です。

以下は、シンプルなカウンターコンポーネントの例です。

import { type Remix, hydrated } from '@remix-run/dom'
import { press } from '@remix-run/events/press'

export const Counter = hydrated(
  routes.assets.href({ path: 'counter.js#Counter' }),
  function (this: Remix.Handle) {
    let count = 0  // クロージャー内の変数

    return () => (
      <div>
        <p>{count}</p>
        <button
          on={press(() => {
            count--  // 状態を更新
            this.update()  // 明示的に再描画
          })}
        >
          −
        </button>
        <button
          on={press(() => {
            count++
            this.update()
          })}
        >
          +
        </button>
      </div>
    )
  },
)

このコードの核心は、let count = 0という普通の変数と、this.update()という明示的な呼び出しです。ReactであればuseStateを使い、状態の更新が自動的に再描画をトリガーしますが、Remix v3ではクロージャー内の変数を直接更新し、this.update()を呼び出すまで画面は更新されません。また、press()という合成イベントを使っていることにも注目してください。これはマウスやキーボードの複数のイベントを抽象化し、より意味的な操作として扱えるようにするRemix v3の機能です。この明示性こそが、手動リアクティビティの最大の特徴なのです。

手動リアクティビティは、一見すると不便に思えるかもしれません。しかし、明示的であることの価値は、プロジェクトが大きくなるにつれて輝きを増します。「いつ更新されるか分からない」という曖昧さがなくなり、コードの動作を正確に理解できるようになるからです。

Remix v3の3つの特徴を見てきましたが、これらは従来のReact開発とどのように異なるのでしょうか。そして、どのような場面でRemix v3を選ぶべきなのでしょうか。

最も大きな違いは、「フレームワークの学習」と「Web標準の学習」のバランスです。Reactを使った開発では、コンポーネントライフサイクル、フックのルール、状態管理のパターンなど、React固有の知識が求められます。一方、Remix v3では、これらの知識の多くが不要になり、代わりにHTMLフォーム、Web標準のイベント、クロージャーといった、より普遍的な知識が活きてきます。

この違いは、学習のハードルにも影響します。Reactを初めて学ぶ開発者にとって、「なぜuseEffectの依存配列が必要なのか」「なぜ状態の更新は非同期なのか」といった疑問は、理解の壁になります。しかしRemix v3なら、「ボタンをクリックしたら変数を更新して、画面を再描画する」という直感的な理解で十分です。

Remix v3が最適解となりうるのは、次のようなケースです。

• ・Web標準を重視し、長期的な保守性を優先するプロジェクト
• ・複雑な状態管理が不要で、シンプルなUIを持つアプリケーション
• ・AIツールを積極的に活用し、コード生成やリファクタリングの支援を受けたいチーム
• ・ランタイムの移行可能性を保ちたいプロジェクト

逆に、Reactの豊富なエコシステムを活用したい場合や、既存のReactコンポーネントライブラリを使いたい場合は、従来のReact開発の方が適しています。Remix v3は「Reactの代替」ではなく、「異なる価値観を持つ選択肢」として位置づけるべきでしょう。

重要なのは、技術選定においてトレードオフを理解することです。Remix v3は、フレームワークの薄さと学習コストの低さを重視する代わりに、Reactエコシステムの広さを手放しています。この選択が正しいかどうかは、プロジェクトの性質や、チームが何を優先するかによって変わります。

本稿では、Remix v3が目指す「薄いフレームワーク」という理念と、それを体現する3つの特徴──ランタイム非依存、React非依存、手動リアクティビティ──に注目して解説しました。

Remix v3は、フレームワークの肥大化やWeb標準からの乖離といった現代Web開発の課題に対して、一つの明確な答えを提示しています。独自のAPIを増やすのではなく、Web標準を最大限活用することで、学習コストを下げ、長期的な保守性を高める。この思想は、AIツールが普及した現代において、ますます重要性を増していくでしょう。

次回は、実際に手を動かしながらRemix v3の特徴を体験します。手動リアクティビティによる状態管理、型安全なルーティング、そしてフォーム送信の仕組みを、実装を通じて理解していきましょう。配布サンプルコードを用意していますので、ぜひご自身の環境で試してみてください。