デフォルトの座を降りたビルドツール — フロントエンド10ツールが場所を譲った理由

はじめに — これは墓碑銘ではなく技術選択の歴史です
1. Create React App
2. Bower
3. TSLint
4. Karma
5. Protractor
6. PhantomJS
7. LibSassとnode-sass
8. Moment.js
9. Rome
10. Grunt — まだ現役でデフォルトの座だけを降りた例
まとめ — 繰り返される三つの力
あわせて読みたい
シリーズ

はじめに — これは墓碑銘ではなく技術選択の歴史です

3年前の標準がいまは見慣れないものに感じられます。だからといってそれらのツールが粗悪だったわけではありません。多くは自分の時代の制約の中では正解であり、制約が変わったことで場所を譲りました。この記事はその交代がなぜ起きたのかを見ます。項目ごとに何を残したのかを必ず書きます。デフォルトの座を降りても、そのプロジェクトが証明したアイデアはたいてい次のツールの中に生きているからです。

根拠の基準は三つです。公式の廃止告知または後継プロジェクトの発表、メンテナーの公開声明、リポジトリのアーカイブ状態のように日付の付いた観測可能な事実。このうち一つ以上を原典で確認した項目だけを入れ、出典を示せないダウンロード傾向は引用しません。

1. Create React App

何だったのか — コマンド一つでReactアプリを始められる公式スキャフォールディングです。
なぜ当時は正しかったのか — 2016年のReactの開始コストはwebpackとBabelの設定でした。それを隠しただけで参入障壁が大きく下がりました。
何が変わったのか — Reactチームが2025年2月14日の公式ブログで廃止を発表しました。活発なメンテナーがいないこと、同じ問題をすでに解くフレームワークが多いことが理由です。
何がその場所に来たのか — 同じ記事がフレームワークとしてNext.js、React Router、Expoを、ビルドツールとしてVite、Parcel、Rsbuildを勧めています。
何を残したのか — 設定なしで始められるという期待値そのものです。いまのスキャフォールダはすべてこの基準に従っています。
いまでも使うのが正しい場合 — 同じ記事がメンテナンスモードで動き続け、React 19対応版を出したと述べています。既存アプリを急いで移す理由はありません。

2. Bower

何だったのか — フロントエンドアセット専用のパッケージマネージャーです。
なぜ当時は正しかったのか — npmがサーバーモジュール中心だった頃、ブラウザ資産にはネストしないフラットな依存ツリーが必要でした。
何が変わったのか — リポジトリのREADME自身が、新規プロジェクトにはyarnとwebpackまたはparcelを勧めると書いています。アーカイブはされておらず、メンテナンス中だと明記しています。
何がその場所に来たのか — npmとyarnがブラウザ資産まで扱い、モジュール解決はバンドラーが担うようになりました。
何を残したのか — フロントエンドの依存も宣言的に管理するという前提と、フラットツリーという解法です。
いまでも使うのが正しい場合 — すでにBowerで固定されたレガシーの維持だけです。新規導入する理由は公式READMEの基準でもありません。

3. TSLint

何だったのか — TypeScript専用のリンターです。
なぜ当時は正しかったのか — ESLintがTypeScript構文をきちんと解析できなかった頃、型を理解するリンターはこれだけでした。
何が変わったのか — リポジトリに廃止告知が付いており、2021年3月25日に読み取り専用でアーカイブされました。
何がその場所に来たのか — typescript-eslintです。パーサーを差し替えて型認識ルールを支える形で解決しました。
何を残したのか — 型情報を使うリントルールという概念と、ルールセット自体が後継プロジェクトへ移植されました。
いまでも使うのが正しい場合 — 事実上ありません。アーカイブされたリポジトリはセキュリティ修正も受け取りません。

4. Karma

何だったのか — 実際のブラウザを起動してテストを走らせるランナーです。
なぜ当時は正しかったのか — ブラウザごとに挙動が違い、本物のブラウザで動かす以外の検証手段がありませんでした。
何が変わったのか — リポジトリのREADMEが、新機能も一般的なバグ修正も受け付けないと明記しています。リポジトリ自体はアーカイブされていません。
何がその場所に来たのか — 同じ告知がJest、Web Test Runner、Vitest、jasmine-browser-runnerを挙げています。
何を残したのか — ユニットテストも実ブラウザで走らせられるべきだという基準です。
いまでも使うのが正しい場合 — 古いブラウザマトリクスを実際に検証する必要があるレガシーです。告知が示すセキュリティ修正期間は有限である点に注意が必要です。

5. Protractor

何だったのか — Angular向けのエンドツーエンドテストフレームワークです。
なぜ当時は正しかったのか — フレームワークがいつレンダリングを終えたかを知るランナーは、待機コードを大きく減らします。
何が変わったのか — Angularチームが2022年8月10日のブログでv16を最後のリリースにすると述べ、リポジトリは2024年7月29日にアーカイブされました。
何がその場所に来たのか — 同じ記事がCypress、Nightwatch、WebdriverIO、Playwrightを提示しています。
何を残したのか — フレームワークの状態を知る暗黙の待機という発想です。今日の自動待機機能の原型です。
いまでも使うのが正しい場合 — 同じ記事が、すぐに移行できないチーム向けの商用長期サポートフォークに言及しています。

6. PhantomJS

