Notes from a room of sixty developers arguing about build steps
Two hours, one unfair question, and a split that ran along what people build rather than how long they have been building it. The arguments that held up.
The question on the whiteboard was deliberately unfair: when did shipping a web page start requiring a build step? Sixty people, a projector nobody used after the first ten minutes, and two hours that produced less consensus and more useful disagreement than any talk we have hosted.
These are the notes, reordered for sense and stripped of the parts where three conversations happened at once.
The room split, and not where we expected
The obvious fault line would be experience — veterans nostalgic for a single script tag, newer developers who have never shipped without a bundler. That is not what happened. The split ran along what people build. Developers working on long-lived applications with many contributors defended tooling almost without reservation. Developers building small sites, internal tools, and things they maintain alone were the ones asking why a landing page needs a dependency graph. Both groups were describing their actual constraints accurately. They were simply not describing the same job.The arguments that held up
"The build step is a team feature"
Made by someone maintaining a codebase with thirty contributors, and unanswered all evening. Modules, types, and a formatter are not there to make one developer faster. They exist so that thirty people writing simultaneously produce something coherent. Solo, that machinery is overhead; at thirty, it is the only reason the project is navigable."You are choosing which cost to pay"
The most clarifying framing of the night. No build step means paying at runtime — more requests, more work in the browser, less dead code eliminated. A build step means paying at development time — install time, configuration, an extra thing that can break at three in the morning. Neither is free. The mistake is believing one of them is."Most of the tooling is now optional and nobody noticed"
A quieter point that landed hard. Modules load natively. Modern CSS handles most of what a preprocessor was for. Browsers converged years ago. A lot of build configuration is inherited from a period when it was genuinely required, carried forward because nobody has been paid to remove it.Somebody asked how many people had tried deleting their bundler config to see what still worked. Four hands out of sixty. Three of those four said the answer surprised them.
The arguments that did not survive contact
"Tooling is why juniors struggle." The juniors present pushed back hardest on this. Their difficulty was not webpack; it was the seventeen ways to do the same thing and no signal about which one this codebase had chosen. Undocumented convention, not configuration. "Just use the platform." Popular in the abstract, thin in specifics. Asked how they would ship a typed, tested, multi-page application with a dozen contributors and no build step, the people making it did not have an answer they were willing to defend past the second follow-up. "It is faster now, so the debate is over." Faster tools removed the waiting, which was the complaint people voiced most loudly. It did not remove the configuration, the dependency surface, or the failure modes — the things they complain about second.What we took away
- Ask what the tool is for before defending it. Most build arguments are two people describing different projects at each other.
- Try deleting it. The exercise is cheap, reversible, and consistently surprising. Several people left planning to.
- Document the choice, not just the config. A short note explaining why this project builds the way it does is worth more to a new contributor than any amount of tuning.
- Complexity you chose is different from complexity you inherited. Almost nobody in the room could explain every line of their own configuration, and nobody found that comfortable.
