When comparing npm + Browserify vs Bower, the Slant community recommends npm + Browserify for most people. In the question“What are the best open source front-end package managers?” npm + Browserify is ranked 1st while Bower is ranked 5th. The most important reason people chose npm + Browserify is:
If you're using node.js as your backend, you gain a lot of flexibility by using the same package manager for the frontend and backend, making it much easier to share code without adding one more tool to an already large toolbase.
Ranked in these QuestionsQuestion Ranking
Pros
Pro Best way to share code with the backend
If you're using node.js as your backend, you gain a lot of flexibility by using the same package manager for the frontend and backend, making it much easier to share code without adding one more tool to an already large toolbase.
Pro Huge active ecosystem
Npm gains a lot from its large community, and the activity from node.js gives npm the largest set of active repositories. Since so many people already use npm, chances are the library you need has already been added to npm, and many new authors are writing their libraries with npm in mind.
Pro Client side shims provided by Browserify
Browserify provides client side versions of non I/O related built in npm modules. This allows you to use the path manipulation, crypto, and zip libraries on the client side.
Pro Support multiple bundles
Browserify allows splitting up bundles among multiple pages to get the benefit of caching for shared, infrequently-changing modules, while still being able to use require().
Pro All modules must implement CommonJS modules which leads to cleaner dependency management
Because all npm modules need to follow the CommonJS format, it's much easier to set up dependencies through the require function.
Pro Easy to create bundles
Because of the nature of Browserify, it's easy to require
different dependencies and concatenate them into one minified file.
This helps with performance and load times, especially for mobile devices.
Pro Can also flatten the dependency tree with dedupe
npm dedupe lets you flatten the dependency tree.
Npm has a very handy dedupe tool. What this tool does is that it checks the dependency tree to find modules that depend on third dependencies. If a suitable version for all modules exists, it keeps that version and deletes any other versions that are not needed.
For example, in this dependency graph:
a
+-- b <-- depends on c@1.0.x
| -- c@1.0.3
-- d <-- depends on c@~1.0.9
-- c@1.0.10
dedupe will transform it to:
a
+-- b
+-- d
-- c@1.0.10
What it did was to make sure that both b
and d
got their dependency met by a single c
module. It then deleted all the unneeded versions of the c
module.
Pro Browserify shim allows you to use non Common JS formatted packages
Browserify shim is a transformation extension for Browserify that lets you load in libraries that do not follow the Common JS structure (using an exports module). This allows you to explicitly define what globally defined variables should be exposed by a require
statement so you can control how you load in these poorly formatted libraries safely without polluting the global scope.
Because the Common JS style loads in required libraries within a closure, any variables defined in a library will not pollute the global scope. Browserify shim lets you define which variables defined within that closure to map to the exports
variable that Common JS expects in a safe and explicit way through declarations in your project's package.json
file.
Pro Can include HTML, CSS and images as well
Packages hosted with NPM do not include just JavaScript. Other assets, like static ones (HTML, CSS and images) are included.
Pro Manages non-JavaScript components
Bower is flexible enough that you can manage pretty much any package you would need on the front-end, so you can manage all your dependencies with one tool, including CSS, boilerplate, fonts and more.
Pro Simplicity provides more flexibility
Bower doesn't try to handle too much of the workflow process, which means it's more flexible, and can be incorporated into more workflows. It tries to just do package management well and nothing else, which is why so many workflow wrappers support it. Because it doesn't try to do too much vertical integration, it also means that the list of supported components that it manages is huge.
Pro Largest front-end specific package registry
Although npm is the largest javascript package manager, Bower is the most popular one built specifically for the front-end. With over 16000 components in its registry, pretty much every component you can think of is supported.
Pro Easily integrates with other tools
Because of Bower's focus on simplicity, it makes it much easier to integrate with other tools, so it has a wide range of support with workflow wrappers and task managers such as yeoman and grunt.
Pro Requires a flat dependency tree
While nested dependencies are better for backend modules that need lots of inter-dependency, they lead to bloated file sizes. Flat dependencies are better for frontend optimization, where file size needs to be more closely managed.
Pro Does not store components in a registry
You always get package directly from owner's repository, i.e. you will always get latest version as soon as its version tag is committed without need of waiting until owner publishes updated package.
Pro Simpler to manage varied code
Because Bower makes few assumptions about the source and format of packages, it's easier to apply it to more of your packages
Pro AMD & CJS compatible
Bower strives to be as simple of a package manager as possible and puts as few restrictions on the packages in the registry as possible, making it the most flexible package manager with the most potential packages.
Cons
Con Familiarity with Node is required
Browserify's documentation assumes that you have some familiarity with Node before starting to work with it. Some methods are not explained very thoroughly and others are assumed to be already known by the developer.
For example, Node's module.exports
is not explained, it's just mentioned that browserify modules can be exported using it. Which is fine, but for a developer not used with Node, or a front-end engineer that has never used Node it can be confusing.
Con Does not guarantee reproducible builds
Con Needs to create a bundle in every change
That makes debugging more difficult and requires extra time to create the bundle again for every change.
Con Post-install scripts
Packages shouldn't need post-installing. They should be an enclosed unit. This is another potential attack vector.
Con Potentially hijacked and malicious packages
Con Seems like a redundant package manger
NPM with Webpack/Browserify can handle all the dependencies for both back-end and front-end. The only place where Bower may be useful is for projects which use libraries not supported by NPM, such as Polymer.
Con Deprecated
As of May 2017 Bower has been deprecated and will not receive any updates with new features. Bugs will still be fixed though for existing projects that use Bower.
Con Does not store components in a registry
Bower installs components directly from urls and repositories, which makes it more susceptible to components being taken down, with fewer guarantees about their availability.
Con Difficult to create bundles
To create a minified bundle of all the required JS dependencies other tools need to be used.
For example a JavaScript task runner which will automatically concatenate JavaScript files and minify them will be needed. Although it's done automatically, it's still extra work because the task runner needs to be configured.
Con Lack of signing of packages on the repository
Anyone can register their package on Bower's GIT registry - on one side, this brings a lot of ease to developers, but on the other hand, this can lead to security issues because the packages are not signed.
Con Less packages than npm due to a smaller ecosystem
- Bower: 36,000 packages
- Npm: 161,876 total packages (of course, many work only on the server)