Boilerplates vs. frameworks

The other day, I wrote…

As a general rule, I prefer boilerplates over frameworks, because they start with some basics and let you layer in selectively over time.

Today, I wanted to talk about why I favor boilerplates.

Most frameworks are complete or mostly-complete systems. They have a preferred way of doing things, and deviation from that preferred approach is typically frowned upon and “punished” with a difficult developer experience.

They also often support an ecosystem of plugins or extensions that are designed to reinforce “the one right way” of doing things.

Often, the preferred approach encourages you to “just grab a plugin.” A common result is bloat, with more and more code getting thrown at a project to solve what would otherwise be really simple problems easily solved with a few lines of vanilla code.

By contrast, boilerplates are starting points rather than complete systems.

They’re often approach agnostic by design. Rather than forcing a “right” way on you, they’re simply a tool you can adapt to your needs as you see fit.

They typically do a very narrow set of things very well. If you need to solve a different problem, you’ll typically want to reach for a different tool. And when you do, you can usually bolt it into your existing boilerplate quite easily.

A natural result of these differences is that boilerplates often result in a bit more work up front, but a much more flexible build setup and lean code base over time.

Given the choice, I choose boilerplates every single chance I get.