NPM and Left-Pad: Have We Forgotten How to Program?

five.js was missing something. I fixed it. https://github.com/jackdcrawford/five/pull/234

It must be one of: Elm, Purescript, GHSJS, Faye or Haste

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.

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.

I think most software developers' gut responses are that something is wrong and crazy in the npm ecosystem.

That said, there are benefits that this blog post and others aren't mentioning, related to the javascript situation specifically.

The first one is that javascript is a surprisingly difficult language to get right. Sure, the final solution is only a few lines, but which 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.

The comments in the blog post are illustrative:

One line of code package:

    return toString.call(arr) == '[object Array]';

Crazy right? And my first stab probably wouldn't have been to implement it that way. Why not:

    (testvar.constructor === Array)

that a commenter suggested, which should be faster? Well another commenter said:

    The constructor comparison will fail if the array comes from a different context (window).

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.

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.

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.

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.

So pros and cons.

    Small modules are easy to reason about

They really aren't, when I'm reading is-positive-integer(x) and wonder if 0 is positive I need to hunt down the definition of positive through two packages and as many files. And it gets wrose if both your code and one of your dependencies required 'is-positive-integer' and I have to also figure out which version each part of the code base is using.

If you had written (x > 0) I would have known immediately, it also wouldn't be doing the same thing as is-positive-integer(x) but how many calls to is-positive-integer are actually correct in all the corner cases that is-positive-integer covers?

And then there's the other problem with dependencies: you are trusting some unknown internet person to not push a minor version that breaks your build because you and Dr. is-positive-integer had different definitions of 'backwards compatibility'.

You're mixing up development time & bandwidth used by client browser. I was addressing the latter. Not having to download a 500 kilobyte library in order to use a single function is a big reason why the node.js ecosystem is the way it is today. Yet it is completely unaccounted for in the article. The author did not go into how the Node.js community came about to this practice in the first place, before going on a rant about it. That is what I was criticising. Whether having minimal modules maximises utility in society is completely irrelevant, because I was addressing perspective and etiquette.

You are a troll because talking about the actual number I used and how good a grasp I have in my mind completely misses the point. You're criticising the javascript ecosystem, I get that, but you completely missed the point of my comment. If you're not going to try to understand how Node.js conventions came to be, what it's strengths and weaknesses are, what the trade-offs made were, then it's inappropriate to focus on particular weaknesses of its practices.

It's like going on about how Objective-C development sucks because it's hard to do on Linux. But you're missing the point about what Objective-C's strengths are that attracted Objective-C developers in the first place.

The author should spend some time acclimating to Node.js best practices before writing this article. And you should do the same before you start knocking down straw men to prove how right you are.