There's nuance to the discussion that both sides are missing. People argue forcefully whether these small modules are good or bad, but I'm not seeing much evidence that they understand the other side.<p>First: why small modules are bad. Lots of dependencies complicate your build, and you end up with the dreaded diamond dependency issue. Failures in a dependency become more likely to affect you. It gets you in the habit of using prebuilt modules even if maybe it's not quite what you need and it would have been better to write yourself. With `npm` specifically, we've seen how its mutability can break the build, though that's about `npm` and not the idea necessarily.<p>I think most software developers' gut responses are that something is wrong and crazy in the npm ecosystem.<p>That said, there are benefits that this blog post and others aren't mentioning, related to the javascript situation specifically.<p>The first one is that javascript is a surprisingly difficult language to get <i>right</i>. Sure, the final solution is only a few lines, but <i>which</i> lines are hard. You have to navigate the mindfield that are is V8 in nodejs, v8 in chrome, spidermonkey, chakra, etc. I've had code work in Chrome before but blow up in IE, and it's really hard to track down and test.<p>The comments in the blog post are illustrative:<p>One line of code package:<p><pre><code> return toString.call(arr) == '[object Array]';
</code></pre>
Crazy right? And my first stab probably wouldn't have been to implement it that way. Why not:<p><pre><code> (testvar.constructor === Array)
</code></pre>
that a commenter suggested, which should be faster? Well another commenter said:<p><pre><code> The constructor comparison will fail if the array comes from a different context (window).
</code></pre>
I've run into issues before with cross-browser compatibility stuff, and it's frustrating and hard to test. If there's some de facto standard package that implements it for you, hopefully the community can iron out edge cases.<p>The other thing that people don't bring up, is that there's not much JS standard library, and in the browser context you have to send all your code to the front end.<p>So maybe you write these 11 lines yourself, and then another package writes these 11 lines, and another... it adds up. But if everyone uses the same package, the code only gets sent once and they all share it.<p>Lastly, people talk about how `sin` should be a part of a "trigonometry" package and not by itself. Well, again you're faced with sending a bunch of unnecessary code to the frontend. With webpack2 and tree shaking, or e.g. Google's Closure compiler, it can strip out dead code and so this issue will go away in the future, but we're not quite there yet. So package authors still bundle all these things separately.<p>So pros and cons.