37 ms·

This comes up a lot when people discuss anything related to npm modules. It's easy to simply dismiss these trivial one-line modules as "insanity" and move on, b

This comes up a lot when people discuss anything related to npm modules. It's easy to simply dismiss these trivial one-line modules as "insanity" and move on, but there's actually plenty of good reasons as to why many prefer to work with multiple small modules in this manner. This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328 https://github.com/sindresorhus/ama/issues/10#issuecomment-1... TL;DR: Small modules are easy to reason about, and encourage code reuse and sharing across the entire community. This allows these small modules to get a tremendous amount of real world testing under all sorts of use cases, which can uncover many corner cases that an alternative naive inlined solution would never have covered (until it shows up as a bug in production). The entire community benefits from the collective testing and improvements made to these modules. I also wanted to add that widespread use of these small modules over inlining everything makes the new module-level tree-shaking algorithms (that have been gaining traction since the advent of ES6 modules) much more effective in reducing overall code size, which is an important consideration in production web applications.

wodencafe 11y ago
But this doesn't address the author's point that each module, each dependency is an additional point of failure.
- lewisl9029 11y ago
  There are definitely trade-offs involved when making decisions to inline vs import. Strictly speaking, you're definitely right. Each dependency is an additional point of failure, but so is each additional line of code you inline. The benefits of these small modules is that they're very thoroughly tested by the entire community. I'd say for most cases, they will be much more robust than any solution an individual developer can spontaneously whip up. Of course, these modules don't exist in a vacuum, and infrastructure failures such as this one do pose another point of failure you wouldn't have with inlining code, but I think in this particular case it had more to do with the failure of npm to adhere to package management best practices to not include an unpublish feature.
  - coldtea 11y ago
    >There are definitely trade-offs involved when making decisions to inline vs import. If someone can't make the right trade-off regarding "should I import a module called "isArray" or "is-positive-integer", then they should not be programming...
    - lmm 11y ago
      Yep. Everyone mocking NPM and the javascript community for this ought to retire, they clearly don't understand how to program in this day and age. Or is that not what you meant?
    - robmcm 11y ago
      I think a lot of the confusion here is that in most languages "isArray" or "is-positive-integer" are simple functions of simply build into the language. Dynamic typing and diversity of devices and virtual machines mean the ability to simple tell if something is an Array could be multiple lines of code that could take a considerable amount of time to test. Delegating this to the community is arguably the only sane choice, however strange that may be to someone come from another environment.
kbenson 11y ago
The simple rebuttal to that is that modules that are collections of small functions are easy to reason about as well, and don't the downside of increasing the metadata management to useful function ratio nearly as much. Why have just an average (mean) function, when it makes sense to provide a median and mode as well? Even then, you might find that there's a bunch of extra math operations that are useful, and you might want to include some of those.
- lewisl9029 11y ago
  With the advent of ES6 modules's selective imports and tree-shaking, that's definitely quickly becoming a better approach. With the old CommonJS modules, you need to be concerned about overall code size, which is where small, single purpose modules excel, and why this approach has proliferated to this degree.
  - rubber_duck 11y ago
    Doea code size really matter to node.js ? And how common was commonjs (no pun intended) on the client before ES6 ? Also doesn't commonjs bundling add a significant overhead when talking 5 line function modules ?
    - lewisl9029 11y ago
      Quite common actually (see Browserify)! In fact, the increasingly widespread use of npm and CommonJS on the client is one of the factors that motivated the npm team to transition to flat, auto-deduplicated modules in version 3.
    - sillysaurus3 11y ago
      There is little reason to bundle node.js code. It's an optimization, and a dubious one. In my experience, speed of execution isn't impacted at all. I haven't tested the memory footprint, but it seems vanishingly unlikely that dead code elimination would have any substantial effect. There's probably not any overhead in bundling, though. Not in speed or memory, at least. The overhead is in the complexity: the programmer now has one more place to check for faults, and debugging stack traces now point to a bundled version of code instead of the original sources. The case where none of this is true is when require() ends up being called thousands of times. Startup time will be correspondingly slow, and bundling is the cure. But that should only be done as a last resort, not a preemptive measure.
idlewan 11y ago
You'd have a good point, if all of those tiny but probably useful modules were given the use you're describing. Discoverability though is so poor that most of those modules are most likely just used by the author and the author's co-workers. If a typical npm user writes hundreds of packages, how the hell am I supposed to make use of them, when I can't even find them? Npm's search is horrendous, and is far from useful when trying to get to "the best/most supported module that does X" (assuming that random programmers rely on popularity to make their choice, which in itself is another problem...).
- foobarian 11y ago
  Another benefit of small well understood components is that they are easier to write tests for. Do these npm modules have good test coverage? Did the leftpad module have a unit test that would have caught the issue?
  - lugg 11y ago
    which issue? I thought we were talking about the random removal of left-pad and a couple hundred others.
  - zachrose 11y ago
    No, leftpad has four test cases and they are all obvious, given the leftpad API. Would I write tests for my own leftpad implementation if I were not farming it out to a dependency? Its possible. More likely I would want to understand the intent behind using leftpad in my application or library, and have test for "formatTicket" or whatever it is that I'm actually doing. But for all the talk about tiny modules that cover surprisingly tricky edge cases, this is not one of them.
- lewisl9029 11y ago
  You're totally right. Most developers don't develop this way, and that makes the benefits of this approach far less pronounced than they would be if they did. It also doesn't negate the benefits entirely, of course.
