Share On Twitter Facebook Google+ LinkedIn Pinterest Tumblr Reddit
Question

Why use Bower when there is npm?

Tags: web development front-end development npm (package manager) package management bower
Date:
Status:Resolved
Question Id:45

What is the fundamental difference between bower and npm? Just want something plain and simple. I've seen some of my colleagues use bower and npm interchangeably in their projects.

Answer
Date:
Correct:No

In almost all cases, it's more appropriate to use Browserify and npm over Bower. It is simply a better packaging solution for front-end apps than Bower is. At Spotify, we use npm to package entire web modules (html, css, js) and it works very well.

Bower brands itself as the package manager for the web. It would be awesome if this was true - a package manager that made my life better as a front-end developer would be awesome. The problem is that Bower offers no specialized tooling for the purpose. It offers NO tooling that I know of that npm doesn't, and especially none that is specifically useful for front-end developers. There is simply no benefit for a front-end developer to use Bower over npm.

We should stop using bower and consolidate around npm. Thankfully, that is what is happening:

Source: Modulecounts

With browserify or webpack, it becomes super-easy to concatenate all your modules into big minified files, which is awesome for performance, especially for mobile devices. Not so with Bower, which will require significantly more labor to get the same effect.

npm also offers you the ability to use multiple versions of modules simultaneously. If you have not done much application development, this might initially strike you as a bad thing, but once you've gone through a few bouts of Dependency hell you will realize that having the ability to have multiple versions of one module is a pretty darn great feature. Note that npm includes a very handy dedupe tool that automatically makes sure that you only use two versions of a module if you actually have to - if two modules both can use the same version of one module, they will. But if they can't, you have a very handy out.


Shameless plug: If you like my ramblings about programming on Quora, you might enjoy my YouTube show: Fun Fun Function

Answer
Date:
Correct:No

My original answer was written a couple of years before Npm 3 and a few other changes. Since then my criticisms are now outdated. I have since moved on to JSPM and occasionally Webpack.

I personally wouldn't recommend Bower in 2016. It served a need once upon a time, but now we have more flexible options to pick from. Front end development has grown so much with its tooling and plethora of dependencies you not only need a package manager but another package to handle loading and other tooling based actions.

Original answer

Have you seen the way NPM handles its dependencies? The whole infinite sub-folder nesting is atrocious, especially if you are a Windows user, you are going to love the path issues you will run into because nested dependencies can sometimes exceed the 255 character path limit.

With NPM you get duplicate dependencies because each package handles its own dependencies instead of checking if the dependency has already been downloaded. We are talking potentially a few hundred kilobytes, but it is an unnecessary waste of disk space.

The front-end needs a package manager. Bower is incredibly smart in that it only installs a dependency once. If a Bower package needs jQuery for example, it will be in your bower_components (or wherever you chose to save Bower packages) under the jquery folder.

Because you will use a task runner like Gulp or Grunt to combine and minify your package dependencies, the duplication in NPM is unacceptable for the front-end of an application where file size matters. It all makes sense once you wrap Bower components in a build process.

Sure you could use something like Browserify with NPM, but why bother? You should never mix your server-side dependencies with your front-end dependencies in the same package file (which if you use NPM, you will be doing).

The benefit of Bower or whatever front-end package manager you use is that it self-documents your dependencies only for the front-end, and allows front-end developers to only touch a file for the front-end leaving the backend to a services or backend team.

So I politely disagree with everyone else here saying the front-end does not need a dedicated package manager.

Answer
Date:
Correct:No

Quoting from Bower: Why Front-End Needs a Package Manager

 

The main difference between npm and Bower is the approach for installing package dependencies. npm installs dependencies for each package separately, and as a result makes a big package dependency tree (node_modules/grunt/node_modules/glob/node_modules/...), where there could be several version of the same package. For client-side JavaScript this is unacceptable: you can't add two different version for jQuery or any other library to a page. With Bower each package is installed once (jQuery will always be in the bower_components/jquery folder, regardless of how many packages depend on it) and in the case of a dependency conflict, Bower simply won't install the package incompatible with one that's already installed.

Answer
Date:
Correct:No

Bower has had better marketing from teams that push it with using Yeoman and Grunt. Google and Twitter dev teams have "packaged" these three tools together and made it sound as though these are your modern workflow necessities. I was in the same camp about using just using Bower until a friend at Adobe explained that npm can do it all; front-end and back-end.

IMO there's no reason to use Bower other than a million code tutorials that insist you use it and/or your dev team is starting out and feels "Since we have to use Yeoman and Grunt, too, we might as well cuz that's what everyone else is doing." It's just the wrong mindset.

Answer
Date:
Correct:No

I was actually in the "there is no good reason to use bower" camp for a long time. I've recently come around.

Sure, if you want to use browserify then perhaps npm alone is enough. However, if you have a few hang ups with browserify, which you might (and maybe should), then npm no longer works.

Imagine using requirejs in this world:

package a's dependencies:
- jquery
- tinycolor
- raphael
- backbone

package b's dependencies
- jquery
- tinycolor

your app's dependencies
- package a
- package b
- jquery

Now, if you were to require something from "package a" it may expect jquery to be inside its node_modules folder. It wouldn't be there... why? Well your app also depends on jquery and if those 2 versions of jquery are semantically compatible jquery ends up in the root thus forcing you to do some magic with paths in the require config file.

This sucks.... It is brutal. In fact this problem instantly goes away if each package just uses bower. In bower land everything is flat and gets installed at the root level. This has its own set of problems (ask anyone who has worked with pip in python land). That being said you may want to deal with those problems instead.

Then again you may not. The browserify route is valid. If you are ok with constantly rebuilding your app and trying to figure out how to split your code. Then it may well be worth the price of admission.

The decision ends up coming down to deciding which battles does your engineering org want to fight on a weekly basis.

Answer
Date:
Correct:No

I would like to try to answer the specific question asked: “is there really anything about it that technically makes it more adapted for client-side modules?” The short answer is yes. The primary technical difference between NPM modules and Bower modules is how they can consumed.

NPM stands for “Node Package Manager”, so while NPM modules can be used for a number of uses, most are intended to operate within the Node.js ecosystem. NPM modules can include a “main” file specification which allows you to “export” a JavaScript object by assigning it as “module.exports”. This module can then be “imported” into another module or file by using require(“module name”). NPM modules will find each other as long as they are located in the correct location based on NPM naming conventions and this is best done by installing with the command “NPM INSTALL”. Because of this modular design, NPM modules need all of the required dependencies to run. Therefore when you install an NPM module, you also install all dependent code. This can often be thousands of individual files. Regardless of whether you use Node.js or Browserify, you will need all of this code in order to execute this “main” module. Node.js loads all of these files from the file system and Browserify packages them into one or more files to load in your browser. When NPM packages are deployed to a repository, the content is stored in the repository. This makes it easy to control what gets deployed with the package and this content can be built from the source code and then deleted since the published package is stored in the repository.

Bower modules can also specify one or more “Main” files, but these perform no technical purpose. Unlike NPM, Bower is not tied to any specific ecosystem. So when Bootstrap specifies “less/bootstrap.less” as one of its main files, you have to know that you will need to use this as an entry-point for LESS processing for this to have any meaning. How (or if) you process this LESS file is up to you. Most likely what you really want is the pre-processed CSS files in the “dist/css” folder and you want to get the other content such as fonts and you want that content to be in the correct file structure for use with the CSS. It is up to you (usually by reading the documentation for the package) to determine how to use this content (typically with an HTML tag in a web application). Similarly to NPM, Bower also allows you to specify dependencies which can be installed automatically using “BOWER INSTALL”. However, because Bower modules are typically intended to be used for client-side (i.e. just include a tag to use the content), the number of dependencies are typically smaller and in some cases could even be “soft” dependencies meaning they are not installed automatically but if you want to use a certain feature you can install and use them. Using dependencies is not automatic since you typically need to add them to your HTML by placing a tag prior to the tag for the module that depends on them. Bower packages are NOT stored in the repository. Bower assumes that the package contents are in a GIT repository. Therefore you cannot just build the package content and then delete it after deploying. You must store the packaged content in the GIT repository.

Since the question was asking if there is any difference, I assume that the intent is to determine if one type of module is “better” than the other. In other words should you be creating NPM or Bower modules and, if both are available, which should you use. I think both answers are the same. If you want to maximize adoption of your module and it will function without needing the Node.js ecosystem, then you should publish as both (and also consider any other type of repository you think would benefit your user community). If this is for a private repository and you know everyone on the team uses NPM and not Bower, then adding a Bower repository because it is “intended for client-side” just doesn’t make sense. If it is a public repository, why not deploy to both. As for whether you use the Bower or NPM version of a module available in both, again this depends on your ecosystem and preference. If you are using Node.js (or Browserify) then use the NPM version. If you aren’t using anything from that ecosystem (which is very unlikely these days), you can use the Bower version. Another key consideration is the storage of the package. If you do not want to keep the package contents in a GIT repository and you only want to keep the source code in GIT, then I would recommend NPM.

Answer
Date:
Correct:Yes

Okay, blanket statements like “There is simply no benefit for a front-end developer to use Bower over npm” is quite presumptive, and assumes that there can’t possibly be a benefit when the truth is, you simply haven’t seen one yet. So, I have to disagree with that statement, just based on principle alone.

In the early days, the npm (and the typically associated node_modules folder) was a solid isolation of build tools vs the bower components folder which housed code actually incorporated with the application itself. This has huge organizational value.

Why on earth would I want to consolidate my build tools into my application and check that into the repository? Should I be checking in Visual Studio and MSBuild as well? We NEED that clean separation for clarity. So, if indeed, the trend is to only do npm, then I’m going to be searching for a way to install application npm modules in a completely separate structure from environmental npm modules. If I ever switch to something other than npm for a build tool (I mean, hey, the JS world is volatile, folks), then I’m going to want the portability that separation provides. If everything lands in node_modules, then I would have to start adding .gitignore lines for every build tool folder.

Going strictly npm will risk sacrificing organization for tool reduction. Not to mention the thousands of bower_components in use that will never be ported over to npm, forcing you to use it anyway. It also assumes that node.js is the end. We will never have anything else. Like I said, quite presumptive. I prefer separation, just as a preparedness policy.

Your Answer

Review Your Answer