202 Lotus blogs updated hourly. Who will post next? Home | Blogs | Search | About 
Latest 7 Posts
Composing With Docker
Thu, Nov 2nd 2017 9
Hacktoberfest and More
Tue, Oct 24th 2017 5
Go Evergreen
Tue, Oct 17th 2017 11
Change is in the Air
Fri, Sep 1st 2017 6
Open Source Contribution
Fri, Jun 16th 2017 8
Docker Quick Tips
Fri, Apr 28th 2017 7
Notes in 9: Dev Tools Grab Bg
Tue, Apr 4th 2017 3
Top 10
Custom JSON Serialization With GSON
Mon, Jan 23rd 2017 12
Everything Old is New Again
Mon, Oct 24th 2016 11
Go Evergreen
Tue, Oct 17th 2017 11
Notes in 9: Docker + SonarQube
Wed, Feb 24th 2016 10
Building Java Objects From JSON
Thu, Jan 22nd 2015 9
Scripting Server Upgrades
Fri, Nov 11th 2016 9
Composing With Docker
Thu, Nov 2nd 2017 9
REST is Best
Wed, Sep 17th 2014 8
XSLTProc in the Buff
Thu, Mar 24th 2016 8
Git Squash
Thu, Oct 20th 2016 8

In Defense of Bower
Twitter Google+ Facebook LinkedIn Addthis Email Gmail Flipboard Reddit Tumblr WhatsApp StumbleUpon Yammer Evernote Delicious


Where It Began

Recently, I saw yet another in a progression of people publicly denouncing the virtues of Bower. This time, it came in the form of a tweet from Kent C. Dodds, who is fairly prominent JS developer, who I follow on Twitter and GitHub, after stumbling across him on some egghead.io videos. He’s usually at the front line of the web development side of things, so he’s got a few interesting projects and usually is pretty insightful into the direction of where things are going. Some lightweight stalking (viewing his SO profile) says that he’s a “full stack JavaScript engineer”, which I believe provides some context to Mr. Dodds’s perspective.

The Tweet

I took the tweet with a grain of salt and even refrained from tweeting some snark back (see that Internet? self-restraint is a thing); although that didn’t keep me from musing on comparing tools in my own tweet later on. That’s not to say that he doesn’t have a point, but Twitter’s 140 character limit is a pretty lightweight medium for what is, IMO, a pretty complex comparison.

Mr. Dodds is a rather talented developer whose projects and ongoing efforts are noteworthy, I just felt he may have skipped over a something in the name of progress. What I felt was missing was all the good things about bower. This post explores the relevance of bower, the complexities involve in comparing bower and npm for front-end dependencies, and will not further mention Mr. Dodds after this paragraph; although I will plug his (updated) slide deck on ES6 modules, which came up recently.

Bower, I Know That, Right?

In case you’ve been living under a rock, bower is a package manager meant for web libraries/frameworks. It runs on top of Node and installs via npm. To make a long story short, with bower, you can:

  • install (front-end) dependencies
  • at either the latest, or specified, version
  • save the dependencies to a config file (bower.json)
  • specify the destination (where the dependencies install to, via the .bowerrc file)*

If this is new to you, you can probably see some pretty obvious advantages, such as the ability to keep libraries outside of your application’s project repository (e.g.- exclude from commiting into your git repo), easily install dependencies “from scratch” (by the single config file) on-demand and with consistency. This all plays into the higher order processes involved with build automation and continuous deployment concerns.

Note*: That last bullet above, the setting of the destination path for libraries, is where I think there is a delineation in approach that some chatter of late, around the implementation of dependency management, hinges upon.

If you have been living under that proverbial rock and would like to to see what bower can do, check out this quick (and free) episode from egghead.io, an introduction and setup of bower.

What Other Dependency Management Options Are There?

As many have espoused of late, npm is a package manager, which many use to install bower in the first place. In fact, the npm blog has covered the recent explosion of front-end dependency management and talked specifically about how npm is pretty agnostic when it comes to JavaScript packages, be they front-end or server packages. This should be acknowledged, as I’ve been under an impression that I believe many have (had) about what npm installs, as far as packages.