- jt2190 11y ago
joe_the_user 11y ago
I don't see how your linked comment brings more to the table than the basic arguments for code reuse. But naturally, with any code reuse there's a benefit and a cost to instance of internal or external reuse. The Benefits for external reuse include ideal reliability as your describe as well as not having to create the code. The costs for external reuse include having your code tied to not just an external object but also the individuals and organizations creating that object. I think that means that unless someone takes their hundreds of modules from the same person or organization and is capable of monitoring that person, that someone is incorporating a layer of risk to their code that they don't anticipate at all.
memracom 11y ago
They do NOT encourage code re-use because the effort required to understand your need, refrain from writing code, and hunt down a module in npm, far outweighs the effort to just write the code and stick it in your in-house utils library.
- jay_kyburz 11y ago
  Yeah but, why do you need your own in-house utils library. Node needs batteries included!
  - mikekchar 11y ago
    Because writing code is what programmers (should) do. If something is simple, then it is simple and won't take up time and energy. If you don't know how to do it, then learning how to do it is worthwhile -- especially if it turns out to be simple. If you make a mistake, then someone on the team must look at the code and understand the mistake. This means that the team learns that things that seem simple are sometimes complex and they learn how to recognise their mistakes. When there is a mistake, someone has to fix that mistake. They learn how to fix the problem. Other people on the team must review that fix and they also learn how to fix the problem. There is always a balance between getting some extra productivity by using somebody else's code, or getting the knowledge, expertise and control of writing it yourself. Far too often I see young programmer's choose something off the shelf so that they don't have to understand it. This is a recipe for disaster -- for your project, for your team and for yourself. IMHO, as programmers, we should err on the side of writing code. Often it is obvious that you should use standard libraries, or a particular framework or or another reuse library. But where it is not really obvious, I would start with writing your own code and see where it gets you. You can always replace it later if it doesn't work out. I think you will find that you and your team will be miles ahead if you take this approach.
    - andy9775 11y ago
      Never understood the fun in importing everything and chaining together someone else's code. Sometimes if I'm building something trivial, a bit of test code or something for fun I'll write up all of it, even if I have to reference others code. You learn so much more.
fieryeagle 11y ago
Just sugar-coated kool aid I'm hearing. Community benefits? First of all, I'm coding to get paid and this recent madness proved that JS ecosystem is semi-garbage. Back to the original question - do people really can't program that they need packages like left-pad or is-integer which had their own dependencies? Before writing those cool toolchains (which would likely work in a specific machine with a specific setting with all the real world testing the community has) can we at least pretend that we know the computer science basics?
- johnny22 11y ago
  if leftpad were in the node stdlib, would you still be making the same point about knowing computer science and using leftpad? in python: https://docs.python.org/3.3/library/stdtypes.html#str.ljust https://docs.python.org/3.3/library/stdtypes.html#str.ljust
  - fieryeagle 11y ago
    Yes, until people stopped publishing isInteger and isArray as `packages`. Plus, stdlib is standard library. Can you cite one for JS? NPM is not.
- usrusr 11y ago
  People need modules like leftpad to tick the "maintains moderately popular open source project" checkbox. Instant hirability. I don't want to claim that it would be a directly calculated career move, more like starting a blog: you admire a good blog, you want to be more like the blogger, you start your own one. On the dim chance that it will become both good and not abandoned after the third post. Nanomodules can be just like that, the air guitar of would-be rockstar coders. This is certainly not the only reason for their existence (and even the air-guitar aspect has a positive: low barrier of entry that might lead to more serious contribution), but the discussion would be incomplete if it was ignored.
  - spenuke 11y ago
    Yep, I think this is a huge, HUGE part of it. Step 1: Create a culture in which "having open source contributions" is a requirement to entering said culture. Step 2: Remove all friction from introducing open source contributions into the culture. Step 3: Watch the Cambrian explosion. Step 4: (Two years later) Point to the Cambrian collapse and how the new hot thing will solve everything. I don't know what sort of shit show Step 4 will turn into, but it will also definitely be the result of folks taking a simple and good rule of thumb (this time, it won't be "small and composable"), and implementing it without ever stopping to think what problems it solves and doesn't solve.
userbinator 11y ago
Small modules are easy to reason about Yes they are, in the same way that a book in which every page consists of a single word is easier to understand than one with more content per page. By focusing on the small-scale complexity to such an extreme, you've managed to make the whole system much harder to understand, and understanding the big picture is vital to things like debugging and making systems which are efficient overall. IMHO this hyperabstraction and hypermodularisation (I just made these terms up, but I think they should be used more) is a symptom of a community that has mainly abandoned real thought and replaced it with dogmatic cargo-cult adherence to "best practices" which they think will somehow magically make their software awesome if taken to extremes. It's easy to see how advice like "keep functions short" and "don't implement anything yourself" could lead to such absurdity when taken to their logical conclusions. The same mentality with "more OOP is better" is what lead to Enterprise Java. Related article that explains this phenomenon in more detail: http://countercomplex.blogspot.ca/2014/08/the-resource-leak-bug-of-our.html http://countercomplex.blogspot.ca/2014/08/the-resource-leak-...
- lewisl9029 11y ago
  > Yes they are, in the same way that a book in which every page consists of a single word is easier to understand than one with more content per page. A more apt metaphor would be separating a book into many small paragraphs that each serves a single purpose makes the book easier to understand. Regardless, the book metaphor misses a lot of the nuance. Of course taking the approach to an extreme would be detrimental. However, a vast majority of these small modules that are actually widely used consist of functions that may seem trivial at first sight, but actually contain a lot of corner cases and special considerations that a naive inline implementation could miss. Sure, there are also plenty of trivial one-line modules on npm that don't fit into a such a description, but those are simply side effects of the unprecedented popularity of the platform and its completely open nature, and shouldn't be used to infer any kind of general trend towards "hypermodularisation" because very few reasonable developers would ever import them into their projects.
  - simula67 11y ago
    > A more apt metaphor would be separating a book into many small paragraphs that each serves a single purpose makes the book easier to understand No, that would not be an apt metaphor for the problem he is describing. > Regardless, the book metaphor misses a lot of the nuance. Not if you are trying to understand the point he is trying to make. Is there any cost to creating modules, uploading them to npm and using them in other projects ? Clearly there is, as is shown by the world-wide breakage from yesterday. This is probably only one of such failure modes. The point is, breaking everything into micro-modules can have benefits and costs. Ultimately, it is an engineering trade-off. Now, it is possible that npm modules are at the right level of abstraction, even though other module systems in the world are not this granular. If this is due to the special nature of JavaScript then the point must be argued from that perspective.
coldtea 11y ago
>TL;DR: Small modules are easy to reason about, and encourage code reuse and sharing across the entire community. How does that even remotely applies to the "is positive integer" test, and even more so to "it's positive" and "it's integer"? What's next? is-bigger-than-5? word-starts-with-capital-letter? add-1-to-a-number?
- userbinator 11y ago
  add-1-to-a-number This seems to be a very common example in educational materials about how to create a function in some programming language. Perhaps they should all be prefaced with "NOTE: you should not actually make such a function, because its triviality means that every time you use it you will be increasing the complexity of your code", or a longer discussion on when abstraction in general is appropriate and when it is not. Ditto for any other abstraction --- I've found there's too much of an "abstraction is good so use it whenever you can" theme in a lot of programming/software design books and not enough "why abstraction can be bad" sort of discussion, which then leads to the "you can never have too much" mentality and the resultant explosion of monstrous complexity. Apparently, trusting the reader to think about the negatives and exercise discretion didn't work so well...
  - Stratoscope 11y ago
    > Apparently, trusting the reader to think about the negatives and exercise discretion didn't work so well... That's the whole point. If you use is-positive-integer, you won't have to think about the negatives!
