You want to build the front end for a simple web app and next thing you know you’re worrying about React, Redux, Thunk, Babel, ES6, Flow, Browserify, BrowserSync, Gulp, SASS, Radium, Karma, Jasmine and Nightwatch.js (for example).
Instead, having recently struggled with this problem myself, I would like to teach you how not to build a shed.
How not to build a shed
Disclaimer: I have never built a shed
When building a shed, you do not need large amounts of scaffolding.
You do not need a crane (2017 edition or otherwise).
You don’t even need a modern slick delivery pipeline that will automatically ship in your raw materials as you need them with the shiniest modern cool trucks.
In fact, these things are not just overkill, they will actually get in the way. You’ll be knee-deep in your crane’s instruction manual long after you could have already finished building your little shed.
The same applies to building with JS.
Those who are starting out, aren’t building rockets or skyscrapers; we’re building sheds. And so the question is, how much scaffolding do you need for that?
It can be tempting to err on the side of caution and just include all the things. Scaffolding generators (e.g. Yeoman) make it really easy for us to do this from day one, however this is often unhelpful*. The result is often a bloated project which is difficult to get started on. In my experience having too much stuff in a project is more destructive than not having enough.
*As much as I love them, I’d suggest holding off on scaffolding generators until you have a good idea about what you need.
Add your scaffolding as you need it
Try and start building your shed with the absolute minimum tooling. You’ll make quick progress and the shed will probably fall over, but that’s OK.
This gives you time to get to know the tools you’re using and help you understand what you need to do to stop it falling over in future. Then, add your extra tooling as you need it. Rinse, repeat.
For example, it can be difficult to know if/when to include flux (redux or otherwise).
To quote Pete Hunt, one of the early React guys:
You’ll know when you need Flux. If you aren’t sure if you need it, you don’t need it
And, in response to that, Dan Abramov, creator of Redux:
I would like to amend this: don’t use Redux until you have problems with vanilla React.
I think both guys appreciate that, especially for beginners, more harm can be done than good by just using it for the sake of it.
For example, not a fan of TypeScript, Browserify or inline styling? No worries, take something else for a spin.
Useful tip #1: Be mindful of what problems have already been solved
When trendy developers namedrop the latest nounJS, ask why it’s needed and make a note of it. You may well find it useful in future. Even if you don’t start out by using redux, it is useful to know what problem it solves. That way when you hit that problem you don’t reinvent the wheel (or give up trying).
Useful tip #2: Reference project templates and starter kits
When adding scaffolding as you need it, you don’t want to spend to much time manually configuring your infrastructure. If you find your wheels are spinning, reference some of the many awesome template for your stack. Then shamelessly steal from them. These are made by some clever guys, who might help you learn some best practices in the process.
Wrapping it up
Check out Pete Hunt’s awesome guide (here) on how to get to grips with React and friends, in an iterative manner. Crucially:
“Only move to the next step if you have a problem that needs to be solved.”
HN discussion here: https://news.ycombinator.com/item?id=12677640
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!