If I we look at the notes for the phantomjs-prebuilt package on npm, we can see something to support this perception; specifically a note regarding the fact that the phantomjs-prebuilt packages is “npm wrapper”, for installation purposes, and not in any way a “node wrapper”, as it doesn’t expose a Common JS package loader. Again, this is something that npm, strictly speaking, “doesn’t care about”, as it can and will successfully install the package; it just won’t be directly usable via commonly accepted (a la Common JS) require('package-name') statement.

Making use of npm has some advantages, as there have been some significant efforts put into making npm v3’s dependency resolution more robust. They’ve blogged about this topic and it’s worth the read, as they lay out the differences from v2 and how peer dependencies play into things. The dependency resolution abilities are honestly something that’s pretty impressive, especially compared to a “flat” dependency tree.

I’ll also highlight that not everyone that uses bower uses node as their back-end. In fact, it’s my belief that the majority of the holdouts not jumping ship off the bower boat are those that aren’t using Node for their back-end, at least in production. This is certainly how it works for me most of the time at the day job, as the only real usefulness the added tooling gives me is a configuration and automation over the manual effort of downloading a given lib’s assets and installing them into a given project directory. If you’re using Node as your back-end, using npm and something like browserify (or webpack, jspm + system.js, etc.) makes really good sense to me, especially as you’re already investing into the dependencies contained within node_modules beyond development tooling.

So, does “using npm” give you as much and more than bower? I’m actually inclined to agree, but there’s the caveat of if you need/want/will-use those features; if not, bower does a perfectly decent job with little fuss and shouldn’t be vilified.

Using NPM To Load Front-End Assets

I’m accustomed to using gulp for some of my tooling, which makes use of wiredep to find the specific html comments in my index.html to dump in my known CSS or JS files (from bower.json). This also makes it easy to have a placeholder for the distributable version of the libraries, when it comes time to ship to production (after a concatenation of the minified libraries into combined vendor libs). This is convenient and relatively easy to adopt and follow.

Choosing to use npm for all your project dependencies has the merit of eliminating yet another package manifest. If you’re using Node based tooling, you (should) already have and be storing your package.json with your repository.

To proof out a bit of the “npm path” as far as managing front-end dependencies, I threw together a simple and straight-forward comparison project, which you can find on GitHub. It doesn’t use gulp or grunt, but rather relies on the npm run scripts, defined in the package.json. This should help to reduce some of the potential complexity for people just looking to try it out.

Using npm for front-end dependency management is about as simple as installing the dependency as you would for any npm package, and saving it to your package.json. Since these are direct dependencies to be used by your application, they should be saved to the “dependencies” block, not the “devDependencies” block. This is done via either npm install --save <package-name> or npm i -S <pkg-name> for those who like abbreviated commands. Once done, the dependencies won’t exist in a separate bower_components directory, but rather the node_modules directory, as anyone with any experience installing packages via npm would expect. As far as the file tree goes, this is an equivalent level of things, so to directly use the libs, they must be referenced to (in development) a “level up” above an assumed app/ or src/ path inside the main project directory (at an equivalent level); aka- <script src="../node_modules/bootstrap/dist/js/bootstrap.js"></script>.

Here’s the thing, if you’re like many developers out there, thats’ exactly how the folder tree would match up with your bower_components relative path. For those of us that work on rather specific/proprietary application stacks, we may have gotten sloppy at some point in the past and, instead of doing it this way, relying on something (a task runner or build/dev pipeline of some sort) to copy or build the dependencies into the production (aka- dist/) path for non-development use, there may be some people out there configuring their installation path to something else. In fact, it might look a lot like an edit to the .bowerrc file, in which a person can specify a different destination/install directory from the bower_components default. This is also why many people out there may not see the obvious disconnect between bower and npm for front-end dependency management, as this alternate install path can make things pretty analogous to an automated method by which to install packages. The example I linked to can/does run on a server (Domino server with the XPages runtime) that allows for full concatenation and minification of client-side assets, so doing it this way doesn’t make much of a difference. Doing it this way means that you can just pull in any asset by the usual lib/some.js approach and continue with your development without any hassle.

