

Why We Should Stop Using Bower – And How to Do It - jsalonen
http://gofore.com/ohjelmistokehitys/stop-using-bower/

======
TomFrost
This article digs on the flattened dependency model like it's a huge weakness
of Bower, but this is the _entire point_ of Bower.

You include two models that both depend on two different versions of jQuery.
NPM wouldn't complain at all, Browserify would happily package both
dependencies up, and now your users are downloading jQuery twice to view your
page.

Bower, conversely, raises a red flag right away, and lets you determine what
should be done here in the event that the package definition doesn't contain
enough info to sort this out automatically. Its goal is to make your client
code as minimal as possible.

Feature, not bug.

~~~
nawitus
Npm/browserify will load only one copy of jQuery if the semvers match. The
only "problem" with that is that if you get duplicates, npm doesn't report
these out of the box. It's rather easy to write a script to detect these (if
one doesn't exist already).

------
EugeneOZ
I think Bower's model of dependencies is better than NPM's. NPM's trees are
huge and ugly, when Bower's flat structure is more suitable for frontend apps.
For example, if I will use npm for all libs I used to use in frontend web app,
npm will install 2-3 versions of Angular (because so plugins still have
Angular 1.2 in dependencies, some want 1.3 and I use 1.4). And what will we do
with all these versions? Nothing, we can run only 1 Angular simultaneously.

------
hiddentao
I'm trying to move away from using Bower and just stick with NPM, but that's
purely to simplify my project setup. I'd rather have one package manager
managing all my dependencies.

------
mcv
I've never actually encountered this particular problem with bower. My main
problem with it is that it's a pain to get it through corporate proxies. And I
have the same problem with npm.

~~~
VOYD
why do you need one library to load another? Am I missing something here?

