Embracing Dependency Minimalism

As a javascript developer the sky never seems so bright, and life so full of potential, as in those moments when you have cause to type yarn init. A fresh project is redemption. It is the opportunity to cleanse yourself of all the terrible things you had to do to finish up the last project. "I will not code myself into THAT much of a corner again, no siree!", you think.

And then, you follow yarn init with:

yarn add react redux react-redux react-router react-router-redux 
react-redux-router-handler react-router-wrapper 
react-ui-router-wrapper-redux loads-of-unnecessary-abstractions
...etc

Whoa, what just happened here? It would appear, that we just destroyed our clean slate approach with a boatload of solutions for which you haven't found the problems.

Now, I hear what you are saying, that you used these patterns in past projects, so of course you are just anticipating these problems. To which I respond: No, it is just premature optimization. And really, that isn't quite right either. It is premature complication. Redux isn't even necessary (meaning: defensible) for all React apps, let alone all of the extra wrappers and add-ons the community has thrown up all over Github.

This is where my interpretation of "minimalism" comes in to help.

Goal:

Aim for the smallest possible footprint that still allows you to hit deadlines.

How:

• Don't install something until you genuinely need it.
• You don't genuinely need it unless you can successfully explain why to someone who doesn't use it.
• Be wary of "wrapper" libraries. They often obfuscate interfaces that you would be better off undertanding.
• Be wary of "stupid" libraries (left-pad, anyone?).

Why:

Understanding way more of your code base is a great reason to do almost anything. Also, on the front-end, performance should be a big consideration. If we are expecting people to load a javascript bundle of 2Mb and we are not serving them a pretty neat video game, we have failed.

Example:

When starting out building an HTTP API, you may know you have multiple URL's to support, with path and query params. Okay, add Express, because that will save you a lot of time, and it is a very well-established, well-focused library. That's one dependency, but I certainly needed it. Sure, I could have tried Koa, but async/await exists, so I don't need co, and async code looks great in Express. Also, Koa doesn't ship with routing, which would be like React shipping without a way to define div's. I also could have tried Hapi, but to be short, I don't need it. I don't have a problem with Express, so I won't fix it.

In summary, picking the right tools for the job is hard, but too many tools can hurt just as much as the wrong ones. Embracing minimalism, and a methodical approach to the adoption of outside technology can help make the right tools easier to identify