What happened

For type checking, the team evaluated TSGO, Microsoft’s newer Go-based implementation of TypeScript tooling. The author reports that a cold full scan fell from 66.4 seconds to 6.39 seconds, while average memory use dropped from roughly 447 MB to 76 MB. The project is still evolving, so compatibility testing on a real repository and in CI remains essential.

The linting story followed a similar path: from ESLint, through Biome, to Oxlint. Biome was quick in the reported tests, but the team found missing rules and editor-process crashes unacceptable. Oxlint, written in Rust, was not the fastest number in every comparison, but it retained the needed rule coverage and behaved reliably in daily work.

The largest perceived change came from bundling. After Webpack and a Vite evaluation that did not meet this microfrontend setup’s Module Federation needs, the team moved to Rsbuild, which is built on Rspack. The article reports hot reload falling from about 36 seconds to one second, along with a smaller output bundle. Compatibility, not raw speed alone, made that migration viable.

Why it matters

A few seconds in one operation seem minor until they are repeated across a team. The article uses a simple example: with 40 developers making 50 edit-and-check cycles per day, reducing a 36-second wait to one second can reclaim nearly 20 hours daily. It is the author’s estimate, but it makes the compounding cost of slow feedback tangible.

The important point is that these tools form a chain. A faster bundler does not help much when linting or type checks still hold changes in CI. Conversely, replacing a mature tool for an attractive benchmark can cost more than it saves if plugins, rules, or microfrontend behaviour break.

There is also the contract boundary between frontend and backend. The author advocates treating swagger.json as the single API contract and generating client types and functions from it. A changed API can then fail a build before merge instead of becoming a production integration surprise.

In practice

Start with measurements from the actual repository rather than a vendor comparison. Measure cold and incremental type checks, linting, hot reload, memory use, and CI duration separately. That gives every migration a baseline and a concrete success condition.

Then introduce changes in controlled stages:

1. Run TSGO alongside the existing tsc check in CI and compare diagnostics before switching.
2. Validate Oxlint or another linter against the current rule set; missing checks matter more than a faster command.
3. Trial Rsbuild on one application area first, especially when Module Federation, nonstandard loaders, or Webpack plugins are involved.
4. Generate API clients from the published contract and commit regenerated types with the backend API change.
5. Enable React Compiler gradually, watching component behaviour and keeping performance checks before and after the rollout.

React Compiler completes the picture by moving some manual memoisation work to compilation. It can reduce defensive useMemo, useCallback, and memo wrappers, but it does not solve expensive calculations, poor state boundaries, or weak component architecture on its own.

Takeaway

The article’s main point is not that every project should adopt the same five products. It is that teams gain leverage when developers can see the consequence of a change sooner and when contract or rule mismatches fail before release.

Evaluate TSGO, Oxlint, Rsbuild, and React Compiler as parts of one feedback system, not as fashionable replacements. A small application may not recover the migration cost, while a large codebase can turn seconds saved in frequent operations into a noticeably different working day.