You know that feeling when you're waiting for ESLint to finish running, watching the seconds tick by, wondering if you should just make another coffee? Yeah, me too. For years, ESLint has been the de facto standard for JavaScript linting—and for good reason. It's comprehensive, extensible, and has a massive ecosystem. But as codebases grow and CI/CD pipelines demand faster feedback, those 2-3 minute linting runs start to feel like an eternity.
That's exactly what pushed our team to explore alternatives. When I first saw the Reddit post showing Oxlint running 110 times faster than ESLint on a real codebase, I was skeptical. I mean, come on—from 2 minutes 27 seconds down to 1.3 seconds? That sounds like marketing hype. But the numbers were real: 5,360 files, 134 rules, all processed in barely over a second.
In this article, I'll walk you through why we made the switch, what we learned in the process, and whether Oxlint+Oxfmt might be right for your team too. I'll address the specific questions and concerns raised in that original Reddit discussion, share our migration experience, and give you practical advice for making the transition yourself.
The Performance Problem That Started It All
Let's start with the elephant in the room: ESLint is slow. Really slow. And it's not just slow on old hardware—even on an M3 MacBook Pro, which is about as fast as consumer laptops get in 2026, ESLint took 2 minutes and 27 seconds to lint a codebase. That's not a typo. Two and a half minutes of waiting every time you want to check your code.
Now, you might be thinking, "But I only run ESLint on changed files" or "I use it in my editor, not on the command line." Fair points. But here's the thing: CI/CD pipelines don't have that luxury. They need to lint everything on every pull request. And when your team is waiting for CI to finish before they can merge, those minutes add up fast. Multiply 2.5 minutes by 20 developers making multiple commits per day, and you're looking at hours of wasted productivity every week.
The Reddit post that sparked this whole conversation highlighted something crucial: this was with "type-aware rules" enabled. That's important because type-aware linting is where ESLint really starts to struggle. It has to do complex type analysis, which is computationally expensive. Oxlint, on the other hand, takes a different approach that we'll explore in a moment.
What Makes Oxlint So Fast?
When I first saw Oxlint's performance numbers, my immediate question was: "What are they sacrificing to get that speed?" The answer, surprisingly, is less than you might think.
Oxlint is written in Rust, which gives it a fundamental performance advantage over ESLint's JavaScript implementation. But it's not just about the language choice—it's about architecture. Oxlint is designed from the ground up to be fast. It uses parallel processing (notice the "11 threads" in the benchmark), which ESLint doesn't do. It also makes smarter decisions about what to analyze and when.
Here's the key insight: Oxlint focuses on correctness and performance, not configurability. ESLint is incredibly configurable—you can write custom rules, plugins, you name it. That flexibility comes at a cost. Oxlint takes a more opinionated approach. It implements the most commonly used rules from ESLint, but it does so in a way that's optimized for speed.
From what I've seen, Oxlint covers about 80-90% of the rules that most teams actually use. The edge cases, the super-specific custom rules—those might not be there yet. But for the vast majority of projects, Oxlint has everything you need.
The Oxfmt Side of the Equation
While the Reddit post focused on linting, the migration story is really about two tools: Oxlint for linting and Oxfmt for formatting. This is important because most teams use ESLint with Prettier, and Oxfmt is Oxlint's answer to Prettier.
Oxfmt is interesting because it's not just a Prettier clone. It's built on the same Rust foundation as Oxlint, which means it's fast. Really fast. But more importantly, it's designed to work seamlessly with Oxlint. No more configuration conflicts between ESLint and Prettier. No more wondering which rules should be handled by which tool.
In practice, what this means is that you get a unified code quality toolchain. Oxlint catches the logic issues, Oxfmt handles the formatting, and they do it in a fraction of the time of the ESLint+Prettier combo. The integration is so smooth that you barely notice there are two tools involved.
Migration: Easier Than You'd Think
Okay, so Oxlint is fast. But is migrating to it a nightmare? Surprisingly, no. The migration process was smoother than I expected.
First, you need to install Oxlint and Oxfmt. That's straightforward with npm or yarn. Then comes the configuration. Oxlint can actually read your existing ESLint configuration and translate most of it automatically. This was a game-changer for us. We didn't have to start from scratch—we could gradually migrate rules over.
The real test came when we ran Oxlint on our codebase for the first time. We expected thousands of errors. We got... a few hundred. And most of them were legitimate issues that ESLint had been missing or ignoring. That was eye-opening. Oxlint's rule implementations are sometimes stricter than ESLint's, which means it catches problems that ESLint lets slide.
For Oxfmt, the migration was even easier. We just pointed it at our code and let it do its thing. The formatting decisions were sensible and consistent with what Prettier had been doing, but with fewer edge cases and weird formatting decisions.
Addressing the Community's Concerns
The Reddit discussion raised some valid concerns that I want to address directly. Several commenters asked about plugin support and custom rules. This is Oxlint's biggest weakness right now. If you rely heavily on ESLint plugins—especially framework-specific ones like for React or Vue—you might hit some limitations.
However, here's what I've found: the Oxlint team is moving fast. New rules and framework support are being added regularly. And for many projects, the built-in rules are sufficient. The performance gains are so dramatic that for some teams, it's worth temporarily losing a few edge-case rules.
Another concern was about the "single-threaded" note in the ESLint benchmark. Some commenters pointed out that you can run ESLint in parallel across files. True, but that's not the same as true parallel processing within the linting engine itself. Oxlint's multi-threaded architecture means it can analyze different parts of the same file simultaneously, which is a fundamentally different approach.
Real-World Impact on Developer Experience
Let's talk about what this migration actually felt like for our team. The most immediate change was psychological. Waiting 2.5 minutes for linting creates a mental barrier. You hesitate to run the linter because you know it'll interrupt your flow. With Oxlint, you can run it constantly. It becomes part of your natural workflow rather than a separate step.
CI/CD times dropped dramatically. Our pull request checks went from 8-10 minutes down to 2-3 minutes. That might not sound like much, but when you're waiting to merge a hotfix, every minute counts. Developers stopped complaining about CI being slow. That alone was worth the migration effort.
Editor integration was seamless. Most editors that support ESLint can be configured to use Oxlint instead. The feedback is instant. You save a file and see any issues immediately, not seconds later.
When You Should (and Shouldn't) Migrate
Based on our experience and the discussions I've seen online, here's my take on when Oxlint makes sense:
You should consider migrating if: your codebase is large (thousands of files), your CI/CD pipeline is slowed down by linting, you're mostly using standard ESLint rules, or you're starting a new project and want the fastest possible toolchain.
You might want to hold off if: you rely heavily on custom ESLint plugins, you have complex TypeScript configurations that need specific type-aware rules, or you're in the middle of a critical project with no time for tooling changes.
For most teams, I think the migration is worth it. The performance gains are just too significant to ignore. But be honest about your dependencies on the ESLint ecosystem.
The Future of JavaScript Tooling
Looking ahead to 2026 and beyond, I think Oxlint represents a broader trend in JavaScript tooling: the move to native-speed tools written in languages like Rust. We're seeing this with SWC replacing Babel, Turbopack competing with Webpack, and now Oxlint challenging ESLint.
This isn't about JavaScript being slow—it's about recognizing that some tools benefit from being closer to the metal. Linters and formatters are perfect candidates because they need to process large amounts of code quickly.
The Oxlint team has ambitious plans. They're working on better TypeScript support, more framework-specific rules, and improved configuration options. I wouldn't be surprised if, by the end of 2026, Oxlint is the default choice for new JavaScript projects.
Getting Started with Oxlint
If you're convinced and want to give Oxlint a try, here's a practical approach:
Start by running Oxlint on your codebase alongside ESLint. Don't replace ESLint immediately—run both and compare the results. This will give you a sense of what rules might need adjustment.
Focus on the biggest performance pain points first. If CI is your bottleneck, integrate Oxlint there first. If developer experience is the issue, get it working in editors.
For Oxfmt, try it on a subset of your code first. See if you like the formatting decisions. Most teams find it produces very similar output to Prettier, but faster.
And remember: you don't have to migrate everything at once. You can use Oxlint for some checks and ESLint for others during the transition period.
Common Questions and Gotchas
Based on the Reddit discussion and our own experience, here are answers to some common questions:
Q: Does Oxlint work with TypeScript?
A: Yes, but the type-aware rules are still evolving. For most TypeScript code, it works great. For complex generic types, you might occasionally miss something ESLint would catch.
Q: What about monorepos?
A: Oxlint handles monorepos well, but you'll need to configure it differently than ESLint. The performance gains are even more dramatic in monorepos because of the larger code volume.
Q: Can I use my existing ESLint config?
A: Mostly, yes. Oxlint can read and translate many ESLint configurations automatically. Some edge cases might need manual adjustment.
Q: What if I need a rule Oxlint doesn't have?
A: You have a few options: contribute it to Oxlint, use ESLint for just that rule, or reconsider whether you really need that specific check.
Wrapping Up: Is It Worth the Switch?
So, after all this, would I recommend migrating from ESLint+Prettier to Oxlint+Oxfmt? For most teams, absolutely. The performance improvements are real and substantial. The developer experience is better. The tooling feels modern and fast.
But—and this is important—don't migrate just because it's new and shiny. Migrate because it solves a real problem for your team. If ESLint is working fine and you're not feeling the pain of slow linting, maybe wait. The ecosystem will only get better with time.
For us, the migration was a clear win. We saved hours of developer time each week. Our CI pipeline got faster. Our developers stopped complaining about slow tooling. And honestly, it just feels good to use tools that are designed for the scale of modern web development.
The original Reddit poster was right: your mileage may vary. But for a growing number of teams in 2026, Oxlint isn't just an alternative to ESLint—it's the obvious choice. Give it a try on your codebase. You might be surprised by how much time you've been wasting.
