JavaScript dependency management: npm vs. bower vs. volo [closed]

JavaScript dependency management: npm vs. bower vs. volo [closed]

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.

Solutions/Answers:

Solution 1:

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.

Solution 2:

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.

Related:  Global javascript variable inside document.ready

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…

Related:  What's the difference between hydrate() and render() in React 16?

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.

Solution 3:

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.

Related:  jquery unobtrusive validation attributes reference?

Solution 4:

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.

Solution 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 🙂