I was recently reminded of that time when I saw this question:
Am I the only one frustrated by the package management situation in frontend development?
Why are there so many?
At the very end I'll tell you which package manager I use for everything, and why.
All the Package Managers
These are listed in chronological order based on the first commit date so you can put them in context.
First Commit: Sep 29, 2009
This one is usually thought of as the node package manager. NPM even stands for node package manager. Obviously you aren't using node in the browser/frontend.
So why is this listed here?
You can use NPM packages for frontend AND backend. Any NPM package that you find might be intended for node only, browser only, or both. These days it seems like most packages can be used in both places.
First Commit: Sep 6, 2012
Tagline: A package manager for the web
Bower has more github stars by far than any other package manager in this list. It is clearly very popular (and has a great logo!).
But you can't go on the star count alone. Bower probably has so many stars because it used to be incredibly useful.
When Bower was created, NPM existed already, but it was for node, not the browser. Node packages didn't usually include assets (like bundled JS and CSS) in their NPM packages. If you needed the assets, you would just download them. That's janky - and that's why Bower was created.
Nowadays NPM packages include frontend assets, so if you are already using NPM for your node backend, you might want to stick with NPM and skip Bower.
First commit: Sep 16, 2013
Tagline: Frictionless browser package management
For users of the SystemJS bundler. If you aren't using SystemJS, you can go ahead and skip this one.
JSPM doesn't host any of its own packages. It allows you to install packages that are hosted on NPM or github. So if you use JSPM, you should search for packages on npmjs.com.
First commit: Apr 9, 2014
Creator: @MattMueller, @mako281
Tagline: A next-generation package manager for the front-end.
Duo lets you specify your
require() statements as github paths, (with an optional version) like this:
var uid =;var fmt =;var reactive =;
The idea is that it saves you time and effort because you don't have to install the package or create a
package.json file. Duo finds and installs the package automatically.
I would argue that this is foolish. If you
require() a package in multiple places, you have to update all your
require() statements any time you want to change the version.
Duo may save a little time in the short term, but it will cost you more in the long term.
Older Package Managers
If you're thinking 'wait, that was only 4, you said there were 7 package managers?', well you're right! I left 3 out.
These package managers are a bit outdated. I list them here for completeness and so you know that if you see them in your travels across the internet, you can safely ignore them.
5. Ender was created way back in 2011, but it only has 6 commits in the github repo for all of 2015. These days that reads as 'not actively maintained'.
6. Component was created in August 2012. According to their github page: "This project is deprecated ... Component is not maintained anymore."
7. Jam was created in May 2012, a few months before Bower. I've left it off my main list because it doesn't have much traction when compared to much newer package managers.
I've heard these other projects mentioned as package manager alternatives, but they aren't package managers. So take a look, but know that you'll need one of the package managers above, and these are additional tools:
- napa: If you use NPM as your package manager, napa helps you install github repositories that haven't been configured to be used as packages yet.
- volo: "volo is a tool which lets you quickly create projects, add libraries, and automate common tasks"
So Which One Do I Use?
Otherwise, use NPM. Any package worth their salt will be hosted on NPM, frontend packages included. Plus if you are using node for your backend, you get to keep the same package manager for your backend and your frontend.