[asterisk_]

This doesn't seem too controversial of an opinion, haven't small modules already been at the core of a Unix philosophy? Once usage patterns emerge, these smaller libraries are composed into frameworks which ultimately build end-user applications.

The entirety of engineering is premised upon leveraging powerful abstractions; cf. the reason we're not still coding via electric charge.

Edit: To expand on the analogy: "A two-person startup already uses twenty-eight other tools" [1].

[1] https://news.ycombinator.com/item?id=22449314

[jasode]

>, haven't small modules already been at the core of a Unix philosophy?

I assume you're talking about userland programs such as "ls", "cut", "grep", etc. ?[1]

But C Language is also part of UNIX and programmers typically link against a large more comprehensive "standard library" such as glibc:

  libc.a, libc.so  <-- includes printf

... instead linking of a hundred little object files specified explicitly like this:

  printf.o
  strcat.o
  strncat.o
  malloc.o
  leftpad.o
  ... <hundred or thousand more .o files>

What happened with Javascript is the language didn't have a comprehensive "standard library" like C, C++, Java, C#, Python "batteries included", Go, etc. Therefore, NPM became an adhoc "standard library" via bottom-up crowdsourcing. There are both positives and negatives to that approach. One negative is that leftpad() isn't produced by a canonical entity like Netscape or Mozilla but a random programmer. When he wanted to take his ball and go home, he broke everyone's build that depended on it. That type of event didn't happen with "printf()" in the C Language world.

[1] https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_a...