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

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Prologue — "Why Build Tools Again?"

If you worked frontend in the late 2010s, you heard this joke: **"JavaScript build tools change every six months."** Grunt, Gulp, Browserify, webpack, Parcel, Rollup, Snowpack, esbuild, Vite, Turbopack… The joke was true.

What is happening in 2024–2026 is different in kind. It is not new tools so much as **the same tools rewritten in a new language**. Almost entirely **Rust** (esbuild is the Go exception, Bun is the Zig exception). webpack was a JS bundler. Babel was a JS transpiler. Prettier and ESLint were JS tools. The successors aiming at those seats in 2026 are **native compiled binaries, top to bottom**.

> This is a **generational shift**. Not just "a faster tool came along" — the language and architecture underneath the whole build chain are being swapped.

This piece maps that terrain. Which tool does what, who builds it, where it lives, what stage it is at in 2026, and what you should actually pick. Not a benchmark dump — a **structural map** of the chain itself.

1. Why the Rust Wave, Why Now

It was natural that JavaScript tools were written in JavaScript. The users were JS devs. The contributors were JS devs. The ecosystem was JS. webpack, Rollup, Babel, Prettier, ESLint — all JS.

The problem was **scale**. From the late 2010s, three things compounded at once.

1. **Apps got big.** A 50,000-module monorepo became normal. Five-minute builds. Thirty-second dev starts.

2. **CI/CD became continuous.** Every PR builds, tests, and lints. Single-threaded JS tools are the bottleneck.

3. **Tight feedback loops became existential.** HMR at 1 second vs HMR at 100 ms — these are cognitively different tools to someone using them all day.

JS is fundamentally **single-threaded, GC-managed, dynamically typed**. Parsing, AST transforms, bundling — these are the canonical CPU-bound parallel workloads. Rust is the opposite: multi-threaded, no GC, statically typed, zero-cost abstractions. The trade-offs line up.

When esbuild proved in 2020 that **"a Go rewrite can be 100x faster,"** the ecosystem's minds shifted. Evan Wallace cut a 20-second webpack build to 200 ms. The next question was natural: **"Why isn't everyone doing this?"**

The answer split two ways.

- **Go**: has GC, simple syntax, fast compilation, but lacks zero-cost abstractions. esbuild went this way.

- **Rust**: no GC, painful ownership, steep learning curve, but real systems-level performance and safety together. Almost every other successor went this way.

By 2026 the result is clear. **Rust won.** swc, Turbopack, Rspack, Biome, oxc, Rolldown, Farm, Lightning CSS, tsdown — almost all new tools are Rust. Go: esbuild. Zig: Bun. Everything else: Rust.

2. A Classification Table — Understand by Role First

Too many names. Group by **role** and it gets simple. The build chain has stages.

| --- | --- | --- | --- |

Keep this in your head and any new name lands in the right slot.

One more — the "tool consolidation" pattern

The Rust era has a second pattern: **one tool covers multiple stages**. Biome merges lint + format. oxc tries to fit parse + transform + lint + format + minify + resolve under one roof. Bun fuses runtime + package manager + bundler + test runner. **Vertical integration.**

The JS era was Unix philosophy — "do one thing well." The Rust era is "share one AST so we parse only once." Both have merit. Which wins is undecided. Momentum right now is on the consolidation side.

3. Turbopack — Next.js 15 Default Dev (Build Still Beta)

**Who** Vercel. Initially led by Tobias Koppers, the creator of webpack.

**Language** Rust.

**Role** Bundler + dev server.

**Status (May 2026)** Next.js 15 default dev. Build is still beta. Next.js 16 targets stable.

The Core Idea — Function-Level Caching

The key difference from webpack/Vite is a cache layer called **Turbo Engine**. Every transformation is expressed as a function; if the input is the same, the output is cached. Turbopack calls this **incremental computation**.

// Turbo Engine tracks the dependency graph automatically