何だったのか — スクリプトで操作するヘッドレスブラウザです。
なぜ当時は正しかったのか — ブラウザベンダーがヘッドレスモードを提供していなかった頃、CIでレンダリングを検証する唯一の現実的手段でした。
何が変わったのか — リポジトリのREADMEが、開発は追って通知があるまで中断していると述べており、2023年5月30日にアーカイブされました。
何がその場所に来たのか — ChromeとFirefoxがヘッドレスを直接提供したことで、PuppeteerとPlaywrightが引き継ぎました。
何を残したのか — ヘッドレスブラウザというカテゴリそのものです。このツールが需要を証明すると、ベンダーが自ら実装しました。
いまでも使うのが正しい場合 — 事実上ありません。最新のWeb APIに対応していません。

7. LibSassとnode-sass

何だったのか — SassコンパイラのC++実装とそのNodeバインディングです。
なぜ当時は正しかったのか — 元のRuby実装は遅く、C++実装はビルド時間を桁で縮めました。
何が変わったのか — Sassチームが2020年10月26日の告知で、新規プロジェクトには勧めないと述べました。言語の進化に追随するエンジニアリング余力がないことが理由で、重大なバグとセキュリティ問題はベストエフォートで修正を続けると付け加えています。node-sassのリポジトリはアーカイブ状態です。
何がその場所に来たのか — Dart Sassであり、いまはRustベースの実装も競争に加わっています。
何を残したのか — Sass構文そのものと、別言語で再実装したコンパイラは本体の構文進化に追いつきにくいという高価な教訓です。
いまでも使うのが正しい場合 — ビルドが完全に固定されたレガシーです。新しい構文が使えない点だけ理解しておけば十分です。

8. Moment.js

何だったのか — JavaScriptの日付と時刻処理の事実上の標準でした。
なぜ当時は正しかったのか — ブラウザの日付APIはパースもフォーマットもタイムゾーン処理も貧弱で、Momentがその穴を埋めました。
何が変わったのか — 公式ドキュメントのプロジェクト状態の項が、自らをメンテナンスモードのレガシープロジェクトと規定しています。表現をそのまま引くと "It is not dead, but it is indeed done." です。
何がその場所に来たのか — 同じ文書がLuxon、Day.js、date-fns、js-Joda、そしてネイティブのDateとIntlを勧めています。
何を残したのか — 日付ライブラリAPIの慣用表現と、可変オブジェクトやツリーシェイキング非対応の設計が長期的に何をコストとして返すかという事例です。
いまでも使うのが正しい場合 — すでにMomentで書かれたコードベースです。ドキュメント自身が死んでいないと述べています。

9. Rome

何だったのか — フォーマッター、リンター、バンドラーを一つにまとめようとした統合ツールチェーンです。
なぜ当時は正しかったのか — ツール五つの設定を揃えるコストは実在し、まとめれば消えるという仮説は合理的でした。
何が変わったのか — リポジトリは2023年8月31日にアーカイブされ、READMEがBiomeをコミュニティの後継として案内しています。Biomeの発表は、同じメンテナーたちが引き続き率いるが、パッケージや組織資産へのアクセスの問題で新しい名前が必要だったと説明しています。
何がその場所に来たのか — Biomeです。同じ人たちが同じ目標を継いでいます。
何を残したのか — 統合ツールチェーンという目標とコードベース全体です。場所を譲った事例というより、名前を変えて続いた事例です。
いまでも使うのが正しい場合 — ありません。後継プロジェクトが明示的に指定されています。

10. Grunt — まだ現役でデフォルトの座だけを降りた例

何だったのか — 設定ベースのタスクランナーです。
なぜ当時は正しかったのか — npmスクリプトが貧弱だった頃、ビルド工程を宣言的に組み立てる方法が必要でした。
何が変わったのか — 廃止されていません。リポジトリはアーカイブされておらず、READMEは最新バージョンにセキュリティとバグ修正を提供すると述べています。変わったのは新規プロジェクトのデフォルト選択肢という地位です。
何がその場所に来たのか — npmスクリプトと、バンドラーに内蔵されたパイプラインです。
何を残したのか — ビルド工程をデータとして宣言するという発想です。今日のほぼすべてのビルド設定ファイルがこの形です。
いまでも使うのが正しい場合 — うまく動いているパイプラインがあるならそのままで構いません。メンテナンスされているツールを置き換えること自体がコストです。

まとめ — 繰り返される三つの力

第一に、プラットフォームが機能を吸収します。PhantomJSはブラウザがヘッドレスモードを内蔵したことで場所を譲りました。ツールが証明した需要をプラットフォームが取り込むのは失敗ではなく、成功の一形態です。

第二に、メンテナンスの余力が言語の進化速度に追いつきません。LibSassの告知がこの点を最も正直に書きました。ボトルネックは機能需要ではなく人でした。

第三に、問題の定義が動きます。TSLintはよくできたリンターでしたが、パーサーを差し替えられるように設計したESLint側のほうが長く残りました。

この三つの力はいずれもプロジェクトの品質とはほとんど関係がありません。いま使っているツールが5年後もデフォルトかを問うのは、ツールを疑う問いではなく環境を読む問いです。

状態情報は2026-08-12に直接確認しました。プロジェクトは再び活発になることもあるので、最新の状態はご自身で確認してください。