164

How do you compare npm, bower and volo?

All three can be used to install JavaScript dependencies for a UI project. I understand npm is more node specific.

So, when to use what?

npm still stands distant, but bower and volo seem to be solving exactly the same problem, although I am not able to draw a line between npm and bower-volo.

Sebastian Simon
  • 18,263
  • 7
  • 55
  • 75
Yugal Jindle
  • 44,057
  • 43
  • 129
  • 197

5 Answers5

105

A description that best describes the difference between npm and bower is: npm manages JavaScript modules called packages and Bower manages front-end components (i.e. css, html, and JavaScript) called components. npm is also used to install bower. Here is an expansive article on npm and bower (does not cover volo) it goes into plenty of detail.

FaizFizy
  • 459
  • 5
  • 15
strangeloops
  • 1,484
  • 2
  • 11
  • 14
  • 88
    This isn't a very good description. Npm can certainly be used to install front-end components. – B T Sep 30 '13 at 17:32
  • Although I have noticed some "frontend" libraries on npm become abandoned in favor of their bower counterparts. Take for instance [Ember](https://www.npmjs.org/package/ember), which hasn't been published in a year. – briangonzalez Apr 19 '14 at 15:44
  • @BT Sure it can be but it's called npm which stands for node package manager I really think implies node modules not that it can't be used for front-end though. – Nate-Wilkins Jul 24 '14 at 22:11
  • 4
    @Nate The name is simply where it started. NPM is now a very general purpose package management system. I regularly use npm to install front-end modules. There is no difference in using NPM for commonjs modules, vs amd, vs anything else. You could use npm just as well for non-javascript modules as well. Therefore, that is simply not a difference between npm and bower. Whether you call them packages or components, they are the same in that they are both collections of arbitrary files. – B T Jul 24 '14 at 22:23
  • @BT Good point - I'm not sure though it feels awkward using something that was initially intended for node modules instead of using something that's intended for the browser. Like you said though the lines have blurred at least for `npm` – Nate-Wilkins Jul 25 '14 at 00:59
  • 2
    This is a very misleading answer considering bower has no policy for dealing with html, css, and, javascript. npm has no policy either except that almost everything on npm is written to at least support commonjs and occasionally other formats. You can put html and css in npm packages just like you can with bower. There are many frontend-only packages on npm, including packages that include css and html. – substack Aug 16 '14 at 03:09
  • 3
    If you are using [browserify](http://browserify.org/), npm is the perfect package manager. I don't think it matters which package manager you use, but I would personally stick to just one per project. – Eruant Sep 05 '14 at 09:48
  • @Nate NPM stands for Node Packaged Modules (at least it does now) in order to conceptually accommodate for pretty much anything you want to package in a NPM compatible way. Not sure if or when it changed to that. – Bret Dec 07 '14 at 21:31
73

bower

It's still very popular among front-end developers, even though it has very few features. Every front-end package is using it. There is also an initiative to merge bower into npm.

Bower is optimized for the client-side and supports only flat dependency trees, i.e. each library must be used only once (since it's expensive to ship different versions of the same library to the client), and the dependency constraints must be resolved by the user.

You can expect to find anything that is front-end related in the bower registry (bower search <some keyword>) -- in my opinion, that's the biggest advantage of bower in relation to other package managers.

volo

I have still not used it for more than 5 minutes in years. Don't know about it, but from what I can see it does include some build tool, which is very familiar to Grunt users.

npm

Yes, npm stands for Node Package Manager. But nowadays you can use it for everything; people are no longer only npm installing things and expecting them to work only in the Node environment. For example, there are many npm packages for Twitter Bootstrap.

Npm is optimized for server-side usage, with a nested dependency tree. Each dependency can have its own dependencies which can have their own, and so on. This eliminated dependency version conflicts as each dependency can use their own version of e.g. Underscore. However, the upcoming npm version 3 will flatten the dependency tree:

With npm@3, your node_modules directory will be a lot flatter. All of your dependencies and most of your subdependencies (and (sub)+dependencies) will be sitting next to each other at the top level. Only when there are conflicts will modules be installed at deeper levels. This should make things a lot easier for Windows users.

Some advantages I see on using npm:

  • It's used by all the other package managers (component, bower, volo, JSPM, etc);
  • Allows using build scripts;
  • Lots of tools are available for introspecting npm-based packages

npm is the package manager for JavaScript.

npmjs.com screenshot


As of february of 2013, my opinion was the following. Please don't take it into account anymore.

npm

It's better to stick with it when you are with a Node project, there are very few projects that are available to browsers also...

bower

Bower is the pop guy right now. They have lots of projects under their hood, and the project maintainers like to keep them up-to-date in the bower registry...

It's a shame that he's sometimes a little buggy.

volo

I haven't tried volo for more than 5 minutes since so, but from what I could see it looks to be more flexible than bower.

A negative point for volo is that their projects are very outdated.

Community
  • 1
  • 1
gustavohenke
  • 40,997
  • 14
  • 121
  • 129
  • 19
    There are thousands of modules on npm that either work only in browsers or work in both node and in browsers. Many of them even have ci badges that tell you exactly which browsers they work in. Most anything on bower et all is probably on npm. – substack Jun 05 '13 at 01:10
  • I dont understand the need for project like ngBoilerplate to use bower while it already depends on npm for installation – lolski Jul 30 '13 at 03:30
  • 5
    What is a "pop guy"? Is "pop" an abbrev. for "popular"? – Bryan Oakley Jan 17 '14 at 22:03
  • 4
    In your screenshot npm stands for nuclear planning manual ;) – Jim Jones Mar 31 '15 at 04:19
24

They seem to be solving the same problem but for different environments/worlds. NPM for nodejs and volo, bower for the browser.

The truth is that you can use NPM also to manage javascript and css for the browser. There is nothing preventing you from doing it. In that sense using NPM feels more natural to me than having to manage two different tools for the same purpose.

It seems that bower have more packages available, at least for the more popular ones. But soon jQuery will be also be available in NPM directly and probably all the other libraries will follow the same trend.

In my opinion, since there are tools like browserify and webmake out there, that help use node modules in the browser, there is not anymore a real need for bower or volo, unless they offer something else for you (a particular module existing only in their registries).

Both Volo and Bower are good too, but from my point of view, if you're already using NPM, it might be better to stick to it.

Please note that you can use NPM to manage your client dependencies even without using browserify or webmake. In most of the projects I have being working on, after the npm modules are installed I run an script to deploy them to the location where my client app uses them. Sometimes I use grunt to concatenate that file with other js files and sometimes I reference it directly from the template files of my web apps. In any case, this is a personal preference. Others could find Bower or Volo easier to use as they fit more natural in their workflows.

BenMorel
  • 34,448
  • 50
  • 182
  • 322
roy riojas
  • 2,406
  • 1
  • 28
  • 30
  • 1
    Its good to have competing solutions for the same problem. Any idea why `yeoman` project chose to come up with a new package manager when we already had `npm` ? ( It was mature, famous & feature-rich ) This thought makes me feel I am still missing the actual point. – Yugal Jindle Nov 26 '13 at 07:14
  • 1
    Not really, but as you said some times is funny to reinvent the wheel, just because you can, and sometimes by doing it some improvements are made while trying to solve the same problem. Not really why they choose to make a new one, apart from make it easier to frontend developers to find packages. Not all frontend developers have node experience, I guess that is the main reason behind projects like Bower. Try to make it easier to non node users, I'm just guessing here. – roy riojas Nov 26 '13 at 11:09
  • I guess they wanted to separate the hassle of `npm` in favor of frontend simplicity. Hence for frontend development. – Yugal Jindle Nov 26 '13 at 11:49
15

Bower's big advantage over NPM is that its dependency management enforces using a single version of a component (whereas NPM works by having different copies/versions as subdependencies of different modules). This is A VERY GOOD THING because it prevents your client side javascript becoming bloated through needing to include multiple copies of a component at different versions. Including multiple copies of a module is central to how NPM's dependency management works, and NPM is therefore wholly unsuited to client side package management.

A consequence of the above is that bower package maintainers and consumers have to be more mindful of maintaining their dependency version numbers to avoid conflicts, but it's a price worth paying. And I find NPM modules are often sloppy in their issuing of major, minor and patch releases so NPM dependency management isn't exactly a bed of roses either.

wheresrhys
  • 22,558
  • 19
  • 94
  • 162
  • 3
    This is only true if you're serving your frontend code directly from the folder the package manager put those files to. In my case I either have build script to process the less/js files or browserify to create a bundle from those files. So that's not really a big issue in my case. The code being distributed always have the right versions, even when other subcomponents might have duplicates during development they never get to production. – roy riojas Jun 26 '14 at 05:22
  • even if you're inadvertently requiring (as subdependencies) two different version of the same dependency? I think in this case you're wrong – wheresrhys Jun 30 '14 at 11:45
  • I usually don't require modules I don't control, so they will always be the right ones... if inadvertently a module tries to require a given module out of the shimmed ones the build will fail. No point on using bower in my case no benefit added – roy riojas Jun 30 '14 at 12:37
  • So npm can only safely be said to avoid duplicating modules in your client side code if you have control of your entire dependency tree. This certainly isn't the case with the vast majority of things I work on and probably not for most projects using a dependency manager to include client side modules. – wheresrhys Jun 30 '14 at 13:46
  • 1
    Unless you're working on mashups your dependency tree won't be that complicated, at least for thirdparty code. Most js libraries exports a single global, so using browserify-shim you can make sure you can use them from the global scope hence always a version you do control. My point is that you can achieve the same without the need of another package manager on top of one you already have. In the end it might be a preferences matter. There are always compromises to be made. – roy riojas Jun 30 '14 at 19:59
5

I know this isn't in the scope of the question but there's another alternative also. Jam JS - http://jamjs.org/ One thing interesting is that it has grunt capabilities in jam:

jam compile output.js

Someone should make yet another package manager and name it: yapm :)

Bruce Lim
  • 745
  • 6
  • 22
  • 5
    Your wish is granted: https://github.com/rlidwka/yapm :P – alex Feb 10 '14 at 15:56
  • 1
    well I was thinking for browser side dependency manager but I guess this work for both :p This is why I cant do startups, all my ideas were thought of already. – Bruce Lim Feb 10 '14 at 18:41
  • @BruceLim yeah, everytime when we think we've got a good idea, there are always some other people who already got it. – Evan Hu Jan 17 '15 at 07:41