How do you compare npm, bower and volo?
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.
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.
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.
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
As of february of 2013, my opinion was the following. Please don’t take it into account anymore.
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 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.
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.
They seem to be solving the same problem but for different environments/worlds. NPM for nodejs and volo, bower for the browser.
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.
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.
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 🙂