- n0us 11y ago
  No, you see "is-bigger-than-5" clearly does 4 different things. You need these modules: module.exports = exec("==="); module.exports = bigger(a, b){return a > b}; module.exports = () => return "than"; module.exports = (a) => a.search('ABCD...'); .. or something like that. These are all plugins of course.
  - deleted 11y ago
    [deleted]
masterleep 11y ago
That argument sounds like an enterprise architect explaining why the AbstractReusableBeanFactoryGenerator is going to increase productivity.
lsc 11y ago
My problem is one of productivity. There's already a standard library, and if it's a language I've been using for a while, I probably remember most of it. I can pretty much go straight from my thought of what I want done to typing it out, much like typing English. If you force a 'cache miss' and force me out of my head and into a documentation search, well, that's going to have a significant effect on my performance. If the function is well-named, it has less of a cost in reading the code, but there's still a cost, because what if it's slightly different? I have a pretty good feel for the gotchas in much of the standard library of the languages I use. I have to stop and check what the gotchas of your function are. Yes, at some point the complexity cost of gluing together the standard library functions to do something becomes greater than the lookup cost of finding a function that does what I want; but I am saying that adding more functions is not costless.
jdonaldson 11y ago
author of over 600 modules and 1200 lines of javascript.
- gone35 11y ago
  Wow, you were not kidding. I chose a random package of his [1], and indeed: a grand total of 1 LOC... This is madness. [1] https://github.com/sindresorhus/float-equal/blob/master/index.js https://github.com/sindresorhus/float-equal/blob/master/inde...
  - serge2k 11y ago
    and it uses another 1LOC package. https://github.com/sindresorhus/number-epsilon/blob/master/index.js https://github.com/sindresorhus/number-epsilon/blob/master/i... and no, the edge cases argument does not apply to either of them. Wow.
    - ricardobeat 11y ago
      Would you like to memorise that number yourself to use in your app?
      - wyattpeak 11y ago
        What memorise? How about this for a dependency: https://www.google.com.au/search?q=es6+epsilon https://www.google.com.au/search?q=es6+epsilon
        ricardobeat 11y ago
        That module exists precisely because this is a new addition to the language, it's a polyfill for backwards compatibility.
erik14th 11y ago
How is that superior to copypasting from a stackoverflow answer? If it's a popular issue, lots of people had the same issue, many will be nice enough to add their edge cases and make the answer better, most will not. Same goes for contributing to a package. With a package you would be able to update when someone adds an edge case, but it might break your existent code and that edge case may be something that is not particular to your system. If you don't want to get too deep in the issue, you can copy paste from SO, just the same you can just add a package. If you want to understand the problem, you can read the answers, comments, etc. With the package you rely on reading code, I don't know how well those small packages are documented but I wouldn't count on it. The only arguments that stands are code reuse and testability. But code reuse at the cost of the complexity the dependencies add, which IMO is not worth the time it'll take you to copy and paste some code from SO. Testability is cool but with an endless spiral of dependencies that quite often use one or more of the different (task|package|build) (managers|tools) that the node ecosystem has, I find it hard to justify adding a dependency for something trivial.
- rycfan 11y ago
  How is it superior? Simple. How do I systematically make sure that I have the latest version of every stackoverflow code snippet? If it's a new post, it may not have all the edge cases fixed yet. So now I have to check back on each of the X number of snippets I've copied. In the npm approach, I can easily tell if there's a new version. For prod, I can lock to a specific version, but in my test environment, I can use ^ to get newer versions and test those before I put them in production. If the edge case of new version of a package breaks my code, I've learned that I'm missing a unit test. Plus, the question isn't whether this bad thing might happen on occasion, the question is whether this approach is, on balance, superior to cutting and pasting random code snippets into my code. I think the downside of the npm approach is less than the downside of the copypasting from stackoverflow approach. And every moderately useful npm package I've looked at has very good to great documenation.
forgotpwtomain 11y ago
> This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/ama/issues/10#issuecomment-1.. https://github.com/sindresorhus/ama/issues/10#issuecomment-1.... If anything looking at sindresorhus's activity feed: (https://github.com/sindresorhus https://github.com/sindresorhus) perfectly supports the author's point. Maybe some people have so little to do that they can author or find a relevant package for every single ~10 line function they need to use in their code and then spend countless commits bumping project-versions and updating package.json files. I have no idea how they get work done though..
- Cut_N_Paste 11y ago
  I think the gist of this whole discussion ( at least the OMG WHY?!?! ) part, can be easily explained by an excerpt from your example comment that sums up in a nutshell the all too pervasive mindset I've seen over the years: "...LOC is pretty much irrelevant. It doesn't matter if the module is one line or hundreds. It's all about containing complexity. Think of node modules as lego blocks. You don't necessarily care about the details of how it's made. All you need to know is how to use the lego blocks to build your lego castle. By making small focused modules you can easily build large complex systems without having to know every single detail of how everything works..." By LOC he's referencing 'ye ole Lines of Code paradigm, and trying to make the point that in the end it just doesn't measure up to the prime directive of "containing complexity". ... and that's where I beg to differ. What I think is being completely overlooked here is the net cost of abstracting away all that complexity... It's performance. Every extra line of code, extraneous function call, unnecessary abstraction ( I'm looking at you promise ), every lazy inclusion of an entire library for the use of a shortcut to document.getElementById -- these all add unnecessary costs from the network down to the cpu. And who pays these costs? The end users of your slow, memory hogging, less-than-ideal set of instructions to the cpu that you call an application... but hey, it's easier for you, so there's that.
  - spion 11y ago
    Promise was clearly necessary, because without it we had hundreds of other less principled ways to implement async control flow :)
