The Controversial State of JavaScript Tooling
The problem with hypermodularization is that it takes time to make a decision on what module to use for every task. If you have to to do this with 100s of modules, you&#x27;re wasting a lot of valuable time.<p>Does anybody know a quick way of making the right decision?<p>NPM is like a crowded graveyard nowadays (or like .com domain names - where all of the good module names have been taken along time ago and now all the best practice modules have completely irrelevant names). There are thousands of buggy modules in which development has stalled, and it&#x27;s easy to waste a lot of time trying to separate the wheat from the chaff. I personally sometimes have to open up 5+ Github repositories to check their last commit, number of contributors, interfaces, code quality, unanswered issues, etc. Only after doing so am I able to make a decision.<p>In terms of knowing what&#x27;s cutting-edge practice it seems you have to watch Twitter a lot and be careful not to follow every single bad idea.<p>I can&#x27;t imagine what it&#x27;ll be like to search for a module to handle something as common as config in a couple of years. Even when you constrain yourself to something like &#x27;12 factor config&#x27; there are many different implementations.<p>Don&#x27;t even get me started on the insane assembly required to get webpack-, babel-, cssmodules-, and postcss- to all work together.<p>The problem is only going to get worse.