#[turbo_tasks::function]

async fn parse_module(path: FilePath) -> Result<AstVc> {

let source = read_file(path).await?;

Ok(swc_parse(source))

}

Call `parse_module` twice with the same input and the second call hits cache. Change a file and only the functions that depend on it are invalidated. The net effect is near-instant HMR.

Reality — Why Build Is Still Beta

In 2024–2025 the common review of Turbopack was "dev is fast, build is unfinished." Edge cases in CSS Modules. Compatibility issues with webpack plugins like Sentry. Subtle differences from webpack output in some module federation scenarios. As of 2026, build is opt-in beta in Next.js 15. **Whether to adopt it for production depends on context** — Vercel-hosted, vanilla Next.js apps are increasingly safe. Apps with deep webpack plugin estates often still keep webpack build.

Who Should Use It

- New Next.js 15+ projects → just turn it on for dev.

- Existing Next.js 12–14 projects → dev fine, keep webpack for build.

- Non-Next React apps → no direct Turbopack path yet. Rspack or Vite is the answer.

4. Rspack — ByteDance, webpack Compatibility as a Weapon

**Who** ByteDance (TikTok's parent). Maintainers include Han, hardfist.

**Language** Rust.

**Role** Bundler.

**Status (May 2026)** v1.x stable. Used in thousands of ByteDance internal projects.

Core Idea — webpack API Compatibility

Turbopack chose "rewrite from scratch." Rspack chose the opposite — **near-perfect compatibility with the webpack API and plugin system**. `module.rules`, `resolve`, `plugins`, `optimization` — almost identical shape. A large subset of webpack plugins work with minor edits or none at all.

// rspack.config.js — practically the same as webpack.config.js

module.exports = {

entry: './src/index.tsx',

resolve: {

extensions: ['.tsx', '.ts', '.js'],

module: {

rules: [

{ test: /\.tsx?$/, use: 'builtin:swc-loader' },

plugins: [

new HtmlRspackPlugin({ template: './public/index.html' }),

};

That compatibility strategy let ByteDance's enormous internal webpack estate migrate to Rspack with **almost no rewrites**. Reported build times dropped 5–10x.

Rsbuild — A Friendlier Layer on Top

Rspack is webpack-shaped, which means webpack-shaped configs are still painful. ByteDance also ships **Rsbuild** — uses Rspack underneath but exposes Vite-style sensible defaults and a clean DSL. In 2026, most new Rspack adoption goes through Rsbuild.

Rsbuild is a one-liner to start

npm create rsbuild@latest my-app

Who Should Use It

- Migrating a large webpack project quickly → Rspack.

- New project, want webpack-style flexibility → Rsbuild.

- Non-Next React production app where build speed matters → Rspack/Rsbuild is among the safest picks.

5. esbuild — The Go-Based Speed Baseline

**Who** Evan Wallace, co-founder of Figma.

**Language** Go.

**Role** Bundler + transformer + minifier.

**Status (May 2026)** v0.24+. Stable. Focus is on stability rather than new features.

Position

esbuild was the **trigger** of this whole wave. When it dropped a 20-second webpack build to 200 ms in 2020, the industry concluded: **native-compiled languages are the answer.**

By 2026 esbuild sits in an interesting place. **Still the fastest, but increasingly used indirectly.** Reasons:

- **Feature scope is deliberately narrow.** Evan Wallace treats esbuild as a "library and baseline." Code splitting is experimental. The plugin API is intentionally limited.

- **Other tools embed esbuild.** Vite uses esbuild for dependency pre-bundling. tsup is an esbuild wrapper. It is becoming **invisible plumbing** rather than a user-facing tool.

Where You Still Pick It Directly

- Library builds — small, fast ESM/CJS dual outputs.

- Simple CLI/script bundles — when webpack is overkill.

- As an engine inside another tool — Vite, tsup, tsdown all use esbuild as a part.

// esbuild as a library — five lines do it

await build({

entryPoints: ['src/index.ts'],

bundle: true,

format: 'esm',

outfile: 'dist/index.js',

external: ['react', 'react-dom'],

});

esbuild is **not going away**. Direct user surface shrinks; "engine inside other tools" grows.

6. swc — The Rust Transpiler That Replaced Babel

**Who** kdy1 (DongYoon Kang). Backed by Vercel; adopted as Turbopack's transpiler.

**Language** Rust.

**Role** Parser + transformer + minifier.

**Status (May 2026)** Stable. The default transpiler in Next.js. 20–70x faster than Babel on typical loads.

What It Replaced

Babel defined an era. Down-level ES6 to ES5. JSX transform. TypeScript stripping. The problem was speed. JS-implemented AST transforms are fundamentally slow.

swc does the same job in Rust. The interface is similar (`.swcrc` vs `.babelrc`, JSX/TS support, custom plugins). The speed is not.

// .swcrc — near one-to-one with Babel config

{

"jsc": {

"parser": {

"syntax": "typescript",

"tsx": true,

"decorators": false

"transform": {

"react": {

"runtime": "automatic"

}

"target": "es2022"

}

Where You Meet It

- Next.js transpile stage (every .tsx/.ts/.jsx).

- Jest with SWC transform (`@swc/jest`) — `babel-jest` replacement.

- Storybook, Turborepo, and the broader Vercel-adjacent toolchain.

Plugins — Still a Loud Area

The Babel plugin ecosystem was massive. swc has a plugin API too — but **plugins must be Rust or WebAssembly**. Higher barrier, smaller community plugin set than Babel. swc team stabilized a Wasm-based plugin API in 2024–2026, and high-traffic plugins like `@swc/plugin-emotion` have swc ports. The long tail is still Babel.

7. Biome — Going After Prettier + ESLint

**Who** Biome team — the continuation of the Rome project. Multiple full-time devs.

**Language** Rust.

**Role** Formatter + linter (both in one tool).

**Status (May 2026)** v2.x. Linter covers a large fraction of ESLint rules. Formatter is near-100% Prettier compatible.

Background — From Rome to Biome

Rome was an ambitious 2020 project: Sebastian McKenzie (Babel creator) wanted to consolidate the whole JS toolchain. It moved to Rust but ran into funding trouble in 2022–2023 and effectively stalled. **Biome is the fork and continuation.** Same code roots, new governance and funding model, and it shipped.

What Is Inside

- **Formatter** — near-Prettier compatible. One-command migration.

- **Linter** — large port of ESLint's recommended ruleset, plus selected React/TypeScript rules.

- **Import organizer** — `eslint-plugin-import` replacement.

- **Speed** — 25x+ vs Prettier, 10–20x vs ESLint.

One install, one command

npm i -D @biomejs/biome

npx @biomejs/biome check --apply ./src

Or migrate from existing configs

npx @biomejs/biome migrate eslint --write

npx @biomejs/biome migrate prettier --write

Limits — Not Yet a Full ESLint Replacement

The ESLint community plugin set is enormous — thousands of rules across `eslint-plugin-jest`, `eslint-plugin-testing-library`, `eslint-plugin-next`, etc. Biome is fast on the core rules but **its API for authoring custom rules is less mature** than ESLint's. In 2026, many teams run a hybrid: Biome for formatting, ESLint for the long-tail rules.

Who Should Use It

- New projects → just Biome instead of Prettier + ESLint.

- Existing projects → easy to migrate Prettier; partial migrate ESLint.

- Monorepo CI where lint/format is the bottleneck → big wins.

8. oxc — Unified Parser/Linter/Formatter, the Backbone of Rolldown

**Who** Boshen and others. Joined VoidZero in 2024.

**Language** Rust.

**Role** Parser, linter (oxlint), resolver, minifier, transformer, formatter (in progress).

**Status (May 2026)** Parser and resolver are production-ready. oxlint is a fast ESLint alternative. Minifier reached swc-minify class. Formatter is beta.

Why oxc Matters

Ninety percent of JS tools start at the **AST**. If parsing is fast, everything on top is fast. oxc (Oxidation Compiler) aims at **"the fastest JS AST toolkit, then put all the tools on top of it."**

+--------------------------------------------------------+

| oxc core |

| +--------+ +----------+ +----------+ +-----------+ |

| +---+----+ +----+-----+ +----+-----+ +-----+-----+ |

| +-----------+-----------------+----------+ |

| | |

| shared AST + shared traversal |

+----------------------+---------------------------------+

+-----------------------------------+

| Rolldown / oxlint / etc |

+-----------------------------------+

**The core idea**: build the AST once, then do lint, minify, format, transform on top of it. Different from swc where each tool re-parses.

oxlint — 50–100x Faster Than ESLint

The linter inside oxc, called `oxlint`. Benchmarks show 50–100x faster than ESLint on equivalent rule sets.

One install, one command

npx oxlint@latest

package.json

{

"scripts": {

"lint": "oxlint",

"lint:check": "oxlint --deny-warnings"

}

A large slice of core ESLint rules, plus selected `typescript-eslint`, `eslint-plugin-react`, `eslint-plugin-jsx-a11y` rules are ported. Not 100% compat — but **CI hybrid where oxlint runs first and ESLint only runs on its narrow remainder** is common in 2026.

Consolidation — VoidZero Absorbed oxc

In July 2024 Evan You founded **VoidZero** and brought oxc's maintainer Boshen on board. That folded oxc, Rolldown, and Vite under one roof. The implication is large — see chapter 14.

9. Rolldown — Rollup Successor, Vite's Next-Gen Bundler

**Who** Evan You + Rolldown core team. Hosted by VoidZero.

**Language** Rust.

**Role** Bundler with Rollup-compatible API.

**Status (May 2026)** Beta. Opt-in in Vite 7. Planned default in Vite 8.

Vite's Reality — Two Bundlers Inside

Vite's open secret: dev and build use **different bundlers**.

- **Dev**: esbuild for dependency pre-bundling, then bundleless ESM.

- **Build**: Rollup.

This hurts sometimes — dev works, build breaks; subtle differences between esbuild and Rollup output surface as bugs. The Vite team has long said they want **one Rust bundler for both**. That bundler is Rolldown.

What It Promises

// rolldown.config.js — Rollup config shape

export default defineConfig({

input: 'src/main.ts',

output: {

dir: 'dist',

format: 'esm',

plugins: [

// Rollup plugins largely work as-is

});

- **Rollup plugin compatibility** — inherit the huge Rollup ecosystem.

- **Speed** — 10–30x Rollup, approaching esbuild.

- **CommonJS support** — native, where Rollup struggled.

- **Code splitting** — full feature where esbuild was weak.

Who Should Use It

- In 2026, direct adoption is still early. Most users meet it through Vite.

- Library tooling where esbuild/tsup feel limiting → beta is worth a try.

10. Farm — The Rising Newcomer

**Who** brightwu and others. Largely China community-driven.

**Language** Rust.

**Role** Bundler + dev server.

**Status (May 2026)** v1.x. Active development; adoption still early.

Differentiation

Farm targets the gap between webpack, Vite, and Rspack.

- **Dev speed — claims faster than Vite** via Rust core + partial bundling.

- **Rollup plugin compatibility** — similar promise to Vite/Rolldown.

- **Explicitly fast HMR** — under 100 ms even in large apps.

// farm.config.ts

export default defineConfig({

compilation: {

input: { index: './src/main.tsx' },

output: { path: 'dist' },

server: {

port: 9000,

});

Position

Functionally Farm targets the Vite/Rsbuild slot. The pitch is "faster than Vite, less webpack baggage than Rspack." In 2026 **the case for picking it is still soft** — Vite and Rspack are already fast enough with bigger ecosystems. Farm is one to watch but not a default recommendation.

11. Vite 6 — The Environment API, Multiple Environments

**Who** Evan You, Vite core team, VoidZero.

**Language** TypeScript core (uses esbuild/Rolldown internally).

**Role** Dev server + build orchestrator.

**Status (May 2026)** v6 stable. v7 has opt-in Rolldown. v8 plans Rolldown by default.

The Heart of v6 — Environment API

Through Vite 5, the "browser build" was a first-class citizen. As **SSR, RSC, edge, worker** environments multiplied, a single project started owning many build outputs. Vite 6's Environment API makes that explicit.

// vite.config.ts

export default defineConfig({

environments: {

client: {

build: {

outDir: 'dist/client',

ssr: {

build: {

outDir: 'dist/ssr',

ssr: true,

workerd: {

build: {

outDir: 'dist/worker',

resolve: {

conditions: ['workerd', 'edge'],

});

Each environment owns its own `resolve.conditions`, its own plugin filters, its own module graph. Huge unlock for framework builders (Nuxt, SvelteKit, SolidStart) who previously had to invent hacky SSR/CSR separation. Now it is first-class API.

Vite's Position — The De Facto Standard

Since 2020 Vite has become the standard dev tool for React/Vue/Svelte/Solid and nearly every other framework. By 2026 Vite passed webpack in npm downloads. Next.js is the major exception (Turbopack track); nearly every other meta-framework sits on Vite.

12. Bun — Zig-Based Unified Runtime + Bundler

**Who** Jarred Sumner. Oven Inc.

**Language** Zig.

**Role** Runtime + package manager + bundler + test runner.

**Status (May 2026)** v1.x stable. Node.js compatibility has improved dramatically.

A Different Species

Bun is not on the same axis as the other tools. Bun targets **Node.js replacement**. The bundler is a feature, not the headline.

package manager

bun install

script runner

bun run dev

test runner

bun test

bundler

bun build src/index.ts --outdir dist

runtime

bun src/server.ts

One binary. Takes aim at `node` + `npm` + `tsc` + `webpack` + `jest` at once.

Reality in 2026

- **The package manager is genuinely fast.** `bun install` is 5–25x faster than `npm install` in many reports. Some teams use **Bun only as their package manager** while keeping Node as the runtime.

- **Runtime compatibility** has improved sharply. Express, Fastify, Hono, Elysia all work. The remaining issues are some Node native modules.

- **The bundler** is in esbuild's class. Rarely picked alone; comes "for free" when you are already on Bun.

- **The test runner** targets Jest API compatibility. `bun test` is widely reported as faster than `jest`.

Who Should Use It

- **New server-side TS project** → strongly consider Bun, especially for a simple API.

- **Monorepo package manager** → Bun is a fine pick. Faster than pnpm, compatible enough.

- **Existing large Node project** → migrate cautiously. Native module dependencies are the deciding factor.

13. tsdown / Lightning CSS — Small But Important

tsdown — A TypeScript Library Bundler

**Who** Sxzz (Vite/Vue contributor). Started in 2024.

**Language** Rust (thin wrapper over Rolldown).

**Role** TypeScript library bundler. Successor to tsup.

tsup was an esbuild wrapper that inherited esbuild's limits — weak code splitting, separate DTS generation. tsdown sits on Rolldown to remove those.

package.json

{

"scripts": {

"build": "tsdown"

}

tsdown.config.ts

export default defineConfig({

entry: ['src/index.ts'],

format: ['esm', 'cjs'],

dts: true,

});

Small but important for library authors. ESM/CJS dual output, automatic DTS, Rolldown-based fast builds.

Lightning CSS — A Rust CSS Pipeline

**Who** Devon Govett, creator of Parcel.

**Language** Rust.

**Role** CSS parser + transformer + minifier + bundler.

Replaces postcss + cssnano + autoprefixer in one binary. Downlevels modern CSS — CSS Modules, CSS Nesting, @layer, color-mix().

**Why it matters**: Tailwind CSS 4 swapped its internal engine to Lightning CSS. In 2026 effectively every Tailwind v4 project uses Lightning CSS.

npm i -D lightningcss

Standalone use also works

npx lightningcss --minify --bundle --targets '>= 0.25%' src/style.css -o dist/style.css

Other Small Tools

- **unbuild** — UnJS camp's library builder. Rollup-based.

- **tshy** — Isaac Schlueter's (npm creator) TypeScript dual-build helper.

- **dprint** — Rust multilanguage formatter. Competes with Biome.

- **moonrepo / nx** — not build tools but build orchestrators (compete with Turborepo).

14. VoidZero — What a Consolidated Company Means (July 2024)

In July 2024 Evan You announced **VoidZero**. Leaving the nonprofit-style Vue Foundation work behind, his bet: **"Build the whole Rust-based JS toolchain under one company."**

The People Inside

- **Evan You** — Vue, Vite.

- **Boshen** — oxc maintainer.

- **Patak (Vite core), bluwy (Vite core)**, and many more.

- **Sxzz** — tsdown, Vue/Vite contributor.

Series A was about 4.6M USD (Accel led). Small by SaaS standards, meaningful for an open-source tool company.

What It Targets

VoidZero's explicit vision: **a Rust-based unified JS toolchain**.

- **Parser/Resolver/Minifier** — oxc.

- **Bundler** — Rolldown.

- **Dev server / build orchestrator** — Vite 7/8.

- **Linter** — oxlint.

- **Formatter** — oxc-formatter (in progress).

- **Test runner** — Vitest (already widespread).

Each tool is independently usable. But they share **the same AST and the same traversals**. The JS-era inefficiency of "every tool re-parses" is gone.

Why It Matters

JS build tooling long lived on the **goodwill of individual maintainers**. Babel, webpack, Rollup, Prettier — almost all carried by one or two people. That model repeatedly produced burnout and funding crises (Rome died there).

VoidZero is the **first serious attempt to switch to a company model**. Vercel does something similar with Turbopack and swc, but its tools are tied to Vercel's product. VoidZero positions itself as **vendor-neutral** — any framework can use it.

Whether the model works is unknown in 2026. But **if the company survives, VoidZero defines the next five years of the JS build chain**. Vercel/Turbopack/swc vs VoidZero/Rolldown/oxc — a two-camp landscape is now the 2026 picture.

15. State of JS Tooling 2025 (Cara / Devographics)

Cara (formerly Devographics) runs the State of JS Tooling survey every year. The 2025 results landed with these headlines:

- **Vite has the highest satisfaction.** 86% usage, 94% user satisfaction.

- **Turbopack and Rspack adoption are climbing fast.** Turbopack rides Next.js adoption; Rspack is strong in monorepos.

- **esbuild's direct usage drops but indirect usage is everywhere.** Satisfaction remains very high.

- **Bun's package-manager usage is climbing sharply.** Runtime usage still in experimentation.

- **Biome adoption has not passed ESLint yet but satisfaction is higher.** New-project picks shifting fast.

- **webpack is still the most-installed but new starts are near zero.** It is approaching legacy status.

The data **backs up the high-level story with numbers**. Adoption is gradual but new starts flow nearly entirely to the Rust camp.

16. Who Should Pick What — Scenario Recommendations

Scenario 1: A New Next.js App

- **Dev**: Turbopack (Next 15 default).

- **Build**: Turbopack default coming in Next 16. Until then, webpack.

- **Transpile**: swc (automatic).

- **Lint/Format**: oxlint + Biome, or stay with ESLint+Prettier.

Scenario 2: A New Non-Next React App

- **Bundler**: Vite 6, or Rsbuild.

- **Dev server**: Vite (de facto standard).

- **Transpile**: swc or oxc-transformer (handled by Vite under the hood).

- **Lint/Format**: Biome or oxlint+Prettier.

Scenario 3: A Library (npm Package)

- **Bundler**: tsdown (Rolldown-based) or tsup (esbuild-based, small libs).

- **Types**: tsc for DTS only is still the safest path.

- **Format**: Biome.

- **Lint**: oxlint + selected ESLint plugins.

Scenario 4: CLI / Simple Script

- **Bundler**: esbuild directly, or Bun build.

- **Runtime alternative**: Bun (single-file execution is strong).

Scenario 5: A Huge webpack Monorepo (Migration)

- **Step 1**: Babel to swc (safest).

- **Step 2**: webpack-dev-server to Vite (per app).

- **Step 3**: webpack to Rspack (use config compatibility).

- **Step 4**: ESLint to oxlint (first-pass in CI only).

Scenario 6: Backend TS Service

- **Runtime**: Bun (simple API), Node.js (maturity-first).

- **Bundler**: tsdown or esbuild.

- **Package manager**: Bun, pnpm.

- **Test**: Vitest, bun test.

One-Line Decision Tree

- **Need fast dev?** → Vite (mostly), Turbopack (Next).

- **Keep a huge webpack as-is?** → Rspack.

- **A library?** → tsdown.

- **Lint and format in one tool?** → Biome, or oxlint+dprint.

- **Everything in one binary?** → Bun.

17. Closing — What 2030 Probably Looks Like

When esbuild dropped in 2020 a lot of people felt "this is the start." When VoidZero was announced and Turbopack became Next.js 15's default in 2024, **the shape of the destination got visible**.

The 2030 JavaScript build chain probably looks like this.

- **A shared AST core** — oxc or swc handles nearly all parsing.

- **Two big umbrellas** — Vercel/Turbopack/swc and VoidZero/Rolldown/oxc.

- **Vite is the dev standard** — basically every meta-framework outside Next.js sits on it.

- **JS-implemented build tools are museum pieces** — new adoption of webpack, Rollup, Prettier, ESLint trends to zero.

- **Bun captures some of the runtime / package-manager market** — doesn't fully replace Node.

- **CSS is Lightning CSS** — partly via the Tailwind v4 wave.

- **Lint is mostly oxlint + selected ESLint plugins.**

Whether this shape is right or wrong is unknown. **The most reliable rule in JS build-tool history is that "the picture five years out is always different from what we predict."** But one direction is essentially certain — **JS build tools are no longer written in JS**. That direction does not reverse.

It is a good time. If you have to pick today, **pick from the Rust camp** and **keep an eye on both Vercel and VoidZero**. The 2030 standard will come out of one (or both) of them.

References

- Turbopack: https://turbo.build/pack

- Next.js 15 release notes: https://nextjs.org/blog/next-15

- Rspack: https://rspack.dev

- Rsbuild: https://rsbuild.dev

- esbuild: https://esbuild.github.io

- swc: https://swc.rs

- Biome: https://biomejs.dev

- oxc (Oxidation Compiler): https://oxc.rs

- oxlint: https://oxc.rs/docs/guide/usage/linter

- Rolldown: https://rolldown.rs

- Farm: https://www.farmfe.org

- Vite: https://vitejs.dev

- Vite 6 Environment API: https://vitejs.dev/guide/api-environment

- Bun: https://bun.sh

- tsdown: https://tsdown.dev

- Lightning CSS: https://lightningcss.dev

- VoidZero announcement (July 2024): https://voidzero.dev/posts/announcing-voidzero-inc

- State of JS Tooling 2025 (Cara/Devographics): https://stateofjs.com

- Tobias Koppers on Turbopack: https://turbo.build/blog