
How can modern tooling save Mercedes-Benz.io engineering time?
In today's fast-evolving JavaScript ecosystem, modern tooling plays a pivotal role, influencing not just how we code but how much time and money we spend doing it.
When working within the JavaScript ecosystem, we can take advantage of various tools to improve quality, consistency, and efficiency. Today, we’ll focus on two standout tools that are achieving significant milestones while remaining drop-in replacements for most use cases.
We are going to talk about bundlers and linters as they can be a bottleneck in development or building for production.
In JavaScript development, a bundler takes individual code modules, whether written as ESM or CommonJS, and assembles them into a cohesive, larger output, such as a complete application or a reusable library.
For web apps, this process enhances loading speed and runtime efficiency, even when using HTTP/2. For libraries, bundling ahead of time reduces the need for re-bundling by the consuming project and can also lead to better performance during execution.
Conversely, linting in JavaScript involves examining your code to catch potential bugs, stylistic inconsistencies, and poor coding habits. A linter is a tool that scans your codebase against a defined set of rules or standards, helping enforce consistency, enhance readability, and prevent common errors before they become real issues.
Contents
How is it changing?
Over the years, various build tools have emerged, including Webpack, Turbopack, Rspack, and Vite. Among them, Vite has gained widespread adoption in the JavaScript community due to its flexibility, user-friendliness, and seamless compatibility with a wide range of projects.
Vite utilises two bundlers under the hood: esbuild and Rollup. You can find more details on this here, so we don’t get much in detail. Their wonderful open-source team, backed by VoidZero, has introduced a new Rust-based bundler designed to replace both esbuild and Rollup. This new bundler retains Rollup's API while significantly enhancing performance and many other improvements.
On the linting front, ESLint has traditionally been the go-to tool for spotting issues in JavaScript code. However, VoidZero is also offering a Rust-powered alternative, Oxlint, that delivers performance improvements, running 50x to 100x faster than ESLint.
As a side note, it's important to remember that simply migrating to Rust doesn't automatically make something faster. Many of these tools also took the opportunity to examine the architecture of other open-source projects, identifying design bottlenecks and making more sustainable decisions for the future, with the reality we know today.
How is it affecting us?
What’s even more impressive about these new tools is that they serve as drop-in replacements. There’s no need to refactor code or spend time figuring out how to integrate everything.
At Mercedes-Benz.io, our frontend nature is micro-frontends, so we can’t just test the full build and see how much it has improved. Still, I was curious to know how much these tools would impact us, both in time and money, and money doesn’t necessarily need to be machine time, but mainly engineering time.
I picked several codebases from some teams, some with more micro-frontends and others fewer, and ran 4 types of tests:
- Drop-in replacement with Rolldown
- Drop-in replacement with Rolldown with SASS-Embedded
- Drop-in replacement with Rolldown with SASS-Embedded + Lightning CSS
- Oxlint instead of ESLint
Since I was already testing it, I decided to embrace two production-ready drop-in replacements, as you can see above.
Sass-Embedded is an alternative to the Sass package. It supports the same JS API as Sass and is maintained by the same team. However, Sass-embedded is a JavaScript wrapper around a native Dart executable. This means it will generally be much faster, especially for large Sass compilations.
LightningCSS is an extremely fast CSS parser, transformer, bundler, and minifier made in Rust. It's a tool that can compile, optimise, and transform CSS, aiming to be faster and more efficient than other traditional tools.
Let's go to the numbers
In all the codebases I tested, the average:
- Only Rolldown: 23% reduction of build time, reaching up to 33%.
- Rolldown + Sass-Embedded: 25% reduction, reaching up to 33%.
- Rolldown + Sass-Embedded + Lightning CSS: 34% reduction, reaching up to 38%.
On the linting side, moving to Oxlint, we saw a whopping average of 71% reduction and reaching up to 97% reduction.
This is just the beginning for these tools. Rolldown is still in development, but is already being heavily tested by the community, and Oxlint is in beta right now. There are many more improvements planned for both tools.
This is truly amazing: we are not talking about refactoring our code or spending time understanding and trying to fit new tools. We are talking about drop-in replacements that could give us a 64% reduction in a CI pipeline (referring to only build + linting).
Given around 100 projects, an average of 600 commits per year per project, each one building and linting each time. We are talking about 500 hours saved per year, almost 21 days. Excluding the machine cost, since it is hard to calculate, we can imagine the engineering cost, both in productivity, focus, and just being able to enter the flow without hiccups.
Related articles

Tiago Afonso
Why Better Data Starts with Better Questions: Insights from the World Data Summit
In a world where "more" is often mistaken for "better", the World Data Summit served as a powerful reminder that when it comes to data, quality always trumps quantity.
Jul 16, 2025

Joana Coelho, Margarida Costa
From Dev-Metal to Green IT: JNation Through a Backend Lens
What happens when you mix high-performance software, environmental sustainability, and a dose of metal music? You get JNation 2025 and the experience left a mark.
Jul 11, 2025

André Félix
What Spring I/O Gave Us About Modern Software, AI, and Rethinking Architecture
When it comes to building scalable, resilient, and future-ready software, the answers aren’t always where we expect them. That’s what Spring I/O 2025 reminded us, and for our Backend Engineer André Félix, it was both an inspiring and grounding experience.
Jul 4, 2025