Why my team uses npm instead of bower
Nick Heiner

I love how these articles ignore the web client UI specific concerns that spurred Bower’s development in the first place. As if the only thing that exists on the web is JavaScript, and as if CommonJS is a good module format for client side scripts.

See, when npm first started, you couldn’t distribute assets like images. In a UI, you’ll probably have some images. So that was a bit of a blocker for adopting npm for UI components.

But even in terms of JavaScript only, npm’s (< 3) heavily nested structure is bad for web client performance because it adds redundant bloat to script that will be sent via HTTP to a web client.

In terms of HTML and CSS, with their global namespaces, it’s the next thing to completely not viable. If two widgets in an app depend on two different versions of Bootstrap Accordion (meaning its HTML pattern, its styles, and the script), how does the app avoid conflicts between their different styles?

Bower’s not the greatest thing ever, especially if you’re not dealing with web client UI, but it was designed to align with what web client UI developers required, wanted, and expected.

npm has committed — so I heartd — to providing the features needed, and that’s great. Bower developers are helping out, which is also great. I’d like to have one package manager, too, and npm has their shit together. But myopic “screw Bower, use npm” posts miss the point 95% of the time.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.