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).

Smarter people than I have complained at great length about this, and so I will not.

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.

The JavaScript universe makes it easy to plug in new tools and switch out parts of your stack. Use that to your advantage! You don’t need to buy into a monolithic opinionated methodology.

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: