Bower vs Browserify

For some, confusion stems around package managers for the front-end, all vying for developer love. In the field there are three well-known package managers that stand; Bower, Component and NPM (Node Package Manager).

Bower and Component are package managers strictly for the front-end, although Node modules exist to bring them in and use them as Node modules.

The third, NPM, started out as Node only modules, but through the community started going in all kinds of directions (including front-end tooling)

Two different approaches, but the same end goal (sorta): Bower and Browserify.

Browserify

Essentially what Browserify allows you to do is bring Node modules into the browser. An area where Browserify is a popular choice is game development. Because of the sheer amount of great game libraries for Javascript.

The one major downside is that NPM + Browserify only packages Javascript files, not CSS files or anything else. This means that its uses are quite limited if say for example you want to import Foundation, jQuery UI or any other library that has a mixture of JS, CSS, images or other assets.

The great thing about Browserify is it allows you to write more modular Javascript. You can break out your Angular directives, controllers or whatever and include them using a require(). Browserify will then bundle it up and make it usable on the client-side.

When it comes to a Browserify package, it needs to be written in CommonJS format and then added to NPM. While the list is high, not all libraries are written in this format which means if you want to bring a dependency in, you need to rewrite it.

If you are however using Browserify to manage your own project Javascript, you don’t need to worry about adding it into NPM, simply install Browserify and then write your modules using CommonJS format and you are good to go.

Bower

Strictly a front-end only package manager. Extremely flexible in that it allows you to install Github repositories as package sources if they are not listed on the official Bower repository.

It handles modules regardless of what they contain. Whether that be; CSS, HTML, images or Javascript files. You also get the benefit of separating dependencies on the back-end from the front-end as well.

If the purpose of the framework or library you are wanting to include is mostly for front-end purposes like jQuery or Bootstrap, then sticking with Bower or equivalent is a good idea.

The upside of picking Bower, is that it works really well with task runners like Gulp and Grunt. You are able to achieve the same things as Browserify can (only for client-side libraries) through a few simple tasks you can find in various repositories and gists.

Conclusion

The rule of thumb for picking one or the other is assessing your needs. Are you working on a project that would benefit or needs to work closely with the back-end? The shared code approach Browserify gives you might be best.

If you need more than client-side libraries or like the way Node package work, it is also another added advantage.

If you just need to add a few libraries or a framework to make your front-end all snazzy and move a few elements around the page, style the scrollbars or whatever it is you are doing that requires heavy DOM manipulation and interaction, choose Bower. Using Browserify + NPM for client-side libraries feels dirty and wrong in my opinion.

It is also worth noting that it is acceptable to use both Bower and Browserify in the same project. Using Bower for components with a mixture of CSS and other static assets, then using Browserify for the heavier JS focused code.