Couldn't you say the same thing about time spent on npm which could have gone into apt or yum?

Not all node platforms run apt/yum. Having a package manager for your platform makes sense.

The problem I have with apt, yum, etc... is that the packages for development are so old that you're going to be compiling from source and managing your own updates, which is exactly the problem a good package manager should solve.

The big difference is that packages that land in the official apt repositories have been heavily tested by the apt repository maintainers. Anyone can push a package to PyPI for example. There is a clear trade off between using packages from apt/yum and your toolchain's package managers.

In practice, I do find it much easier to pin dependencies and install from my toolchain's package manager (pip/PyPI).

Why do you have to deal with bower? I don't.

A lot of frontend libraries are not on npm.

I don't have to deal with npm either for that matter.

Care to say what are you dealing with instead? I hope it's not something obvious like "I build Obj-C apps"...

For the small number of dependencies any of the projects I work on have, I find it easier to download the dependencies in a browser, and just copy them to the projects I'm using. I understand this is heresy.

> I find it easier to...

Have you used Bower? I haven't but I watched a video of some guy speaking of Bower who pretty much said the same thing you did but changed his mind after trying it out.

I haven't tried Bower yet but kept that anecdote in mind and plan to try it to see what all the fuss is about.

From my understanding, a single command will take away all those intermediary steps between deciding to use a library and actually using it. No need to navigate to the project's page, looking for download link, downloading it, extracting and copying to the project directory.

Sounds good in theory to me; just haven't the chance to try it yet myself. Mostly because npm happens to have everything I would have used Bower for.

"Small number of dependencies" being the operative phrase.

Try managing a complex single page app with deep dependency graphs and each node in that graph versioning up independently. Not sure how your approach would scale there.

I've never worked on an app that required more than ~4 javascript dependencies, and the depth of the dependency graph has never been more than 2.

Agreed. Bower also doesn't have any notion of version pegging or shrinkwrapping like npm... which is a total production killer.

Agreed. I was using Bower until I discovered that most client-side libraries are also on npm. Much simpler.