EdiX 11y ago
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'.
- ShellfishMeme 11y ago
  JS does not have an Integer type, so (x > 0) does not work. Now if you add all those checks necessary to see whether you're actually dealing with an integer here, you get to a point where you cannot be sure anymore whether there aren't any weird type coercion issues there and need to start writing tests. Suddenly your whole positive integer check took 1h to write and you still cannot be sure whether there's something you didn't think of. I'd rather use an external library for that that's properly unit tested.
  - EdiX 11y ago
    JS does not have an Integer type, so (x > 0) does not work It depends on what the surrounding code actually does wheter (x > 0) works or not. Depending on the version of is-positive-integer you are using a positive instance of the class Number may return true, false or cause an error. PS. never mind that the implementation of is-positive-integer is extremely inefficient.
  - minitech 11y ago
    A module doesn’t solve that kind of type confusion, though. Static typing does. The next best thing in JavaScript is passing consistent types of values to your functions, so just write function isPositiveInteger(x) { return x > 0 && Number.isInteger(x); } and always pass it a number. (Of course, this shouldn’t even be a function, because JavaScript is confused about the definition of “integer” – maybe you really want `x >>> 0 === x` – and apparently is-positive-integer is confused about the definition of “positive”, so it’ll be clearer to just put things inline.)
wiradikusuma 11y ago
Why dont they put everything together and call it "commons" like in Java? (commons-lang, commons-io, etc).
tmptmp 11y ago
it reminds an apt proverb: missing forest for the trees. Too many modules do not necessarily become a good thing. They may appear to get rid of complexity but in reality, you will have to face the complexity some level above and in fact, the sheer number of small modules will most probably add more complexity of themselves.
z3t4 11y ago
I agree with you, besides the tree-shaking (nice word btw). It's like NPM shaking the Christmas tree and then say "Have fun cleaning up the floor". Remember that NPM is not like apt-get, where the packages are Managed for you by an expert. In NPM you have to manage the packages! And where you can't have NPM and build dependencies, like in production, maintenance now becomes much harder!
avz 11y ago
> Small modules are easy to reason about Flip-side: it isn't easy to reason about a large and complicated graph of dependencies.
confusedjs 11y ago
I'm not at all clear why this blog post is touted as evidence that the tiny modules approach is correct. I think it might be all the people after it congratulating him. "It's all about containing complexity." - this completely ignores the complexity of maintaining dependencies. The more dependencies I have the more complicated my project is to maintain. Dependencies are pieces of software managed by separate entities. They have bugs and need updates. It's hard to keep up to date. When I update a piece of software I read the CHANGELOG, how am I expected to read the CHANGELOG for 1,000 packages? Depending on a bigger package (handled by the same entities, who write one changelog, in the same form) is more straight forward. I'm not saying this is wrong - but there's a balance here, and you must not ignore the complexity of increasing your number of dependencies. It does make things harder.
carlosnunez 11y ago
I get that author's point, but do you REALLY need a dependency module that tells you the type of something? That's not a Lego block; that's an excuse.
- ctolsen 11y ago
  When using a language where isArray(arr) turns into toString.call(arr) == '[object Array]' ...then I guess that's more reasonable than if you use something sane.
carlosnunez 11y ago
I get that author's point, but do you REALLY need a dependency module that tells you the type of something? That's not a Lego block; that's an excuse.
spoondan 11y ago
I think that there's a certain wishfulness bordering on naïveté to this pursuit. We tell ourselves that we are managing complexity by having small, well-tested units that are reused by an entire community. But software complexity continues to exist. We think we are mitigating the complexity of our own software. But the complexity really just shifts to the integration of components. Anyone that has been around long enough has war stories about getting two relatively simple pieces of software working with each other. In my experience, integration problems are often the most difficult to deal with.
calanya 11y ago
The alternative to small modules is not no modules at all, it's libraries.
ctolsen 11y ago
It's interesting to me that people find this convincing. I find it to be complete insanity. People need their libraries, but putting everything in tiny buckets is just not working. Why aren't people working on good utility libraries instead? There's even some guy calling for a "micro-lodash". To me, as a Python engineer, lodash [1] is already a tiny utility library. I guess it's also about the fact that JS is a pretty bad language. That you need a one-line `isArray` dependency to `toString.call(arr) == '[object Array]'` is crazy. [1] https://lodash.com/docs https://lodash.com/docs
- dysfunction 11y ago
  There is a practical reason for tiny modules in client-side JS that doesn't exist with Python: page load times. If your base layer is going to have third-party dependencies, they better be tiny and do only and exactly what you need. That said, lodash core is only 4KB, and lodash gives you the ability to build it with only the categories or exact functions you want, so I don't understand what the purpose of a "micro-lodash" would be.
  - ctolsen 11y ago
    There are tools to include only the stuff you actually use that you can stuff in your build process though.
deleted 11y ago
[deleted]
coleifer 11y ago
> author of over 600 modules on npm Nope.
yAnonymous 11y ago
The reasoning makes sense for small modules that might change in the future, but as he says himself, most of his modules are finished and will never change. That makes many arguments in his post moot and the modules should probably be snippets instead that are implemented directly.
endemic 11y ago
My problem with this, as an occasional JavaScript developer, is "discoverability" (as many others have mentioned). If I decide I need a left-pad function, and search on NPM, how do I choose which one is best? The one with the most downloads? Not always the best indicator of quality; perhaps it's just the oldest. Not to mention the cognitive overhead of stopping programming, going to NPM, searching/finding/installing the module, then reading the documentation to understand its API. Isn't it simpler to `while (str.length < endLength) str = padChar + str;`? How can there be a bug in that "alternative naive inlined solution"? Either it works or it doesn't!
jack9 11y ago
Small modules are also often the result of dealing with different javascript implementations over the years. I've recently seen a simpler version of the left pad that would not have worked on multiple Safari versions or <IE6 The derision is unwarranted, due to a failure in critical thinking from otherwise smart people.
geoelectric 11y ago
Percentage of module owners who you can't trust to not screw up their module: H Risk of indirectly hosing a project with N module owners providing dependencies: 1-((1-H)^N) Let's say H is very small, like 0.05% of module owners being the type who'd hose their own packages. 3 module owners: 0.15% chance your own project gets hosed 30 module owners: 1.49% chance your own project gets hosed 300 module owners: 13.93% chance your own project gets hosed Keep in mind it's not just your dependencies, but your entire dependency chain. And if you think a module owner might hose some modules but not others, maybe H is actually the number of modules in which case 300 starts getting pretty attainable. Upshot: Not everyone is trustworthy enough to hang your project on. The more packages you include, the more risk you incur. And the more module owners you include, definitely more risk. The micromodule ecosystem is wonderful for all the reasons described, but it's terrible for optimizing against dependency risk. Takeaways: Host your own packages. That makes you the module owner for the purposes of your dependency chain. If you're not going to do that, don't use modules dynamically from module owners you don't trust directly with the success of your project. I love collaborative ecosystems, but some people suck and some perfectly non-sucky people make sucky decisions, at least from your perspective. The ecosystem has to accommodate that. Trust is great...in moderation.

