Oxlint – JavaScript linter written in Rust
A new JavaScript linter written in Rust, Oxlint, is drawing attention for being tens to thousands of times faster than ESLint in large codebases, especially in CI pipelines. Commenters welcome the performance and simpler dependency story, but highlight major tradeoffs: limited rule coverage, lack of mature plugin and custom-rule ecosystems, and the risk of fragmenting tooling across multiple Rust-based replacements like Biome and Bun. The debate reflects a broader trend of rewriting JS tooling in compiled languages, balancing raw speed and simplicity against configurability, extensibility, and long‑term maintainability.
Performance and CI Impact
- Many are impressed by reported 50–100x speedups vs ESLint; one case: 75 minutes on 40+ CI workers → ~10 seconds on a single worker.
- Some argue this is transformative for large monorepos and full-repo CI linting; others say lint is rarely the bottleneck and prefer partial (changed-files-only) linting or incremental approaches.
- Debate over whether full-repo linting is necessary; type-aware and cross-file rules are cited as reasons partial linting is hard.
Rules, Customization, and Ecosystem Compatibility
- Big blocker for adoption: lack of parity with ESLint’s ~hundreds of rules and rich plugin ecosystem (TypeScript, React, import rules, “rules of hooks”, etc.).
- Several rely heavily on custom ESLint rules as “continuous codemods” and project-specific static analysis, so they see ESLint as irreplaceable until equivalents exist.
- Oxlint’s planned custom-rules support via Trustfall queries and YAML is seen as promising, but still early.
DX, Configuration, and Workflow
- ESLint configuration is widely described as complex and fragile, especially with TypeScript/React and multiple overlapping rule sets.
- Some praise tools that “just work” with minimal config (Ruff for Python, Deno’s built‑in linter/formatter, Go/Rust conventions) and wish for something similar in JS/TS.
- Others argue initial lint setup is a one-time cost and stable configs can last years.
Comparisons to Other Tools
- Frequent comparisons to Ruff (Python), Biome (ex‑Rome), Bun, Deno, dprint, Pyright, mypy, TypeScript itself.
- Question of why to choose oxlint over Biome; one answer: stronger focus on ESLint compatibility, though Biome reportedly implements more ESLint rules today.
Rust Rewrites and Language Choice
- Thread situates oxlint in a broader trend of rewriting JS tooling in compiled languages (Rust, Go, Zig).
- Supporters: huge speed wins, better memory layout for ASTs, good distribution via single binaries, Rust more accessible than C/C++.
- Critics: performance problems may mask deeper complexity/tech‑debt issues; using non‑JS for JS tooling can reduce contributor pool and risk long‑term sustainability.
Philosophy of Linting
- Disagreement over whether linting should be lightweight/style-only vs deep static analysis core to development.
- Some see heavy linting as overreach and maintenance burden; others view strong, project-specific static analysis as a major productivity and quality “superpower.”