Have you ever made a pie? If you have, I’m sure you know the amount of detail & precision that goes into that perfect “from-scratch” recipe. Wait a couple minutes too long, and the crust burns. Use too much butter and your pie doesn’t have the right texture. Making a creme pie? If you get the measurements wrong your pie could end up as soup (been there, done that. At least it was a tasty mistake).

Makes you wonder why we say “easy as pie”, right?

One of the biggest complaints from people about the current JavaScript ecosystem is the state of the tooling. Starting a React project could require 1–3 days of setup to get everything working correctly. You’ve got transpilers, module bundlers, linters, formatters, test runners, etc.

Juggling all of these can feel very much like baking a pie — make one mistake, and you’re knee-deep in webpack internals trying to figure out why you can’t even get “Hello World” to show up.

Most of the front-end frameworks have CLIs or boilerplates to alleviate this pain, but conventional wisdom & a large number of blog posts would have you think that writing your own config will result in higher productivity down the road (because after all, you know how it works so you can customize as much as you want).

Most of the time, you simply just don’t need to write your own custom boilerplate.

A Couple Disclaimers 🙃

Software engineering is filled with tradeoffs, and the time spent working on tooling is no exception. There may be some cases where spending a bunch of time setting up your project actually does help in the long run. Before we get into details, I wanted to make these two disclaimers, lest anyone draw the wrong conclusions.

Learning tooling isn’t a waste of time. But it can be a large barrier to learning something new / delivering faster. There’s a lot of tiny choices that you will spend energy on, and each one of those choices wear you down a little. The good news is that webpack & the other build tools have amazing docs (for the most part), so you can usually get by with only touching configuration files when you actually need to.

But it can be a large barrier to learning something new / delivering faster. There’s a lot of tiny choices that you will spend energy on, and each one of those choices wear you down a little. The good news is that webpack & the other build tools have amazing docs (for the most part), so you can usually get by with only touching configuration files when you actually need to. You might need custom functionality, and that’s ok. I understand that some use cases merit a custom configuration built-from-scratch. But I would also argue that in many cases (especially side projects) these are the exception and not the rule. In addition, you can often build your custom functionality on top of an off-the-shelf solution.

Ok. Now that we’ve got that out of the way, let’s get into the why.

There’s a Lot of Good “Boilerplate Frameworks” Out There

For lots of apps, you can piggy-back off of the myriad of boilerplate & bootstrapping frameworks out there. In the React ecosystem, here’s 3 of the most popular.

Create-React-App (great for smaller projects & learning React! Also lets you “eject” & customize however you want) NextJS (server-rendering framework with a rich plugin ecosystem) Gatsby (static site generator built on React & GraphQL. Also has a lovely plugin ecosystem).

I use the term “boilerplate frameworks” to describe these type of frameworks/bootstrapping packages since they’re not boilerplates in the strictest since of the term. In a boilerplate, you’d typically have access to all of the generated/pre-populated code. However, they allow you to quickly bootstrap an app, fulfilling the initial purpose of a boilerplate.

All three of these “boilerplate frameworks” provide opinionated defaults while allowing options for developers to extend functionality. Before you go and spend a bunch of time writing your own config, see if one of these fits what you’re looking for (many times it will!). And if you need something one of these doesn’t provide, see if there’s a plugin (in the case of Gatsby / NextJS, Create-React-App doesn’t have plugin functionality). Building on top of one of these solutions or using a plugin with save you hours of setup time, meaning you can get your code out to users faster.

Remember That If You Write Your Own Config, You Will Have to Maintain It.

A lot of these boilerplate frameworks will regularly release updates with security & dependency updates. If your app is built on top of it, you’ll get these for free (and often painlessly).

Writing your own configuration is a two-edged sword — you get to update it any time you want. You don’t have to wait on open source contributions or for the next release. You can change things today.

However, when your build pipeline is breaking, you alone have to fix it. When one of your dependencies needs to be updated & that update breaks your build system, you have to dig into the config & debug your tools.

Just remember that any time spent debugging your tools is time that you could have spent writing the code that makes your apps unique.

Last Thoughts

A big thanks to Kyle Holmberg for the phrase “Friends Don’t Let Friends Write React Boilerplate”. He’s also doing frontend web engineering at AutoGravity, making car financing an easy (dare I say fun) digital experience. 👌🏻

At the end of the day, writing software should be focused on the end users. If that extra time spent on your own config benefits them, go for it. But if your app could be done on top of a “boilerplate framework” save yourself some time & effort — focus instead on delivering an awesome user experience.