Do we still need build tools?Jul 3, 2026<br>Do we still need build tools?

How necessary are build tools for frontend development in 2026? Let’s take a look.

Do we still need build tools for CSS?

Prefixes

Autoprefixer, esbuild and Lightning CSS can automatically add vendor prefixes to CSS. This week, Autoprefixer was downloaded from NPM 49,587,933 times. If your codebase doesn’t include the stretch keyword, user-select, or box-decoration-break, there’s no reason to use a prefixing tool. There are other properties, values and selectors that require a prefix, but because they don’t have a standard equivalent, they have to be written manually: e.g. -webkit-text-stroke, -webkit-text-fill-color, -webkit-line-clamp and ::-webkit-scrollbar. If you write text-stroke in your CSS, for example, tools like Autoprefixer won’t add the -webkit prefix because text-stroke is not a standardised CSS property.

Unprefixing user-select is part of Interop 2026 so will happen at some point this year.

Syntax lowering

“Syntax lowering” means taking modern CSS and transforming it to be compatible with older browsers. PostCSS was first to offer this functionality, and has been followed by esbuild and Lightning CSS (which is used by Bun, Rspack and Turbopack).

The lowered features differ slightly between tools but can include:

modern colors like lab(), lch(), oklab(), oklch(), color(), hwb(), hex colors with alpha and modern RGB/HSL syntax.

color-mix()

the inset shorthand

nesting

gradient interpolation

light-dark()

logical properties

system-ui font

Match functions like round(), mod(), cos(), tan(), pow() etc

These features are either baseline widely available already (meaning they have been supported by all browsers for at least two and a half years), or will become so later this year. Some, like inset and the system-ui value for font-family, have been supported for far longer.

Syntax lowering comes with severe caveats. While a simple shorthand property like inset can be easily transformed into longhand, the full functionality of a feature like light-dark() cannot be emulated with any fidelity. There is rarely a way for a build tool to make a new CSS feature “just work” in exactly the same way it works in the latest browsers. Pretending to use a feature, while the output code is something very different, can end up being more confusing than helpful. And having a disconnect between what’s in your authored code and what shows up in devtools makes debugging harder.

Preprocessors: Sass and Less

Sass was once a wildly popular tool but has mostly fallen out of favour as its best features have been adopted into CSS, often in an improved form. That started with CSS custom properties and continued with nesting. Nesting has been supported by all browsers since 2023. CSS color functions like alpha(), color-mix() and CSS relative color are improvements over Sass color functions. Sass has deprecated its own if() function in favor of the official CSS if() syntax. Chrome has shipped if() and @function and it’s possible those features will gain broader browser support in the future. There’s also a CSS spec for mixins which is currently being implemented in Chromium by the Microsoft Edge team.

@import bundling

Tools like esbuild, PostCSS Bundler, postcss-import, and Lightning CSS can combine CSS files referenced by @import into a single .css output file. Similarly, Sass has its own unique way to combine multiple .scss files into a single .css file. If you’re authoring more than a handful of CSS files, combining them together is one build step that will remain highly recommended.

In a no-build project, every CSS file you author needs its own CSS @import statement or a link tag — meaning each file is a separate HTTP request. David Heinemeier Hansson, the creator of Ruby on Rails, has been one of the few high-profile public advocates of a pure no-build approach to frontend development. On Hey.com, developed by DHH’s company, there are 147 elements in the of the document. The site isn’t slow. It achieves 94 on a Lighthouse performance test, but its a difficult practice to justify at such a scale and certainly isn’t optimal.

ONCE #1 is completely #NoBuild for the front-end. No bundling, no transpiling, no nothing. Just individual, vanilla CSS and JavaScripts served over HTTP/2. It's amazingly light and amazingly fast with exquisite cache expiration dynamics. Bliss to develop for too! pic.twitter.com/BdBFX9BkXW<br>— DHH (@dhh) December 18, 2023

Jake Archibald has written about the compression benefits of combining resources:

A big part of gzip and brotli compression involves back-references, eg “the next 50 bytes are the same as this bit earlier in the resource”. That can only happen in a single resource, so compressing lots of small resources is less efficient than compressing one combined resource.

Minification

Minification strips out comments and whitespace. Minification of CSS remains a best practice.

Do we still need build tools...