Bower.
It was awesome, but sadly, it hasn’t been a very loved term in web development in recent years.
What is Bower?
Bower is a dependency manager and downloader. Like any good package manager, it supports a configuration file which specifies each dependency with an optional version constraint. It uses a package registry, as was all the rage. It was contemporaneous with npm.
If there was npm, how did Bower fit in? Initially npm, as the full name “node package manager” denotes, was intended for nodejs, not browsers. Bower was the package manager for javascript in the browser. In those days, transpiration and bundling was not yet widely propagated (may not have existed at all?).
You see, there is a dividing line. NPM packages do not work directly in the browser; they need to be compiled into a bundle, which is then loaded into the browser. NPM packages also need to be carefully built to not rely upon nodejs features absent in the browser JS environment.
Bower packages, however, are built to run in browsers.
Another differentiation is that bower packages are “flat” – all installed in the same directory – and minimal while npm tends to be nested and expansive. Any transitive dependencies (a dependency of a dependency) in Bower are installed in the same directory but may be installed in sub-directories within the package dependency itself.
Bower packages are always pre-built, npm packages may be built when installed. NPM packages may also have native binary components which depend upon building binary components with a c compiler and the like. Of course binary components cannot be used in browsers. This is really just to note that (a) npm package space includes non-browser packages and (b) npm package installation and OS requirements are generally greater than that of Bower packages. (Of course it is possible to design a simple, pre-built, browser-specific npm package.)
Bower Problems
The glaring with using Bower today, and frankly the last few years, is that the project has been abandoned.
…psst! While Bower is maintained, we recommend using Yarn and Vite for front-end projects. Read how to migrate!
This is largely due to the rise of transpiration and bundling technologies for browser-based web apps. This has allowed npm packages to be included in browser codebases. Other forces have contributed to the utility of bundled web apps - nodejs-based tools may be used to build, format, test, and document a web app project.
Of course, nodejs or even better (imo) other languages like Ruby or Python may be used for tooling.
Anyway, bower continued to work for years after it’s deprecation, although recently the bower registry has either been abandoned or become unreliable (the registry may be replicated, though, which has been done.)
Bower may also be used to install packages directly from a git repository like GitHub, so in this sense it will be usable for the foreseeable future.
Using Bower Packages
Bower packages are both simple and flat, and are designed to be usable directly in a browser. Bower packages may be installed directly into the document root for the web app “site”. Typically all bower packages are installed into a root directory “bower_components” within the document root.
Packages generally have multiple builds available to suit different methods of including javascript in the browser.
The simplest is the good ol’ script tag, using the src attribute.
<script src="/bower_components/my_package/foo.js"></script>
The foo.js “component” is just a Javascript file loaded into the browser. What it does is beyond the scope of Bower - but typically it would add some functionality to Javascript by adding global properties like functions, objects, and other values.
At the time of bower’s inception there was no official module system in browser javascript. However, there was the Asynchronous Module Definition (AMD) “standard” with several implementations including requirejs. With AMD a configuration file is required to identify “modules” that Javascript code may load on demand.
We’ll not discuss AMD here, but note that this is the technique I’ve always used, and is used on this site.
Each module is typically available in a debug and production version. The debug version is simply the original full Javascript file, with comments, designed to be read by humans and computers alike. The production version is “minified” at a minimum, and may be obscured in an attempt to protect IP.
How We Use Bower
- install out of doc root
- tool (script) to copy only necessary components (modules)
- use file references when possible
- name references only for popular libraries used as transitive dependencies by primary dependencies