The end is nigh for Bower?

by Doug Niccum

Over the last four or five years, I have come to have a deep adoration for the front end package manager Bower. Going to the official jQuery or Angular repositories to download dependencies was a thing of the past. The even deeper integrations with scaffolding tools like Yeoman even made the attraction even more irresistible. The fact I could build a basic project with a couple shell commands just blew my mind the first few times.

Now that Angular 2 has finally been released and is no longer in the purgatory of beta or release candidate, I am starting to see a trend with the support of public projects and the technologies that supports them. This trend is that these new projects are not supported by Bower.

While I would like to note that these trends are somewhat specific to brand new projects like that of Angular 2 and Ionic 2. Projects like Angular 1 and Ionic 1 that are currently being maintained, though not improved, are still supported with Bower compatible packages; I digress...

But why would I be thinking about this? Is there something that Bower did wrong to seal it's demise? I have a few ideas.

It's a NodeJS package

So what if it is a NodeJS package? We use helpers like Grunt and Gulp all of the time to process code and to make our lives easier as developers. Why would Bower be any different? Here's my theory: because it is a required dependency to install further dependencies with its own set of shell commands; automation in other words.

When working with CMS applications like Adobe Experience Manager or even platforms like Laravel (PHP-based), these tools ship with scaffolding tools or provide a tool for you to create your own. The majority of these assets require you to use Node Package Manager (npm) to install and run their associated dependencies. It has become so common that it is second-nature for us as developers to clone a repository and then run $ npm install. Configuring AEM to run this command isn't very hard either. The issues that I can identify lies in the fact that:

  • Bower downloads is packages differently than NodeJS does
  • It has a different set of configurations and requires additional files to apply these configurations
  • It is discouraged to store your Bower-related files or bower_components in the same place as your node modules. Bad things start to happen when you do

Each of these points could become troublesome if you are trying to develop in an existing ecosystem that was never designed to support Bower.

Additionally, in most instances you have to have Bower installed globally on your machine. If not, for instance it is a dependency of your NodeJS application, then you are limited to calling the Bower command like so:

/usr/local/bin/bower install

Now you are liable to manage two different sets errors and feedback. And as I pointed out earlier, if this Bower project has been automated, debugging these errors can be troublesome.

The lack of updates

If you look at the Bower repository release page, you can see that the platform hasn't been touched (at the time of this article being written) since April. A platform that was as widely used as this, and when you throw in the recent macOS update of Sierra, the lack of updates should come as a bit of an alarm to you.

No new project adaptation

As I said above, if you are familiar with Angular 2, Ionic 2, or even Zurb's Foundation, currently none of these projects have developed Bower components. It is also worth touching on that these three projects also have a corresponding command line interface (CLI) to be able to initializes or compile its assets. As you would expect, these CLI's using NodeJS to install their dependencies. With not relying on Bower to install their dependencies applications such as these can scaffold a project without having to call additional shell commands; resulting in both supplementary speed and stability within the applications.

Just a few thoughts

As I draw this techy rant to a close, keep in mind that I am basing my conclusions purely off of observations and some basic research. I proudly disclose that I have not spoken to the Bower guys about the longevity of their project, or do I have any usage metrics to show a decline. Again, just a few thoughts that I tied together into a hypothesis. For all I know, Bower could be alive and well.

But nevertheless, we as developers have to take note of this evidence and begin to make decisions when we are scaffolding a new project or making enhancements to existing projects.