It's not about the number of lines of code. From serial developer modules

Sindre Sorgus is the author of more than 600 npm modules ( 666, Karl! ). In the recent AMA (who does not know, this is such a format, when someone famous / interesting suggests asking questions, for example, in the form of tickets to the git repository , although, of course, more famous / r / AMA and the buffet table at Lebedev ) its position on the modules, one-liners, which often cause criticism of the node.

I was going to write a blog post on this topic, but, unfortunately, I am not as productive in this as in writing code.

tl; dr Small specialized modules are needed for reuse and to make large and complex pieces that are easy to understand.
')
People are too concerned about the number of lines of code. LOC does not matter at all. It does not matter whether the module consists of one line, or hundreds. It's all about hiding complexity. Think of the node modules as Lego cubes. You are not interested in what and how they are made. All you need to know is how to use these cubes to build your lego lock. By making small and specialized modules, you can easily build large and complex systems without control over how each individual component works. Our short-term memory is finite. These modules can be reused by other people, and every improvement and bug fix will receive all of them.

Imagine if PC makers made the processors themselves. Most would do it badly. Computers would be more expensive, and innovations would be slower. Instead, most use Intel, ARM and others.

And that would be impossible if npm didn't work that way. The beauty of multi-level dependencies is that I don't have to control which dependencies I use. This is his strength.

A few years ago, before Node.js and npm, I had a large base of snippets that I copied into projects when I needed it. These were small utilities that sometimes came in handy. Now npm is my base of snippets. Why copy-paste, if you can repair the module and get exactly what you need. A bug fix in a snippet is just an update of one module, and not a fix with the hands of all the places where a snippet would be inserted.

For example, I have a negative-zero module. His job is to tell me that the number is -0 . Usually this is not required, but it happens. And how do we determine that the number is -0 . Quite easy, x === 0 && 1 / x === -Infinity . So? Do you really need to know how and why it works that way? I would prefer to connect negative-zero and concentrate on other things.

Another example. One of the most popular modules on npm is Chalk . You may not know this, but, in fact, this is a set of modules . It uses modules to determine the color support in the terminal , to get ansi codes , etc. All this could be included in the main module, and that is most likely in most cases. But this would mean that someone would create another module to work with strings in the terminal and reinvent the wheel. With the same set of modules, people easily benefit from using Chalk in their projects and, perhaps, even help indirectly improve Chalk itself, improving one of its dependencies.

And another example. My user-home module is only needed to get the user's home directory. You might think that it could be easier than writing process.platform === 'win32' ? process.env.USERPROFILE : process.env.HOME process.platform === 'win32' ? process.env.USERPROFILE : process.env.HOME . And most will do. But, really, why does each of us need to know how to get a home directory? Why not use ready-made "Lego cube"? And, of course, you may not know that this check is incomplete. On Windows, you also need to look at process.env.HOMEDRIVE + process.env.HOMEPATH , and you might also want to do additional checks . Lego

You do not sew your own shoes? No, you buy them at the store. Most do not care how their shoes are made. Just how well they sit on their feet.

I want to make programming easier. To make programming easier is to build reliable systems. And the practical way in my vision is to stop reinventing everything and make the same stupid mistakes again and again.