Small modules: it’s not quite that simple
Rich Harris

Sorry, but I don’t agree. The idea promoted here seems to be against the Unix philosophy.
Writing small modules instead of big monoliths is a great improvement.

I completely agree that it would be a lot better if writers of small libraries tried to keep the number of dependencies low. But I think is better (and necessary) to preach about keeping dependencies at minimum (ideally zero) instead of a return to monoliths.

I don’t like half-backed projects, but being “easy to publish” is hardly the reason of success for npm. Publishing (full or half-backed) projects to bower is also really easy. Half-baked projects is something I been seeing since the times sourceforge was THE distribution channel of open source projects.

I still remember when jQuery came out and suddenly new developers didn’t seem to know the difference between JavaScript and jQuery. They wanted to include jQuery even if they were going only use it for things like “$(‘#id’)” because they didn’t even knew there was “document.getElementById”.
I did reconized the benefits of having a library that handled browser differences but I saw it as a necessary evil. It fomented, among other things, that those brand new developers wanted to make every JavaScript library a jQuery plugin.

I don’t see the fact there are a lot of libraries as a bad thing. I really think having a Baazar is better than having one big library that is THE way to do things. (I’ve always liked the perl slogan “There’s more than one way to do it”)