wodencafe 11y ago

But this doesn't address the author's point that each module, each dependency is an additional point of failure.

lewisl9029 11y ago
There are definitely trade-offs involved when making decisions to inline vs import. Strictly speaking, you're definitely right. Each dependency is an additional point of failure, but so is each additional line of code you inline. The benefits of these small modules is that they're very thoroughly tested by the entire community. I'd say for most cases, they will be much more robust than any solution an individual developer can spontaneously whip up. Of course, these modules don't exist in a vacuum, and infrastructure failures such as this one do pose another point of failure you wouldn't have with inlining code, but I think in this particular case it had more to do with the failure of npm to adhere to package management best practices to not include an unpublish feature.
- coldtea 11y ago
  >There are definitely trade-offs involved when making decisions to inline vs import. If someone can't make the right trade-off regarding "should I import a module called "isArray" or "is-positive-integer", then they should not be programming...
  - lmm 11y ago
    Yep. Everyone mocking NPM and the javascript community for this ought to retire, they clearly don't understand how to program in this day and age. Or is that not what you meant?
  - robmcm 11y ago
    I think a lot of the confusion here is that in most languages "isArray" or "is-positive-integer" are simple functions of simply build into the language. Dynamic typing and diversity of devices and virtual machines mean the ability to simple tell if something is an Array could be multiple lines of code that could take a considerable amount of time to test. Delegating this to the community is arguably the only sane choice, however strange that may be to someone come from another environment.

kbenson 11y ago

The simple rebuttal to that is that modules that are collections of small functions are easy to reason about as well, and don't the downside of increasing the metadata management to useful function ratio nearly as much. Why have just an average (mean) function, when it makes sense to provide a median and mode as well? Even then, you might find that there's a bunch of extra math operations that are useful, and you might want to include some of those.

lewisl9029 11y ago
With the advent of ES6 modules's selective imports and tree-shaking, that's definitely quickly becoming a better approach. With the old CommonJS modules, you need to be concerned about overall code size, which is where small, single purpose modules excel, and why this approach has proliferated to this degree.
- rubber_duck 11y ago
  Doea code size really matter to node.js ? And how common was commonjs (no pun intended) on the client before ES6 ? Also doesn't commonjs bundling add a significant overhead when talking 5 line function modules ?
  - lewisl9029 11y ago
    Quite common actually (see Browserify)! In fact, the increasingly widespread use of npm and CommonJS on the client is one of the factors that motivated the npm team to transition to flat, auto-deduplicated modules in version 3.
  - sillysaurus3 11y ago
    There is little reason to bundle node.js code. It's an optimization, and a dubious one. In my experience, speed of execution isn't impacted at all. I haven't tested the memory footprint, but it seems vanishingly unlikely that dead code elimination would have any substantial effect. There's probably not any overhead in bundling, though. Not in speed or memory, at least. The overhead is in the complexity: the programmer now has one more place to check for faults, and debugging stack traces now point to a bundled version of code instead of the original sources. The case where none of this is true is when require() ends up being called thousands of times. Startup time will be correspondingly slow, and bundling is the cure. But that should only be done as a last resort, not a preemptive measure.

idlewan 11y ago

You'd have a good point, if all of those tiny but probably useful modules were given the use you're describing. Discoverability though is so poor that most of those modules are most likely just used by the author and the author's co-workers. If a typical npm user writes hundreds of packages, how the hell am I supposed to make use of them, when I can't even find them? Npm's search is horrendous, and is far from useful when trying to get to "the best/most supported module that does X" (assuming that random programmers rely on popularity to make their choice, which in itself is another problem...).

foobarian 11y ago
Another benefit of small well understood components is that they are easier to write tests for. Do these npm modules have good test coverage? Did the leftpad module have a unit test that would have caught the issue?
- lugg 11y ago
  which issue? I thought we were talking about the random removal of left-pad and a couple hundred others.
- zachrose 11y ago
  No, leftpad has four test cases and they are all obvious, given the leftpad API. Would I write tests for my own leftpad implementation if I were not farming it out to a dependency? Its possible. More likely I would want to understand the intent behind using leftpad in my application or library, and have test for "formatTicket" or whatever it is that I'm actually doing. But for all the talk about tiny modules that cover surprisingly tricky edge cases, this is not one of them.
lewisl9029 11y ago
You're totally right. Most developers don't develop this way, and that makes the benefits of this approach far less pronounced than they would be if they did. It also doesn't negate the benefits entirely, of course.
jt2190 11y ago

joe_the_user 11y ago

I don't see how your linked comment brings more to the table than the basic arguments for code reuse. But naturally, with any code reuse there's a benefit and a cost to instance of internal or external reuse. The Benefits for external reuse include ideal reliability as your describe as well as not having to create the code. The costs for external reuse include having your code tied to not just an external object but also the individuals and organizations creating that object. I think that means that unless someone takes their hundreds of modules from the same person or organization and is capable of monitoring that person, that someone is incorporating a layer of risk to their code that they don't anticipate at all.

memracom 11y ago

They do NOT encourage code re-use because the effort required to understand your need, refrain from writing code, and hunt down a module in npm, far outweighs the effort to just write the code and stick it in your in-house utils library.