In any case, I’m going to assume we’re not using the above outlined, non-standard destination path for the bower install, so this should keep things pretty analogous. It also means that you’ve been a good developer and optimizing (all) your client-side assets. If that’s the case, they which folder you keep them in is pretty irrelevant, the only question becomes how to load them into your front-end. We definitely do not want to expose our node_modules path to the whole web and any traffic that comes through, as even if you’re only using node_modules to store client-side assets, it’s such a horrific concept that I’m not going to take it as a viable option. It also means we need a way to load up these assets, or “copy them” to our distributable app path.

Module Loading… in the Browser

If you’re not accustomed to them, now only has there recently been an explosion of front-end and JavaScript frameworks/libraries/utilities/etc. We’ve seen the rise of TypeScript and ECMAScript6 usage, the latter often enabled via a transpiler like babel. With the exception of ES6 which does have 90%+ support from the latest builds of Chrome and FireFox, a transpiler is required for full compatibility amongst the usual browser crowd; as well as necessary for TypeScript in the first place. Since many more advanced front-end frameworks now require some combination of these things, that means that we can reap the benefit of their efforts.

There are tools out there, like browserify, webpack, and others, which seek to aid us in our dependency loading tasks. I’m presently most familiar with browserify (which does a good job of giving us access to our dependencies via a simple require statement, just like we would on a Node back-end), but we’re concerned with the front-end, the browser. The example and tutorial for Angular 2 makes use of system.js, which aims to have some pretty compatible loading capabilities for use in the browser. It’s loaded like any normal JS file, it’s configured with a base url (path to the dependencies), and receives the dependencies via an import command. It lets you specify a transpiler, such as babel (and the Angular 2 tutorial with TypeScript makes use of it), to hook in at the right points and make things easier for us. All in all, we have plenty of options, and I’d love to see the dust settle on this battle of the tools, but I also would prefer to advance my skill set sooner, so I’m picking one (okay two) and going for it.

Making Sense of When to Use What

As I mentioned, if all you’re looking to accomplish is dumping some front-end libraries into a given project (or application) path, then bower can achieve that pretty easily, configured through its bower.json to define dependencies and .bowerrc for the path (if you’re putting it out directly to your app path). The comparison of the two looks, to me, to hinge upon the tenant that we shouldn’t be dumping our front-end libraries directly into our application path. Using minified CSS and JS is good, but there’s a threshold at which the quantity of network requests incurred is too high of a tax on browser/DOM load times and performance, leading to the inevitable conclusion that a build pipeline or task runner is necessary, to optimize those assets to their fullest. If we take that as granted, then the source of our dependencies is irrelevant, so we should embrace the best tool for the job.

What the comparison of bower with npm should highlight is a couple of specific things:

  • listing our dependencies in a file (bower.json or package.json) is relatively irrelevant
  • so much of the future of JavaScript is within the use of ES6/+ and/or TypeScript and component driven frameworks (like Angular 2) in which the CommonJS / module format being the standard
  • tools like browserify and webpack (and more) make the task fairly easy, regardless of how much you do or don’t use a task runner or otherwise


It’s my belief that if you’re resistant to learning something like how npm can play into front-end dependency management, that “a little learning can go a long way”. It’s not “better” for every use case, but it certainly opens the doors for most use cases going forward. Bower does a good job of accomplishing what it set out to do, it’s just not the only tool in town.

Until next time, write better apps! :beers:

Jun 14, 2016
4 hits

