NPM modules can be used on browsers. On browsers, space is a premium.
Why would you want to install a 500kb dependency that has only one function you need, when you can install a 10kb dependency that has it?
Would you want each of your five 20kb dependencies to re-implement the same 5kb function, increasing the code you must send to the client by 20%, or would it be more optimal for each of those dependency to use the same 5kb function?
The author rants about practices of developers from different programming environment, without experience, without figuring how things came to be. If he did give an effort to think from the perspective from Node.JS developers he’d have addressed the previous two points.
This is like going to a friend’s house and complaining everything is put in the wrong place. It would have been wise to immerse in Node.JS conventions and observe for a while before making comment.
EDIT: Reply to scrollaway:
I've also understated the problem.
Let's look at the problem in the current Node.js environment, it's not uncommon for a web app to have 20 dependencies, each of those have 10, and each of those 10 have 5. That's a total of 20 times 10 times 5 = 1000 dependencies in total.
Let's say you were to remove a 10 line library function that's "standard library-like", used by 15% of those dependencies, and have each of the existing dependencies re-implement that in each of those dependencies that uses it.
15% times 1000 times 10 lines is 1500 lines of code.
So if you're going to troll a solid argument by nitpicking, do it properly and get the details right.
FYI, you can reply to my comments if you click on their timestamp, in case the reply box isn't showing up
> So if you're going to troll a solid argument by nitpicking, do it properly and get the details right.
First of all, I don't appreciate you calling me a troll. Someone who mentions "5kb functions" clearly has no idea of what 5kb represents, period.
And second, this is not a solid argument at all. There is logic behind it, which is why we usually have high quality stdlibs in popular languages. Javascript lacks that. So instead, javascript gets this absolute mess of an ecosystem, where things like this can happen.
Several people have brought up various issues with the way it's done now. Dependency hell, for one. Lack of discoverability, which in turn leads to duplicate libraries, which in turn leads to a system where you have 1000 dependencies, but despite your "modular" idealism you still have hundreds of duplicate dependencies. Not to mention all the duplicates of different versions of the same dependency.
This "saving lines of code" math is completely broken exactly because this stuff is not in the stdlib. The various issues with the JS ecosystem mean that the actual results are nowhere close to ideal, and have a net negative impact.
I also love when people mention how much "one time cost" is saved and back it up with similar math, completely forgetting the amount of continuous time wasted downloading and installing these dependencies every time.
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.
It's quite ironic how you're lecturing people about dependencies and bandwidth when you yourself don't seem to have a good grasp in your mind of how immense even 5 kilobytes is (you talk about 5kb functions). 5 kilobytes (well, KiB) is 5120 bytes. That's about 200-300 lines of code. If you're talking about minimized code, maybe up to 500 lines.
While a 5kb function is immense, I work on a legacy code base and I have seen functions up to 2000 lines long. You possibly overestimate the quality of code that people in business actually write. I've worked in a few places and all have parts of the code which I would thought were made up if submitted to the dailywtf.
Also, have you ever seen a commercial library require >2MB of minified JS? Here's an example:
That file is almost 2MB minified (5.6MB unminified).
And that is is only 1 of the few different files required for our dependency on it, there is a bunch more javascript/css also required. Would I use that library on a new product? I'd probably advise against it due to the size, but a legacy product has dependencies and you don't have the freedom to rewrite everything all the time.
Why would you want to install a 500kb dependency that has only one function you need, when you can install a 10kb dependency that has it?
Would you want each of your five 20kb dependencies to re-implement the same 5kb function, increasing the code you must send to the client by 20%, or would it be more optimal for each of those dependency to use the same 5kb function?
The author rants about practices of developers from different programming environment, without experience, without figuring how things came to be. If he did give an effort to think from the perspective from Node.JS developers he’d have addressed the previous two points.
This is like going to a friend’s house and complaining everything is put in the wrong place. It would have been wise to immerse in Node.JS conventions and observe for a while before making comment.
EDIT: Reply to scrollaway:
I've also understated the problem.
Let's look at the problem in the current Node.js environment, it's not uncommon for a web app to have 20 dependencies, each of those have 10, and each of those 10 have 5. That's a total of 20 times 10 times 5 = 1000 dependencies in total.
Let's say you were to remove a 10 line library function that's "standard library-like", used by 15% of those dependencies, and have each of the existing dependencies re-implement that in each of those dependencies that uses it.
15% times 1000 times 10 lines is 1500 lines of code.
So if you're going to troll a solid argument by nitpicking, do it properly and get the details right.