jay_kyburz 11y ago
Yeah but, why do you need your own in-house utils library. Node needs batteries included!
- mikekchar 11y ago
  Because writing code is what programmers (should) do. If something is simple, then it is simple and won't take up time and energy. If you don't know how to do it, then learning how to do it is worthwhile -- especially if it turns out to be simple. If you make a mistake, then someone on the team must look at the code and understand the mistake. This means that the team learns that things that seem simple are sometimes complex and they learn how to recognise their mistakes. When there is a mistake, someone has to fix that mistake. They learn how to fix the problem. Other people on the team must review that fix and they also learn how to fix the problem. There is always a balance between getting some extra productivity by using somebody else's code, or getting the knowledge, expertise and control of writing it yourself. Far too often I see young programmer's choose something off the shelf so that they don't have to understand it. This is a recipe for disaster -- for your project, for your team and for yourself. IMHO, as programmers, we should err on the side of writing code. Often it is obvious that you should use standard libraries, or a particular framework or or another reuse library. But where it is not really obvious, I would start with writing your own code and see where it gets you. You can always replace it later if it doesn't work out. I think you will find that you and your team will be miles ahead if you take this approach.
  - andy9775 11y ago
    Never understood the fun in importing everything and chaining together someone else's code. Sometimes if I'm building something trivial, a bit of test code or something for fun I'll write up all of it, even if I have to reference others code. You learn so much more.

fieryeagle 11y ago

Just sugar-coated kool aid I'm hearing. Community benefits? First of all, I'm coding to get paid and this recent madness proved that JS ecosystem is semi-garbage. Back to the original question - do people really can't program that they need packages like left-pad or is-integer which had their own dependencies? Before writing those cool toolchains (which would likely work in a specific machine with a specific setting with all the real world testing the community has) can we at least pretend that we know the computer science basics?

johnny22 11y ago
if leftpad were in the node stdlib, would you still be making the same point about knowing computer science and using leftpad? in python: https://docs.python.org/3.3/library/stdtypes.html#str.ljust https://docs.python.org/3.3/library/stdtypes.html#str.ljust
- fieryeagle 11y ago
  Yes, until people stopped publishing isInteger and isArray as `packages`. Plus, stdlib is standard library. Can you cite one for JS? NPM is not.
usrusr 11y ago
People need modules like leftpad to tick the "maintains moderately popular open source project" checkbox. Instant hirability. I don't want to claim that it would be a directly calculated career move, more like starting a blog: you admire a good blog, you want to be more like the blogger, you start your own one. On the dim chance that it will become both good and not abandoned after the third post. Nanomodules can be just like that, the air guitar of would-be rockstar coders. This is certainly not the only reason for their existence (and even the air-guitar aspect has a positive: low barrier of entry that might lead to more serious contribution), but the discussion would be incomplete if it was ignored.
- spenuke 11y ago
  Yep, I think this is a huge, HUGE part of it. Step 1: Create a culture in which "having open source contributions" is a requirement to entering said culture. Step 2: Remove all friction from introducing open source contributions into the culture. Step 3: Watch the Cambrian explosion. Step 4: (Two years later) Point to the Cambrian collapse and how the new hot thing will solve everything. I don't know what sort of shit show Step 4 will turn into, but it will also definitely be the result of folks taking a simple and good rule of thumb (this time, it won't be "small and composable"), and implementing it without ever stopping to think what problems it solves and doesn't solve.

userbinator 11y ago

Small modules are easy to reason about Yes they are, in the same way that a book in which every page consists of a single word is easier to understand than one with more content per page. By focusing on the small-scale complexity to such an extreme, you've managed to make the whole system much harder to understand, and understanding the big picture is vital to things like debugging and making systems which are efficient overall. IMHO this hyperabstraction and hypermodularisation (I just made these terms up, but I think they should be used more) is a symptom of a community that has mainly abandoned real thought and replaced it with dogmatic cargo-cult adherence to "best practices" which they think will somehow magically make their software awesome if taken to extremes. It's easy to see how advice like "keep functions short" and "don't implement anything yourself" could lead to such absurdity when taken to their logical conclusions. The same mentality with "more OOP is better" is what lead to Enterprise Java. Related article that explains this phenomenon in more detail: http://countercomplex.blogspot.ca/2014/08/the-resource-leak-bug-of-our.html http://countercomplex.blogspot.ca/2014/08/the-resource-leak-...

lewisl9029 11y ago
> Yes they are, in the same way that a book in which every page consists of a single word is easier to understand than one with more content per page. A more apt metaphor would be separating a book into many small paragraphs that each serves a single purpose makes the book easier to understand. Regardless, the book metaphor misses a lot of the nuance. Of course taking the approach to an extreme would be detrimental. However, a vast majority of these small modules that are actually widely used consist of functions that may seem trivial at first sight, but actually contain a lot of corner cases and special considerations that a naive inline implementation could miss. Sure, there are also plenty of trivial one-line modules on npm that don't fit into a such a description, but those are simply side effects of the unprecedented popularity of the platform and its completely open nature, and shouldn't be used to infer any kind of general trend towards "hypermodularisation" because very few reasonable developers would ever import them into their projects.
- simula67 11y ago
  > A more apt metaphor would be separating a book into many small paragraphs that each serves a single purpose makes the book easier to understand No, that would not be an apt metaphor for the problem he is describing. > Regardless, the book metaphor misses a lot of the nuance. Not if you are trying to understand the point he is trying to make. Is there any cost to creating modules, uploading them to npm and using them in other projects ? Clearly there is, as is shown by the world-wide breakage from yesterday. This is probably only one of such failure modes. The point is, breaking everything into micro-modules can have benefits and costs. Ultimately, it is an engineering trade-off. Now, it is possible that npm modules are at the right level of abstraction, even though other module systems in the world are not this granular. If this is due to the special nature of JavaScript then the point must be argued from that perspective.

coldtea 11y ago

>TL;DR: Small modules are easy to reason about, and encourage code reuse and sharing across the entire community. How does that even remotely applies to the "is positive integer" test, and even more so to "it's positive" and "it's integer"? What's next? is-bigger-than-5? word-starts-with-capital-letter? add-1-to-a-number?

userbinator 11y ago
add-1-to-a-number This seems to be a very common example in educational materials about how to create a function in some programming language. Perhaps they should all be prefaced with "NOTE: you should not actually make such a function, because its triviality means that every time you use it you will be increasing the complexity of your code", or a longer discussion on when abstraction in general is appropriate and when it is not. Ditto for any other abstraction --- I've found there's too much of an "abstraction is good so use it whenever you can" theme in a lot of programming/software design books and not enough "why abstraction can be bad" sort of discussion, which then leads to the "you can never have too much" mentality and the resultant explosion of monstrous complexity. Apparently, trusting the reader to think about the negatives and exercise discretion didn't work so well...
- Stratoscope 11y ago
  > Apparently, trusting the reader to think about the negatives and exercise discretion didn't work so well... That's the whole point. If you use is-positive-integer, you won't have to think about the negatives!