Recent Blog Posts
Composing With Docker
Thu, Nov 2nd 2017 2:00p   Eric McCormick
Background About a year ago, I blogged on automating server upgrades with Docker and a BASH script. This met the needs I had at the time, and worked itself out to be pretty stable. But, since I think about such things and always question my preconceptions, I went down a path of creating a Docker compose config file, something I wouldn’t have had to create from scratch by waiting a little while as one appeared as an example from GitLab. As it turns it, it was a great learning experience regardl
Hacktoberfest and More
Tue, Oct 24th 2017 2:00p   Eric McCormick
Hacktoberfest 2017 October brings many good things with it. It’s the beginning of autumnal colors here, along with some yard raking in my case. It also brings with it not just Oktoberfest, but Hacktoberfest! Hacktoberfest 2017 Hacktoberfest is a month long open source support initiative, sponsored by Digital Ocean, partnering with GitHub. It’s meant to promote open source involvement and contribution. As added incentive, if you meet the criteria, you can get a free t-shirt (and stickers).
Go Evergreen
Tue, Oct 17th 2017 4:00p   Eric McCormick
Happy 🎂 Day IE 11! On the 17th of October in 2013, Internet Explorer 11 was released from Microsoft. That means that as of today, this popular* browser is now four years old and, with all respect to it, it really ought to go. Good day sir. I said good day! Evergreen Browsers What makes a browser, or any software for that matter, evergreen? Well, the basic requirements for a browser, or any piece of software for that matter, are specifically the support of automatic updates, that bring in:
Change is in the Air
Fri, Sep 1st 2017 1:00p   Eric McCormick
I’m Back What Can I Say? In Case You Missed It If you find yourself asking “where was Eric?”, this should summarize it all: Instead of trying to do everything all summer, I tend to take a break from blogging and a lot of open source endeavors over the summer. It means I can focus on family time along with yard and house projects. Ah... Summer That’s all paid off and, with fall fast approaching, I’ve found myself wanting to start those things back up; ramping up into winter when
Open Source Contribution
Fri, Jun 16th 2017 5:00p   Eric McCormick
Intro It’s time to clear some of the backlog. I started this post a few months back and it should probably be sent on its way to clear the pile of drafts I haven’t finished yet… 🤔 I have a bit of a passion for open source software. My preferred distribution of Linux has been Ubuntu since 4.10, the Warty Warthog (I was even a minor contributor on a short lived, wildly popular project that aimed at improving the Ubuntu experience early on), I’ve enjoyed most open source projects I’ve
Docker Quick Tips
Fri, Apr 28th 2017 3:00p   Eric McCormick
Docker If you have been living under a rock, Docker is pretty much amazing. If you haven’t been living under a rock, you may be getting used to the idea of Docker, but still have the occasional question. I’ve found myself using Docker in increasing amounts and complexity over the last year or so. I’ve recently decided to start recording some of the tasks I’ve found useful, some of which may be less familiar to a beginner. If you’re so inclined, check out the playlist, embedded here.
Notes in 9: Dev Tools Grab Bg
Tue, Apr 4th 2017 1:00p   Eric McCormick
Intro I’m on Notes in 9 again, with a “grab bag” of a couple of tools I’ve put together recently that may be of a varying degree of useful for other Domino + XPages developers. You don’t need these to do development, but for the right person, they may help with their development workflow. Also of note, with the upgrade to Swiper with the FP8 release of Notes + Domino Designer, the limitations previously mentioned are no longer there! This means that my second tool I talked about, node-
Custom JSON Serialization With GSON
Mon, Jan 23rd 2017 2:00p   Eric McCormick
Intro Here’s a curious one, in which I found myself with a limitation of not being able to output JSON with scientific notation values. wait, what? If you’re wondering why that is, since both JSON and JavaScript allow scientific notation of number values, you are absolutely correct and that’s a great question. The strange thing was that I found myself outputting perfectly valid JSON to be consumed by something specific which didn’t allow scientific notation. I’m not entirely sure wh
Recapping 2016
Mon, Jan 16th 2017 3:00p   Eric McCormick
Intro Per usual, I’ve had a little break between things and decided to catch up with a bit of a summary of some recent things that each didn’t necessitate their own post. 2017 IBM Champion For starters, I’m honored to be named an IBM Champion in Collaboration Solutions (/ Social Business) for the third time. This would be a hat trick in (ice) hockey 🏒. I’m happy to be recognized with a group of people, developers and more, who are passionate about both their work and the plat
Rebirth: An App of Ice and Fire
Wed, Dec 14th 2016 4:00p   Eric McCormick
Intro If you read my blog for any of the Saga of Servlets series, then I hope that you’re excited I’m returning to the application I put together for it. This time, it’s as a conversation piece in regards to some of the build process modernization I engaged in recently, in order to unify the code base in its git repository. In any case, it’s helping pave the way forward before I update some of the back-end elements, when it will again be a talking point for some additional rework and

Created and Maintained by Yancy Lent - About - Planet Lotus Blog - Advertising - Mobile Edition