I run this site, focusing on testing. And I believe part of that is running your tests (and lint/type checks) in your CI/CD pipeline (such as on GitHub Actions) on every pull request.

But some of these checks can take forever to run. For years you have probably used eslint and prettier - both of which are written and execute in Node's JavaScript runner. There has been a push recently for new tools that have the same behaviour, but written in native Golang or Rust for significant speed improvements. And in my opinion they are at the stage where you can start using them in your CI/CD checks on production.

These new tools are so quick that you can run them on all files on each commit, and you will not even notice they're running. But this blog post is focusing on your CI/CD pipeline (such as on GitHub actions). Just go and try these tools out, they're almost instant.

There are some new tools that have been appearing in the last few years that I believe can replace slower tools that you are almost definitely using on frontend applications.

I'm only including tools that require very little additional config and you should be able to drop them into your app within a few minutes, to compare if they are significantly faster.

I've tried them out on this app (HowToTestFrontend.com, with all of the app, including the complex browser based test runner for our lessons) and included all time savings below. I've also tried them out on other apps (smaller, and much larger) and saw even more significant time reductions in CI/CD runtimes.

Replace tsc with tsgo for faster TypeScript type checking

I am assuming that in 2026, if you have frontend applications you are probably using TypeScript.

You probably have a step in your CI/CD pipeline that checks that your TypeScript types are valid. (If you don't: please set this up immediately! Type checks are one of the most important checks to check in your CI/CD flow)

This is normally this simple command - run the TypeScript compiler (tsc) with --noEmit:

tsc --noEmit

This might be listed as script in your package.json, such as:

{
  "scripts": {
    "typecheck": "tsc --noEmit"
  }
}

You can replace this with the Go version of the TypeScript compiler, tsgo.

The easiest way: just install npm install @typescript/native-preview then run npx tsgo --noEmit.

The only config change I've found I had to do was remove baseUrl from my tsconfig. (This had no impact. In the TS docs, it says "As of TypeScript 4.1, baseUrl is no longer required to be set when using paths")

On this website (HowToTestFrontend.com), which I would say is a medium sized app - nothing too huge, but definitely not a small weekend project, it went from 42 seconds with tsc --noEmit to just 17 seconds with tsgo --noEmit.

This can be reduced even further by installing it in your package.json.

Replace Prettier with oxfmt

Prettier is used to format your code according to rules (such as correct spacing, trailing commas, tabs vs spaces etc).

There is a new tool called oxfmt which is written in Rust and claims to be 30x faster than Prettier , and 3x faster than Biome (another recent toolset, also focusing on being faster than existing tools).

While I haven't seen 30x speed difference compared to Prettier, I have seen it run almost twice as fast. This is enough to make significant improvements if you have a big enough app.

On this app (HowToTestFrontend.com), it used to take 14 seconds with prettier.

With oxfmt it takes 6 seconds. Slightly under half the run time of prettier!

Setup is really easy - you just install it (npm install -D oxfmt) and run it. See docs here - takes a few minutes to get it up and running.

There is a full migration guide from Prettier here but I've found even just with defaults it works quite well.

Replace eslint with oxlint

Another tool from the same team as oxfmt is oxlint

It is a replacement for ESLint . It supports more than 600 rules from ESLint core and popular ESLint plugins.

Both ESLint and oxlint are linting tools that check your code for potential bugs, enforce coding standards, and ensure consistency across your codebase.

On this app it used to take 32 seconds with eslint

With oxlint it takes 1 second. I had to double check I was even running it correctly as it is honestly that fast.

Finished in 98ms on 643 files with 90 rules using 2 threads.

I cannot get over how incredibly fast it is.

You can install it (npm add -D oxlint) then run it, or oxlint --init to initially set it up. There is also a migration guide for moving from ESLint .

So what should you do?

In summary, this is what I recommend:

• For checking types (tsc --noEmit replacement), use tsgo.
  • Try it out right now with npx tsgo --noEmit - you might need very minor tsconfig.json changes
• For linting, replace eslint with oxlint
• For formatting, replace prettier with oxfmt

Total time savings

For this website (the entire HowToTestFrontend.com site, in-browser test runner, and so on):

• Total before: 88 seconds (42 + 14 + 32)
• Total after: 24 seconds (17 + 6 + 1)
• Savings: over 1 minute saved (just over 70% in time savings)

Which is even more than half that I put in the title, but I didn't want this to look like fake clickbait.

Of course, this is "only" 1 minute. But this all adds up when there are multiple people on multiple teams trying to get their PRs and deploys out several times a day.

On larger applications (HowToTestFrontend.com is my personal passion project, it is nowhere near the size of an app at your typical SaaS or startup!) you will see much bigger improvements in most cases.

Should You Switch to these tools in an existing app?

I would strongly recommend at least trying to switch to these tools in an existing app. It can take a few minutes to get an idea of if it will easily work with your codebase and you will see the speed improvements immediately.

Although these are quite new tools, and might have some teething problems over the next 12-18 months I believe (from my experience of using it) that they are all production ready for CI/CD checks like this.

You can quite easily drop them in and test them out

• if you are seeing < 10 seconds of improvement it is probably not worth it right now, especially if additional configuration will still be needed.
• If you are seeing > 120 seconds then I would strongly argue you will see the benefits easily.
• The middle ground might not make much difference - your regular tests (jest/vitest etc) are probably going to take longer than these checks anyway, so it might not make much noticeable difference to you or your developer team mates.

ESLint (which can be replaced with oxlint) and Prettier (which can be replaced with oxfmt) also has a lot of custom plugins. It is likely that you have at least 3 or 4, and I've seen apps with 15+ ESLint plugins and very complex configuration. In those cases you might have to balance faster linting vs a tried and tested configuration with well known and popular tools.

Either way, I'd still give it a go if I were you. The oxlint tool already supports most of the main ESLint rules/plugins, so it might be quite compatible - check their migration page .

Should you use these on new apps?

I would by default now start with these in most apps. But similarly to the paragraph above about custom prettier or eslint configurations - you may want to stick with what you know and where there is already years of support for the more established tools.

For your general run-of-the-mill React or Node based app, I would however go with these new tools.

Important notes:

• While they generally are a drop in replacement and from my testing over several apps they work very well, you may need to spend a bit of time configuring them for your app.
• The timings I've used in this blog post are the run time of each check, and do not account for the extra time on npm install. It will still be a net gain anyway.
• All three of these tools are in my opinion ready for production, but they are still in very early stages. Expect version bumps with breaking changes that might be a bit awkward to update. I think the trade off is good enough right now.
• I also only use the Go based TypeScript compiler for type checks on CI/CD. You can check the table on the GitHub microsoft/typescript-go repo to see what is fully compatible. For type checking it is completely safe and compatible.