>_ DevTrendsja

言語

ホーム

言語

セクション

フロントエンド バックエンド モバイル DevOps AI / ML ゲーム開発 ブロックチェーン 組み込み セキュリティ
JavaScript

Web開発の伝説Create React Appの歴史とその終焉

2016年を覚えていますか?当時、シンプルなReactプロジェクトを素早く立ち上げるのは、説明書のつかないキャビネットを組み立てるようなものでした。Webpackを手動で設定し、Babelを設定し、CSSローダーの設定を書き、ローカル開発サーバーをセットアップする必要がありました。実際のアプリケーションコードを一行も書かないうちに、環境構築に丸一日かかってしまいました。

それからFacebookがCreate React App (CRA)をリリースしました。1つのコマンドで、準備完了のプロジェクトが生成されました。プロンプトもダイアログボックスも、何千行もの設定も必要ありませんでした。

今日、このツールは正式に非推奨となり、長期的なリタイアメントを迎えました。Reactドキュメントは直接、ViteやNext.jsなどの代替ツールへの切り替えを推奨しています。CRAがフロントエンド業界をどのように変えたのか、内部でどのように動作していたのか、そしてなぜその時代が終わったのかを探っていきましょう。

Create React App logo

Create React Appができたこと

このツールのアイデアは「ゼロコンフィギュレーション」という概念に合致していました。開発者はビルドツールの設定を深く理解する必要なく、動作するスタックを手に入れました。

すべてのインフラストラクチャは1つのパッケージ(react-scripts)に隠されていました。Webpack、Babel、ESLint、PostCSSを含むブラックボックスでした。

クイックスタートは次のようになりました:

npx create-react-app my-app
cd my-app
npm start

約30秒後、ブラウザでページが開きました。

CRA launch demo

ディレクトリ構造は非常にクリーンになりました。ルートにwebpack.configやbabel.configなどのファイルがありません:

my-app
├── README.md
├── node_modules
├── package.json
├── public
   ├── favicon.ico
   ├── index.html
   └── manifest.json
└── src
    ├── App.css
    ├── App.js
    ├── App.test.js
    ├── index.css
    └── index.js

内部での動作仕組み

CRAは3つの原則に基づいて構築されていました:単一のビルド依存関係、ゼロの初期設定、エスケープハッチコマンド。

単一依存関係

以前は、ツールの更新は悪夢でした。Webpackを更新するとBabelが壊れました。Babelを更新するとESLintプラグインが動作しなくなりました。

CRAでは、react-scriptsがすべてを担当していました。この単一のライブラリを更新すると、背後にあるビルドチェーン全体が更新されました。これには以下が含まれていました:

  • 箱から出してすぐにJSX、ES6+、TypeScriptサポート
  • AutoprefixerによるCSSの自動ベンダープレフィックス挿入
  • Jestとファイル監視によるインタラクティブなテスト実行
  • ブラウザに直接ビルドエラーオーバーレイ

構文にタイプミスがあると、CRAは正確な行と文字を指す明確な画面を表示しました:

Error overlay in CRA

Ejectメカニズム

デフォルト設定が不十分な場合はどうでしょうか?たとえば、特定のファイルタイプを処理するための珍しいプラグインが必要な場合。

そのような場合のために、作成者はnpm run ejectコマンドを追加しました。これは文字通りプロジェクトを裏返しました:react-scriptsを削除し、何百行ものWebpackとBabelの設定をプロジェクトに直接コピーしました。

これは片道切符でした。クリーンな構造に戻す方法はなく、広がった設定の混乱を自分で維持する必要がありました。

なぜCreate React Appは時代遅れになったのか

時間がCRAに不利に働きました。テクノロジーは前進し、ツールのアーキテクチャ上の決定が弱点になりました。

第一に、速度です。Webpackは開発サーバーを起動すると、プロジェクト全体をゼロから再ビルドして分析します。プロジェクトが数百のコンポーネントに成長すると、起動とホットリロードに数十秒かかります。その後継であるViteは、ネイティブブラウザESモジュールを使用し、超高速なGoコンパイラであるesbuildでオンデマンドでコードをビルドします。

第二に、SSRとサーバーコンポーネントへの移行です。CRAはクライアント中心のシングルページアプリケーション(SPA)しかビルドできませんでした—ユーザーのブラウザでスクリプトで満たされる空のHTMLファイルです。良いSEOと高速な最初の描画にはサーバーサイドレンダリングが必要でしたが、CRAはそれを単に提供できませんでした。

第三に、肥大化したサイズです。新規作成したプロジェクトのnode_modulesフォルダは数百メガバイトあり、高速な接続でも依存関係のインストールに数分かかりました。

CRAの代わりに何を使うか

公式Reactガイドは明確な方向性を示しています:

  • Vite — サーバーサイドレンダリングなしの高速SPA、パーソナルプロジェクト、個人的なブログが必要な場合。ミリ秒単位で起動し、著しく高速に動作します。
  • Next.jsまたはRemix — SSR、ルーティング、画像最適化、サーバーコンポーネントを備えた本格的な本番アプリを作成している場合。
  • Expo — React Nativeでクロスプラットフォームのモバイルアプリを作成する予定がある場合。

伝説の記憶

Create React Appは最も重要なことを行いました:Developer Experienceの基準を高く設定しました。ウェブアプリケーションの構築がシンプルで、就業初日にWebpackの深い知識がなくてもできることを、業界全体に示しました。

今日、新しい本格的なプロジェクトをCRAで始めることには実用的な価値はありません。しかし、3年前のチュートリアルに遭遇した場合や、サンドボックスを素早く立ち上げる必要がある場合は— CRAはまだ動作します。

関連プロジェクト