n0us 11y ago
No, you see "is-bigger-than-5" clearly does 4 different things. You need these modules: module.exports = exec("==="); module.exports = bigger(a, b){return a > b}; module.exports = () => return "than"; module.exports = (a) => a.search('ABCD...'); .. or something like that. These are all plugins of course.
- deleted 11y ago
  [deleted]

masterleep 11y ago

That argument sounds like an enterprise architect explaining why the AbstractReusableBeanFactoryGenerator is going to increase productivity.

lsc 11y ago

My problem is one of productivity. There's already a standard library, and if it's a language I've been using for a while, I probably remember most of it. I can pretty much go straight from my thought of what I want done to typing it out, much like typing English. If you force a 'cache miss' and force me out of my head and into a documentation search, well, that's going to have a significant effect on my performance. If the function is well-named, it has less of a cost in reading the code, but there's still a cost, because what if it's slightly different? I have a pretty good feel for the gotchas in much of the standard library of the languages I use. I have to stop and check what the gotchas of your function are. Yes, at some point the complexity cost of gluing together the standard library functions to do something becomes greater than the lookup cost of finding a function that does what I want; but I am saying that adding more functions is not costless.

jdonaldson 11y ago

author of over 600 modules and 1200 lines of javascript.

gone35 11y ago
Wow, you were not kidding. I chose a random package of his [1], and indeed: a grand total of 1 LOC... This is madness. [1] https://github.com/sindresorhus/float-equal/blob/master/index.js https://github.com/sindresorhus/float-equal/blob/master/inde...
- serge2k 11y ago
  and it uses another 1LOC package. https://github.com/sindresorhus/number-epsilon/blob/master/index.js https://github.com/sindresorhus/number-epsilon/blob/master/i... and no, the edge cases argument does not apply to either of them. Wow.
  - ricardobeat 11y ago
    Would you like to memorise that number yourself to use in your app?
    - wyattpeak 11y ago
      What memorise? How about this for a dependency: https://www.google.com.au/search?q=es6+epsilon https://www.google.com.au/search?q=es6+epsilon
      - ricardobeat 11y ago
        That module exists precisely because this is a new addition to the language, it's a polyfill for backwards compatibility.

erik14th 11y ago

How is that superior to copypasting from a stackoverflow answer? If it's a popular issue, lots of people had the same issue, many will be nice enough to add their edge cases and make the answer better, most will not. Same goes for contributing to a package. With a package you would be able to update when someone adds an edge case, but it might break your existent code and that edge case may be something that is not particular to your system. If you don't want to get too deep in the issue, you can copy paste from SO, just the same you can just add a package. If you want to understand the problem, you can read the answers, comments, etc. With the package you rely on reading code, I don't know how well those small packages are documented but I wouldn't count on it. The only arguments that stands are code reuse and testability. But code reuse at the cost of the complexity the dependencies add, which IMO is not worth the time it'll take you to copy and paste some code from SO. Testability is cool but with an endless spiral of dependencies that quite often use one or more of the different (task|package|build) (managers|tools) that the node ecosystem has, I find it hard to justify adding a dependency for something trivial.

rycfan 11y ago
How is it superior? Simple. How do I systematically make sure that I have the latest version of every stackoverflow code snippet? If it's a new post, it may not have all the edge cases fixed yet. So now I have to check back on each of the X number of snippets I've copied. In the npm approach, I can easily tell if there's a new version. For prod, I can lock to a specific version, but in my test environment, I can use ^ to get newer versions and test those before I put them in production. If the edge case of new version of a package breaks my code, I've learned that I'm missing a unit test. Plus, the question isn't whether this bad thing might happen on occasion, the question is whether this approach is, on balance, superior to cutting and pasting random code snippets into my code. I think the downside of the npm approach is less than the downside of the copypasting from stackoverflow approach. And every moderately useful npm package I've looked at has very good to great documenation.

forgotpwtomain 11y ago

> This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/ama/issues/10#issuecomment-1.. https://github.com/sindresorhus/ama/issues/10#issuecomment-1.... If anything looking at sindresorhus's activity feed: (https://github.com/sindresorhus https://github.com/sindresorhus) perfectly supports the author's point. Maybe some people have so little to do that they can author or find a relevant package for every single ~10 line function they need to use in their code and then spend countless commits bumping project-versions and updating package.json files. I have no idea how they get work done though..

Cut_N_Paste 11y ago
I think the gist of this whole discussion ( at least the OMG WHY?!?! ) part, can be easily explained by an excerpt from your example comment that sums up in a nutshell the all too pervasive mindset I've seen over the years: "...LOC is pretty much irrelevant. It doesn't matter if the module is one line or hundreds. It's all about containing complexity. Think of node modules as lego blocks. You don't necessarily care about the details of how it's made. All you need to know is how to use the lego blocks to build your lego castle. By making small focused modules you can easily build large complex systems without having to know every single detail of how everything works..." By LOC he's referencing 'ye ole Lines of Code paradigm, and trying to make the point that in the end it just doesn't measure up to the prime directive of "containing complexity". ... and that's where I beg to differ. What I think is being completely overlooked here is the net cost of abstracting away all that complexity... It's performance. Every extra line of code, extraneous function call, unnecessary abstraction ( I'm looking at you promise ), every lazy inclusion of an entire library for the use of a shortcut to document.getElementById -- these all add unnecessary costs from the network down to the cpu. And who pays these costs? The end users of your slow, memory hogging, less-than-ideal set of instructions to the cpu that you call an application... but hey, it's easier for you, so there's that.
- spion 11y ago
  Promise was clearly necessary, because without it we had hundreds of other less principled ways to implement async control flow :)

EdiX 11y ago

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

ShellfishMeme 11y ago
JS does not have an Integer type, so (x > 0) does not work. Now if you add all those checks necessary to see whether you're actually dealing with an integer here, you get to a point where you cannot be sure anymore whether there aren't any weird type coercion issues there and need to start writing tests. Suddenly your whole positive integer check took 1h to write and you still cannot be sure whether there's something you didn't think of. I'd rather use an external library for that that's properly unit tested.
- EdiX 11y ago
  JS does not have an Integer type, so (x > 0) does not work It depends on what the surrounding code actually does wheter (x > 0) works or not. Depending on the version of is-positive-integer you are using a positive instance of the class Number may return true, false or cause an error. PS. never mind that the implementation of is-positive-integer is extremely inefficient.
