I was really tempted to title this article “Boilerplate Fatigue.” Then maybe, it would’ve been more popular. But honestly, I think we’ve all had enough “fatigue” to last a lifetime.
This post starts with a common question:
I’m starting a project in React. Which boilerplate should I use?
The React ecosystem is complicated. There are a lot of moving parts. Nobody can deny this.
And yet, it is surmountable. You can learn all the pieces.
At the same time, most tutorials lead you to believe you actually NEED all those pieces before you even write the first line of code. It’s not true.
Since there’s so much complexity, many people decide it’d be best to outsource all those decisions to someone who knows what they’re doing: someone who made a boilerplate project. In theory, choosing a boilerplate gives you all that project setup “for free.” The reality is that those complex moving parts become your own problem as soon as you want to add something or upgrade a build library.
On Failure
We programmers have don’t like to do things that might fail.
It’s funny. There are all sorts of mantras about avoiding perfection. “Fail fast”, “The perfect is the enemy of the good”, and all the rest.
But then you have to start a new project, and what happens?
“Well I can’t just choose a library without vetting it first! That would be crazy!”
So instead of writing any code, for fear of “doing it wrong” or having to throw it all away, many of us will spend days or even weeks researching libraries and dependencies and tools. Reading tutorials. Watching videos.
But actually? Just using Create React App would’ve got you started on day 1.
It’s a justifiable fear: “how will I handle situation X?” … Where X could be AJAX, routing, dependency injection, tests, linting, deploying to production, or any number of other things.
But this fear is a feeling. I will be straight with you: you need to push past it and write some damn code. The world will not implode. You do not need a perfect cathedral of libraries to build your app.
And for the record…
Let me assure you that React and its ecosystem have answers for every one of: AJAX/HTTP requests, routing, dependency injection, tests, linting, deploying to production, data flow, large numbers of components, massive tables full of data, and much more. You won’t hit a wall on day 37 of your project because React or its ecosystem is lacking a certain capability.
Sometimes, I yearn for the good old blink tag. I would make that paragraph blink.
Back to Boilerplates
…and back to the point: you do not need to start with a boilerplate project. In fact, you should not use a boilerplate if you are starting out with React.
What should you do instead? Use Create React App. It’s easy, and it’ll actually work quite well for your project as it grows.
Using a boilerplate is like buying a $2000 guitar and a stack of amps with a stage-ready audio chain before you try to play any notes. You may think all that gear is going to help you play great… that it’ll help you skip the part where you make mistakes and suck.
Nope. It’s more likely to make you give up entirely because you can’t figure out how all the pieces work. Just the presence of all that extra stuff weighs down your mind because you feel compelled to figure out how all of it works before you even start.
So: use Create React App.
Then follow a straightforward guide that starts with just React. You might like to read a Timeline for Learning React and How To Learn React (and what to build along the way). There are also countless tutorials out there, but it can take a lot of time to sift through the noise. Egghead.io has a number of good ones.
That is all.
You Don't Need a Boilerplate was originally published by Dave Ceddia at Angularity on December 05, 2016.
CodeProject
