Are build tools an anti-pattern?

A few weeks ago, I wrote about parallel vs. waterfall downloads, their impact on performance, and why I think build tools still have their place.

However, a thread on Mastodon from Blake Watson has me questioning my opinion on this…

The worst part of this is that the web platform is probably one of the most backward compatible runtimes in the history of computing. You can take some HTML/CSS/JS from 20 years ago and it will probably run just fine in a modern browser now. Build steps ruin this.

If you build a web application with no build steps, you could pick up working on that project a decade from now and not have to worry about not being able to work because of compatibility issues.

There has really never been a better time to ditch build steps. CSS is awesome now. It has variables. It has nesting (maybe not everywhere yet but still).

Code organization? Modern browsers support ES modules, so it’s not like you need one gigantic bundle.

I recently ran into this in action.

I was working on some code for a client project, and it had grown pretty big in size. The CSS file was several hundred lines. The JavaScript include some nested waterfall downloads.

So, I added a build step.

It maybe improved performance a little bit, but it had another, unexpected side-effect. When the designer on the team, who also writes CSS, went to go make changes, it was a lot harder for them to implement them.

They had to figure out which file to look in, open up command line, run a build step, check that it worked as expected, and then deploy the code.

The build tools themselves also introduce an additional maintenance issue and breaking point.

I’ve kept them as lean and lightweight as possible, but I sometimes question if the project is actually better served with a build step or not.