- minitech 11y ago
  A module doesn’t solve that kind of type confusion, though. Static typing does. The next best thing in JavaScript is passing consistent types of values to your functions, so just write function isPositiveInteger(x) { return x > 0 && Number.isInteger(x); } and always pass it a number. (Of course, this shouldn’t even be a function, because JavaScript is confused about the definition of “integer” – maybe you really want `x >>> 0 === x` – and apparently is-positive-integer is confused about the definition of “positive”, so it’ll be clearer to just put things inline.)

wiradikusuma 11y ago

Why dont they put everything together and call it "commons" like in Java? (commons-lang, commons-io, etc).

tmptmp 11y ago

it reminds an apt proverb: missing forest for the trees. Too many modules do not necessarily become a good thing. They may appear to get rid of complexity but in reality, you will have to face the complexity some level above and in fact, the sheer number of small modules will most probably add more complexity of themselves.

z3t4 11y ago

I agree with you, besides the tree-shaking (nice word btw). It's like NPM shaking the Christmas tree and then say "Have fun cleaning up the floor". Remember that NPM is not like apt-get, where the packages are Managed for you by an expert. In NPM you have to manage the packages! And where you can't have NPM and build dependencies, like in production, maintenance now becomes much harder!

avz 11y ago

> Small modules are easy to reason about Flip-side: it isn't easy to reason about a large and complicated graph of dependencies.

confusedjs 11y ago

I'm not at all clear why this blog post is touted as evidence that the tiny modules approach is correct. I think it might be all the people after it congratulating him. "It's all about containing complexity." - this completely ignores the complexity of maintaining dependencies. The more dependencies I have the more complicated my project is to maintain. Dependencies are pieces of software managed by separate entities. They have bugs and need updates. It's hard to keep up to date. When I update a piece of software I read the CHANGELOG, how am I expected to read the CHANGELOG for 1,000 packages? Depending on a bigger package (handled by the same entities, who write one changelog, in the same form) is more straight forward. I'm not saying this is wrong - but there's a balance here, and you must not ignore the complexity of increasing your number of dependencies. It does make things harder.

carlosnunez 11y ago

I get that author's point, but do you REALLY need a dependency module that tells you the type of something? That's not a Lego block; that's an excuse.

ctolsen 11y ago
When using a language where isArray(arr) turns into toString.call(arr) == '[object Array]' ...then I guess that's more reasonable than if you use something sane.

carlosnunez 11y ago

I get that author's point, but do you REALLY need a dependency module that tells you the type of something? That's not a Lego block; that's an excuse.

spoondan 11y ago

I think that there's a certain wishfulness bordering on naïveté to this pursuit. We tell ourselves that we are managing complexity by having small, well-tested units that are reused by an entire community. But software complexity continues to exist. We think we are mitigating the complexity of our own software. But the complexity really just shifts to the integration of components. Anyone that has been around long enough has war stories about getting two relatively simple pieces of software working with each other. In my experience, integration problems are often the most difficult to deal with.

calanya 11y ago

The alternative to small modules is not no modules at all, it's libraries.

ctolsen 11y ago

It's interesting to me that people find this convincing. I find it to be complete insanity. People need their libraries, but putting everything in tiny buckets is just not working. Why aren't people working on good utility libraries instead? There's even some guy calling for a "micro-lodash". To me, as a Python engineer, lodash [1] is already a tiny utility library. I guess it's also about the fact that JS is a pretty bad language. That you need a one-line `isArray` dependency to `toString.call(arr) == '[object Array]'` is crazy. [1] https://lodash.com/docs https://lodash.com/docs

dysfunction 11y ago
There is a practical reason for tiny modules in client-side JS that doesn't exist with Python: page load times. If your base layer is going to have third-party dependencies, they better be tiny and do only and exactly what you need. That said, lodash core is only 4KB, and lodash gives you the ability to build it with only the categories or exact functions you want, so I don't understand what the purpose of a "micro-lodash" would be.
- ctolsen 11y ago
  There are tools to include only the stuff you actually use that you can stuff in your build process though.

deleted 11y ago

[deleted]

coleifer 11y ago

> author of over 600 modules on npm Nope.

yAnonymous 11y ago

The reasoning makes sense for small modules that might change in the future, but as he says himself, most of his modules are finished and will never change. That makes many arguments in his post moot and the modules should probably be snippets instead that are implemented directly.

endemic 11y ago

My problem with this, as an occasional JavaScript developer, is "discoverability" (as many others have mentioned). If I decide I need a left-pad function, and search on NPM, how do I choose which one is best? The one with the most downloads? Not always the best indicator of quality; perhaps it's just the oldest. Not to mention the cognitive overhead of stopping programming, going to NPM, searching/finding/installing the module, then reading the documentation to understand its API. Isn't it simpler to `while (str.length < endLength) str = padChar + str;`? How can there be a bug in that "alternative naive inlined solution"? Either it works or it doesn't!

jack9 11y ago

Small modules are also often the result of dealing with different javascript implementations over the years. I've recently seen a simpler version of the left pad that would not have worked on multiple Safari versions or <IE6 The derision is unwarranted, due to a failure in critical thinking from otherwise smart people.

geoelectric 11y ago

Percentage of module owners who you can't trust to not screw up their module: H Risk of indirectly hosing a project with N module owners providing dependencies: 1-((1-H)^N) Let's say H is very small, like 0.05% of module owners being the type who'd hose their own packages. 3 module owners: 0.15% chance your own project gets hosed 30 module owners: 1.49% chance your own project gets hosed 300 module owners: 13.93% chance your own project gets hosed Keep in mind it's not just your dependencies, but your entire dependency chain. And if you think a module owner might hose some modules but not others, maybe H is actually the number of modules in which case 300 starts getting pretty attainable. Upshot: Not everyone is trustworthy enough to hang your project on. The more packages you include, the more risk you incur. And the more module owners you include, definitely more risk. The micromodule ecosystem is wonderful for all the reasons described, but it's terrible for optimizing against dependency risk. Takeaways: Host your own packages. That makes you the module owner for the purposes of your dependency chain. If you're not going to do that, don't use modules dynamically from module owners you don't trust directly with the success of your project. I love collaborative ecosystems, but some people suck and some perfectly non-sucky people make sucky decisions, at least from your perspective. The ecosystem has to accommodate that. Trust is great...in moderation.