- TypeScript adoption continues to grow, but teams face trade-offs between safety and setup overhead.
- The linter ecosystem has shifted with Rust-based tools like Biome and Oxlint challenging ESLint's dominance.
- Speed benchmarks show dramatic gains, but plugin depth and type-aware linting remain key differentiators.
- Migration strategies and CI costs play a major role in choosing the right tool for your project.
Every JavaScript and TypeScript team eventually hits the same crossroads: is it time to ditch the old guard and embrace a faster, more modern toolchain? For a decade, the answer was almost always no, because nothing else matched ESLint’s plugin depth. But that changed once Rust-based tooling matured. Biome now bundles a linter and formatter in one binary, while Oxlint, built on the Oxc project backed by Vite creator Evan You, claims lint runs dozens of times faster than the JavaScript-based original. By August 2026, the choice between ESLint, Biome, and Oxlint has become one of the most searched decisions in the coding-tools space, and the right answer depends heavily on codebase size, plugin dependencies, and how much CI time your team is willing to burn.
At the same time, TypeScript itself has become the default for serious JavaScript projects. It’s not just about catching bugs early; it’s about making large codebases maintainable and onboarding new developers without a tribal-knowledge briefing. But adopting TypeScript isn’t free. There’s a setup tax, a compile lag, and the ever-present temptation to use
Why TypeScript Still Matters in 2026
TypeScript’s core promise remains unchanged: catch bugs before they reach production. The compiler acts like a strict raid leader, forcing everyone to follow rules they might resent at first, until those rules start saving their asses. On a long-term enterprise build with a rotating dev roster, skipping types is reckless. You’re choosing to let production find your bugs instead of your compiler, and someone is going to get paged for that decision who didn’t make it. The trade-off is real: raw JavaScript is fast to start but slow to maintain, while TypeScript is slow to start but fast to maintain. That’s the trade you’re actually making, stripped of the sales pitch.
Where TypeScript really earns its keep is in refactoring legacy codebases. Old code is haunted—nobody wrote docs, nobody remembers what processData(x, y, flag) actually expects, and the guy who wrote it left two years ago. Type definitions act as a minimap through undocumented hell. Renaming a field surfaces every broken reference instantly. Dead exports light up instead of rotting silently for years. Try that audit in raw JS and you’ll grep for a function name, find fourteen matches, and still miss the one that matters.
The Linter Evolution: ESLint, Biome, and Oxlint
The linter landscape has split into three distinct camps. ESLint, the JavaScript-native original, has been the default since 2013. It’s written in JavaScript and runs on Node.js, which is exactly why its plugin ecosystem became so deep—any developer who can write JavaScript can write an ESLint rule without learning a second language. ESLint 10.0.0 shipped on February 6, 2026, making flat config the only supported format and formally retiring the old .eslintrc system. As of this writing, the line has moved to the 10.4.x releases.
Biome is a single Rust binary that replaces both ESLint and Prettier, handling linting and formatting in one pass with one config file. It grew out of the Rome project after that codebase was forked and rebuilt. Biome’s 2.x line added type-aware linting rules in 2025 and 2026, and the project now sits at version 2.4.x. Vercel has publicly sponsored Biome 2.0 development, giving it one of the more visible corporate backers among the Rust-based challengers.
Oxlint is the linter piece of Oxc, a Rust-based JavaScript/TypeScript toolchain that also includes a parser, resolver, transformer, and the oxfmt formatter. Oxc is the technical foundation behind Rolldown, the Rust bundler that now powers Vite 8’s default production build. Oxlint trackers put its current release in the 1.6x to 1.7x line as of mid-2026. Unlike Biome, Oxlint doesn’t try to replace your formatter—it focuses purely on catching problems fast and is explicitly designed to run alongside ESLint during a gradual migration rather than force an all-or-nothing switch.
Speed Benchmarks: How Much Faster Is Rust, Really?
Speed is the entire reason Biome and Oxlint exist, and the numbers are staggering. A widely cited 10,000-file benchmark had ESLint finish in 45.2 seconds against Biome’s 0.8 seconds—a roughly 56x gap. A separate monorepo test on a 10,000-line codebase measured ESLint plus Prettier at 3–5 seconds versus Biome finishing in about 200 milliseconds. One team’s documented migration off ESLint and Biome onto Oxlint and oxfmt cut a full lint-and-format pipeline from roughly 81 seconds to 2.5 seconds, with the lint step alone dropping from about 3 seconds to 0.7 seconds. Testing against the Node.js repository itself (6,298 files), Oxlint finished in 21 seconds compared with 1 minute 43 seconds for ESLint—a 4.8x gap on a codebase most JavaScript engineers know well. Head-to-head, Oxlint has been clocked processing roughly 11,774 files per second against Biome’s approximately 5,887 files per second, suggesting Oxlint edges out Biome on raw lint-only throughput even though Biome remains dramatically faster than ESLint.
The pattern across every test is clear: both Rust-based tools beat ESLint by an order of magnitude or more on large codebases, and Oxlint tends to edge out Biome specifically on pure linting throughput because it doesn’t carry formatting logic in the same pass. None of this means ESLint is unusably slow on a small project—on a 200-file app, the wall-clock difference between 0.5 seconds and 2 seconds barely registers. The gap only becomes painful once a codebase crosses into the thousands of files that large monorepos routinely hit.
Downloads, Stars, and Adoption Signals
Raw popularity still favors ESLint by a wide margin. Weekly npm download trackers put ESLint at roughly 134 million downloads in a single week in May 2026, dwarfing Biome’s approximately 8.8 million and Oxlint’s approximately 6.7 million in the same window. That gap reflects ESLint’s decade-long head start and the fact that huge swaths of the npm ecosystem still list it as a peer dependency even in projects that don’t actively run it. GitHub stars tell a similar but less lopsided story: ESLint sits around 27,000 to 27,500 stars, Biome trails at roughly 24,000, and Oxlint ranges from about 17,000 to 22,000 depending on the tracker. Star counts are a weaker adoption signal than downloads, but the relatively narrow gap shows how much attention the Rust-based challengers have pulled in a short time.
Growth trajectory matters more than the snapshot. Multiple 2026 trackers describe Biome’s and Oxlint’s download counts as having grown several times over in roughly a year, while ESLint’s download count has stayed roughly flat as the established default. If that trend holds, the download gap will keep narrowing even if ESLint keeps its lead through 2027.
The Oxc Story: VoidZero, Rolldown, and the Cloudflare Deal
Oxlint doesn’t exist in isolation, and its backing explains why it’s suddenly everywhere. Oxc is the Rust toolchain that also builds Rolldown, the bundler that replaced Rollup as Vite’s default production backend starting with Vite 8, which shipped on March 12, 2026. Vite’s own announcement described Rolldown as 10 to 30 times faster than the Rollup-based pipeline it replaces in production builds. The company steering that work, VoidZero, was founded by Evan You, the creator of Vue and Vite. In June 2026, VoidZero announced it was joining Cloudflare, folding Vite, Rolldown, and Oxc (and by extension Oxlint) under Cloudflare’s stewardship while publicly committing to keep the tooling vendor-neutral. That deal matters for anyone evaluating Oxlint today: it’s no longer a small side project competing for attention against a well-funded rival—it’s now backed by one of the largest infrastructure companies on the internet, with a direct line to the same team responsible for Vite and Rolldown’s roadmap.
For teams already running Vite 8 with Rolldown, adopting Oxlint means staying inside a single vendor’s toolchain end to end, which is a real operational advantage even before you weigh the speed numbers. VoidZero’s own 2026 messaging has leaned hard into this framing, describing Oxlint’s roadmap as “true type-aware linting powered by tsgo,” a reference to Microsoft’s Go-based TypeScript compiler rewrite that shipped its own 10x compile-speed gains in 2026.
Type-Aware Linting: The Hardest Capability to Replicate
Type-aware linting—rules that need to know a variable’s actual type rather than just its syntax—is the single hardest capability to replicate in a fast, standalone linter. It typically requires running a full TypeScript compiler pass. ESLint paired with typescript-eslint remains the most mature option here in 2026 and is still the reference point every other tool gets measured against. Biome added type-aware rules in its 2.x release line without running the full TypeScript compiler, instead approximating type information well enough to cover a large share of common cases. That’s a meaningful engineering trade-off: it keeps Biome fast, but it means Biome’s type-aware coverage isn’t a full substitute for typescript-eslint on codebases with unusual or highly generic type patterns.
Oxlint is taking a different path, building toward type-aware linting powered by tsgo, the Go-native rewrite of the TypeScript compiler that Microsoft shipped as TypeScript 7.0 on July 8, 2026. Because tsgo delivers roughly 10x faster full builds than the old JavaScript-based compiler on large codebases, Oxlint’s bet is that it can eventually offer full type-aware linting without giving up the speed advantage that defines the tool. As of August 2026, that work is still in progress rather than shipped, so teams that need type-aware linting today should treat Oxlint’s type-checking as a roadmap item, not a current feature.
Plugin Ecosystem and Rule Parity
Speed only matters if the tool actually catches the bugs your team relies on ESLint to catch today. ESLint’s plugin ecosystem, built over more than a decade, remains far deeper than either challenger’s. Thousands of published plugins cover everything from accessibility rules to framework-specific patterns to internal company style guides, and any team can write a custom rule in plain JavaScript. Biome ships a documented migration command that imports both legacy and flat ESLint configs, but it explicitly does not migrate YAML-based configs, and it distinguishes between rules it considers “equivalent” to an ESLint rule versus rules it considers merely “inspired” by one. Only equivalent rules migrate automatically. Inspired rules need an explicit opt-in because their behavior isn’t identical. Biome’s docs list solid coverage of typescript-eslint, jsx-a11y, react, and unicorn plugin families, but that’s a fraction of the plugin universe ESLint supports.
Oxlint has moved the fastest on compatibility claims, with some 2026 sources describing an ESLint v9-compatible plugin API and migration tooling that can read an existing ESLint flat config directly. Those compatibility claims are worth verifying against your own rule set before switching, since third-party comparison sources disagree on exactly how complete that parity is today. The safest framing for any team: run Oxlint or Biome side by side with ESLint on your actual codebase and diff the findings before removing ESLint from CI.
Migration Strategies and Common Pain Points
Neither migration should happen in one commit on a codebase of any real size. Both tools include a compatibility path specifically because full parity with ESLint’s rule set isn’t guaranteed. The safest approach runs the new linter in parallel with ESLint for at least one sprint before removing anything. For Biome, start by installing it and running its built-in migration command, which reads your existing ESLint and Prettier configuration and generates a starting biome.json. After the migration command runs, open the generated config and check for rules Biome flagged as “inspired” rather than “equivalent.” Those need manual review since their behavior may differ slightly from the ESLint rule they replace. Keep ESLint installed and run both tools in CI for a sprint, comparing diffs before you delete the ESLint config and its dependencies.
Oxlint is explicitly designed to run alongside ESLint rather than replace it outright on day one, since it doesn’t yet cover the full plugin surface. Add it as a fast first pass and keep ESLint for the rules it doesn’t yet support. A common pattern in 2026 migration write-ups: run Oxlint first in CI as a fast fail-fast gate that catches the majority of issues in under a second, then run ESLint afterward only for the smaller set of plugin-dependent rules Oxlint hasn’t replicated yet. That combination captures most of the speed win without giving up plugin coverage, and it’s a lower-risk stepping stone than a full cutover.
Common pain points include ESLint 10’s mandatory flat config—teams still on the old .eslintrc format have to migrate that first, before they can even evaluate Biome or Oxlint’s own ESLint-config importers. Biome’s migration tool skips YAML-based ESLint configs entirely, so any team using .eslintrc.yml needs to convert to JSON or JS first. Custom, hand-written ESLint rules have no automatic migration path to either Biome or Oxlint, since both tools use their own internal rule engines rather than ESLint’s plugin API for rule authoring. Editor integration can lag behind CLI support, and formatter conflicts are common during a transition period if a team runs Biome’s formatter and Prettier simultaneously without fully removing one.
Cost and CI Impact
All three tools are free and open source, but lint time is billed CI compute time. GitHub Actions charges $0.006 per minute for a standard Linux runner. Using the benchmark numbers, a 10,000-file repo with full lint runs at 200 runs/day would cost about $18.10 per month with ESLint, versus $0.32 with a Rust-based tool. On a Node.js-scale repo (6,298 files), the monthly cost drops from $41.20 to $8.40. These figures are estimates, but the direction is clear: on a large monorepo running hundreds of CI jobs daily, the difference between ESLint and a Rust-based linter can add up to real, budgeted infrastructure spend, not just a developer-experience nicety. That’s before counting the human cost of engineers waiting on a slow pre-commit hook dozens of times a day.
For teams that are already on Vite 8 and Rolldown, adopting Oxlint keeps the whole toolchain under one Oxc-based vendor, which simplifies debugging and version alignment across bundler, linter, and formatter. For new projects starting from scratch, Biome’s all-in-one design and roughly 56x speed advantage over ESLint on large lint runs make it the more pragmatic default in 2026, especially with Vercel’s continued investment behind it. For CI-bottlenecked monorepos, Oxlint as a fast first-pass gate, paired with a slower ESLint run for plugin-specific rules, captures most of the speed benefit without a risky full cutover.
Ultimately, there isn’t a single winner. The data points to a clear default for each situation. If your team runs a large, established codebase with custom ESLint plugins and relies on typescript-eslint’s type-aware rules daily, switching away from ESLint in 2026 still carries more migration risk than it saves in CI minutes. If you’re starting a new project or running a small-to-medium codebase without heavy custom plugin dependencies, Biome is the simplest choice. If your bottleneck is specifically CI compute time on a monorepo running thousands of files through lint checks dozens of times a day, Oxlint’s throughput advantage and its backing from Cloudflare make it worth piloting as a fast first-pass gate today, with ESLint kept in the loop for anything Oxlint doesn’t yet cover. Watch the tsgo-powered type-aware linting work closely—once that ships, Oxlint’s case for a fuller cutover gets substantially stronger.
