DEV Community

Cover image for Why Vite Asked Me to Choose Between Oxlint and ESLint
Janarthanan Soundararajan (Jana)
Janarthanan Soundararajan (Jana)

Posted on

Why Vite Asked Me to Choose Between Oxlint and ESLint

#react #typescript #oxlint #webdev

While initializing a new Vite project (npx create-vite), I hit an interactive CLI prompt that paused my standard workflow:

◆ Which linter to use?
  ● Oxlint
  ○ ESLint
Enter fullscreen mode Exit fullscreen mode

Having relied on ESLint as my default linter for years, this piqued my curiosity. The filled bullet (●) wasn't a formal endorsement from Vite—it was simply where the CLI cursor landed—but it made me pause. Why is Vite offering Oxlint alongside ESLint, and when does it make sense to use it?

Here are my first impressions after looking into what Oxlint is, how it works under the hood, and how I plan to test it out.

❓ Why Is Vite Offering Oxlint?

Vite doesn't recommend Oxlint over ESLint—it simply presents both as first-class options during project creation. Given the growing adoption of native tooling such as SWC, Biome, and Rolldown, adding Oxlint feels consistent with the broader direction of the frontend ecosystem, while still leaving the choice to developers.

Rather than forcing one choice, Vite simply lets developers decide which workflow best fits their needs.

🔍 What is Oxlint?

From my preliminary research, Oxlint is a linter developed as part of the Oxc (Oxidized Compiler) project.

The core difference seems to be the engine: while ESLint runs on Node.js/JavaScript, Oxlint is written in Rust. Because Oxlint is a native executable rather than a JavaScript package running inside Node.js, it can reduce startup overhead and take advantage of parallel execution on modern CPUs.

Rather than trying to replace every custom rule or plugin in the JavaScript ecosystem on day one, Oxlint's current focus appears to be catching common correctness bugs, React hook pitfalls, and type safety issues with minimal setup overhead.

⚔️ How They Seem to Compare

Here is a high-level snapshot based on the documentation and early community feedback I've gathered so far:

Metric / Feature ESLint Oxlint
Runtime Engine Node.js / JavaScript Rust (Oxidized)
Execution Speed Varies by project size, plugins, and custom rules Official Oxlint benchmarks report significantly faster execution than ESLint, and early community feedback has generally reflected similar experiences, though results depend on the project.
Setup & Config Requires eslint.config.js Designed around sensible zero-config defaults
Plugin Ecosystem Very mature and extensive Smaller plugin ecosystem, with built-in support for many common React, TypeScript, JSX, and Jest rules
Primary Value Deep customization & strict team policies Fast local feedback and low initial setup friction

⚡ Why the Speed Pitch Caught My Eye

What made me want to investigate Oxlint further is the promise of shorter developer feedback loops.

In past projects, running pre-commit hooks (husky / lint-staged) or saving files during local hot reloading (HMR) sometimes created a small delay while validating code:

# Typical local feedback loop:
# 1. Save or stage a file.
# 2. Run the linting process.
# 3. Wait for rule validation before moving on.
Enter fullscreen mode Exit fullscreen mode

If Rust-based linters can make that validation step feel nearly instant during active coding, that could be a subtle but nice improvement in daily flow. I'm curious to see if that holds true as my project grows from a fresh scaffold into a complete application.

🏗️ The Hybrid Idea I'm Curious to Try

As I read through discussions on how developers are approaching this, one approach I came across repeatedly was a hybrid setup:

  • For local dev & pre-commit hooks: Use Oxlint as a lightweight frontline defender to catch common mistakes instantly without slowing down commits.
  • For CI/CD pipelines: Keep ESLint running in GitHub Actions if complex, custom ESLint plugins or team-wide policies are required later on. 
// package.json - Conceptual hybrid setup I may experiment with
{
  "scripts": {
    // Frontline check for local HMR & pre-commit hooks
    "lint:fast": "oxlint --deny-warnings",
    // Deep structural audit for CI/CD pipelines
    "lint:ci": "eslint ."
  }
}
Enter fullscreen mode Exit fullscreen mode

🧪 Next Steps & What I'm Testing Next

I decided to select Oxlint for this new Vite build as an initial experiment. Since this is a brand-new project, it felt like a good opportunity to evaluate a newer tool without worrying about migrating an existing lint configuration.

Right now, the codebase is in its early stages, so getting started required virtually no configuration. As I build out components, integrate state management, and add visualizations (like D3 charts), I'm planning to observe:

  1. How well Oxlint catches real React/TypeScript errors during active development.
  2. Whether I run into any rule limitations that force me to bring ESLint back into the loop.

I'll be keeping notes as the project develops and might share a follow-up post with actual hands-on impressions once the site is fully built!

Update: If my experience changes after building a larger React application, I'll publish a follow-up comparing Oxlint and ESLint with real-world usage rather than first impressions.

Top comments (0)