Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Introduction — this is a history of technical choices, not an epitaph
1. Create React App
2. Bower
3. TSLint
4. Karma
5. Protractor
6. PhantomJS
7. LibSass and node-sass
8. Moment.js
9. Rome
10. Grunt — still active, only stepped down from default
Conclusion — three recurring forces
Related reading
Series

Introduction — this is a history of technical choices, not an epitaph

A standard from three years ago feels unfamiliar now. That does not mean those tools were built badly. Most of them were the right answer within the constraints of their moment, and they gave up their place when the constraints changed. This post looks at why those replacements happened. Every entry carries a what it left behind field, because even after a project steps down from being the default, the idea it proved usually lives on inside the next tool.

There are three evidence standards. An official deprecation notice or successor announcement, a public statement from a maintainer, or a dated observable fact such as repository archive status. Only entries where at least one of these was confirmed at the source made the list, and usage trends I cannot cite a source for are not quoted.

1. Create React App

What it was — the official scaffolding tool that let you start a React app with a single command.
Why it was right at the time — in 2016 the cost of starting with React was webpack and Babel configuration. Hiding that alone lowered the barrier dramatically.
What changed — the React team announced the deprecation on 14 February 2025. The reasons given are that it has no active maintainers and that many frameworks already solve the same problems.
What took its place — the same post recommends Next.js, React Router and Expo as frameworks, and Vite, Parcel and Rsbuild as build tools.
What it left behind — the expectation that you start without configuration. Every scaffolder today follows that standard.
When it is still right — the same post states it keeps working in maintenance mode and that a version compatible with React 19 was published. There is no need to move an existing app in a hurry.

2. Bower

What it was — a package manager dedicated to frontend assets.
Why it was right at the time — when npm was centred on server modules, browser assets needed a flat, non-nested dependency tree.
What changed — the repository README itself recommends yarn plus webpack or parcel for new projects. The repository is not archived and states that it is maintained.
What took its place — npm and yarn now handle browser assets too, and bundlers took over module resolution.
What it left behind — the premise that frontend dependencies deserve declarative management, and the flat tree as the solution.
When it is still right — maintaining legacy that is already pinned to Bower. Even by its own README there is no reason to adopt it fresh.

3. TSLint

What it was — a linter dedicated to TypeScript.
Why it was right at the time — when ESLint could not parse TypeScript syntax properly, this was the only linter that understood types.
What changed — the repository carries a deprecation notice and was archived read-only on 25 March 2021.
What took its place — typescript-eslint, which solved the problem by swapping out the ESLint parser to support type-aware rules.
What it left behind — the concept of lint rules that use type information, along with the rule set itself, which was ported to the successor project.
When it is still right — effectively never. An archived repository does not receive security fixes either.

4. Karma

What it was — a test runner that launched real browsers to run tests.
Why it was right at the time — browsers behaved differently from one another, and there was no verification method other than actually running in a real browser.
What changed — the repository README states that it accepts neither new features nor general bug fixes. The repository itself is not archived.
What took its place — the same notice lists Jest, Web Test Runner, Vitest and jasmine-browser-runner.
What it left behind — the standard that even unit tests should be runnable in a real browser.
When it is still right — legacy code that genuinely has to be verified against an old browser matrix. Note that the security-fix window described in the notice is finite.

5. Protractor

What it was — an end-to-end test framework for Angular.
Why it was right at the time — a runner that knows when the framework has finished rendering cuts a great deal of waiting code.
What changed — the Angular team stated in a blog post on 10 August 2022 that v16 would carry the final release, and the repository was archived on 29 July 2024.
What took its place — the same post presents Cypress, Nightwatch, WebdriverIO and Playwright.
What it left behind — the idea of implicit waiting driven by framework state. It is the ancestor of today's auto-waiting features.
When it is still right — the same post mentions a commercial long-term-support fork for teams that cannot migrate immediately.

6. PhantomJS

What it was — a scriptable headless browser.
Why it was right at the time — when browser vendors offered no headless mode, it was the only realistic way to verify rendering in CI.
What changed — the repository README states that development is suspended until further notice, and the repository was archived on 30 May 2023.
What took its place — once Chrome and Firefox shipped headless modes directly, Puppeteer and Playwright took over.
What it left behind — the category of the headless browser itself. Once this tool proved the demand, the vendors implemented it natively.
When it is still right — effectively never. It does not support modern web APIs.

7. LibSass and node-sass

What it was — the C++ implementation of the Sass compiler and its Node bindings.
Why it was right at the time — the original Ruby implementation was slow, and the C++ implementation cut build times by an order of magnitude.
What changed — the Sass team stated in a notice dated 26 October 2020 that they no longer recommend it for new projects. The reason is that there is not enough engineering bandwidth to keep pace with the language, and they added that serious bugs and security issues will still be fixed on a best-effort basis. The node-sass repository is archived.
What took its place — Dart Sass, and today Rust-based implementations are in the running too.
What it left behind — Sass syntax itself, plus the expensive lesson that a compiler reimplemented in another language struggles to keep up with the syntax evolution of the original.
When it is still right — completely frozen legacy builds. You only need to be clear that new Sass syntax is unavailable.

8. Moment.js

What it was — the de facto standard for date and time handling in JavaScript.
Why it was right at the time — browser date APIs were weak at parsing, formatting and time zones alike, and Moment filled that gap.
What changed — the project status section of the official docs describes the project as legacy and in maintenance mode. In its own words: "It is not dead, but it is indeed done."
What took its place — the same document recommends Luxon, Day.js, date-fns, js-Joda, and the native Date and Intl objects.
What it left behind — the idioms of date library APIs, and a case study in what mutable objects and tree-shaking-hostile design cost you over time.
When it is still right — codebases already written around Moment. The docs themselves say it is not dead.

9. Rome

What it was — a unified toolchain that aimed to merge formatter, linter and bundler into one.
Why it was right at the time — the cost of aligning configuration across five tools was real, and the hypothesis that merging them removes that cost was reasonable.
What changed — the repository was archived on 31 August 2023 and its README points to Biome as the community successor. The Biome announcement explains that the same maintainers continue to lead it, but that a new name was needed because of access issues around the package and organisation assets.
What took its place — Biome. The same people continue toward the same goal.
What it left behind — the unified toolchain goal and the entire codebase. This is less a case of giving up a place than of continuing under a new name.
When it is still right — never. The successor project is explicitly designated.

10. Grunt — still active, only stepped down from default

What it was — a configuration-driven task runner.
Why it was right at the time — when npm scripts were thin, there had to be a way to assemble build steps declaratively.
What changed — it was not deprecated. The repository is not archived and the README states that the latest version receives security and bug fixes. What changed is its status as the default choice for new projects.
What took its place — npm scripts, and pipelines built into bundlers.
What it left behind — the idea of declaring build steps as data. Nearly every build configuration file today has that shape.
When it is still right — if you have a Grunt pipeline that works, you can leave it alone. Replacing a maintained tool is itself a cost.

Conclusion — three recurring forces

First, the platform absorbs the feature. PhantomJS gave up its place once browsers shipped headless mode natively. A platform taking over the demand a tool proved is not failure; it is one form of success.

Second, maintenance capacity cannot keep pace with language evolution. The LibSass notice put this most honestly. The bottleneck was people, not feature demand.

Third, the problem definition moves. TSLint was a well-built linter, but the ESLint side, designed so the parser could be swapped, lasted longer.

None of these three forces has much to do with project quality. Asking whether the tool you use today will still be the default in five years is not a question about the tool; it is a question about the environment.

Status information was verified directly on 2026-08-12. Projects sometimes become active again, so check the current state yourself.