193 Lotus blogs updated hourly. Who will post next? Home | Blogs | Search | About 
Latest 7 Posts
Custom JSON Serialization With GSON
Mon, Jan 23rd 2017 8
Recapping 2016
Mon, Jan 16th 2017 12
Rebirth: An App of Ice and Fire
Wed, Dec 14th 2016 4
Scripting Server Upgrades
Fri, Nov 11th 2016 7
Everything Old is New Again
Mon, Oct 24th 2016 5
Git Squash
Thu, Oct 20th 2016 7
MWLUG Success
Wed, Aug 24th 2016 10
Top 10
Building Java Objects From JSON
Thu, Jan 22nd 2015 16
Git History Searching
Tue, Jul 12th 2016 12
Recapping 2016
Mon, Jan 16th 2017 12
Blue Chalky Soup
Mon, Feb 2nd 2015 11
House Keeping
Tue, Feb 23rd 2016 11
Fixing Dojo 1.6.1 in Domino 8.5.3
Tue, Sep 2nd 2014 10
When You Need a Comparator
Thu, Jan 8th 2015 10
MWLUG Success
Wed, Aug 24th 2016 10
Server REST Consumption with Authentication
Mon, Aug 18th 2014 9
Redmine, CodeRay, and Domino, Oh My!
Mon, Aug 11th 2014 9

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
6 hits

Recent Blog Posts
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
Scripting Server Upgrades
Fri, Nov 11th 2016 2:00p   Eric McCormick
Intro This one might be slight departure from my usual, but those that have followed my blogging this past year will have noticed a bit more of a leaning towards DevOps in some of my posts. This echoes a lot of what I’ve been concluding as increasingly a necessary part of development; that we need to consider a picture large enough to encompass the themes surrounding development functions and, like any good developer (DRY ~= “lazy”), automate the heck out of it. Overview I had p
Everything Old is New Again
Mon, Oct 24th 2016 8:00p   Eric McCormick
Intro Every so often, it’s good to reassess one’s position. This is good from both a standpoint of being inquisitive and even interrogative, but when it comes to the ever changing landscape of the front-end development space, it’s not only inevitable, but must be embraced for what feels the need to “stay afloat”. I’m changing theme of my blog, hopefully for the better. The previous theme was good and did a great job of getting things started, but while I had forked a copy of a good
Git Squash
Thu, Oct 20th 2016 8:00a   Eric McCormick
Intro If you’re just here to learn a little about how to “squash” commits with git, skip down a ways. Otherwise, hold on, and I will catch you up on a couple of personal notes before we get there. On the Blog It’s been a little while since I blogged last. This has been due to a combination of reasons; specifically, I’ve been busy with: my family, it was the end of summer with lots of things going on a number of projects around the house (a deck removal and basement remodel
MWLUG Success
Wed, Aug 24th 2016 8:37a   Eric McCormick
Intro MWLUG was a great success as far as I’m concerned. Each time I’ve gone I’ve had the great enjoyment of being able to attend some high quality sessions, meet with lots of colleagues and friends from the community, and get a view into products and solutions many people are undertaking, over conversations and interactions outside of the sessions. This is always a great way of interacting with others who were able to make it. Unlike the IBM conference of Connect(EDsphere), this is purel
Manually Renewing HTTPS w/ Let's Encrypt
Wed, Jul 27th 2016 10:40a   Eric McCormick
Intro A while back, I rolled a personal project, which is a Node app, to Bluemix for lightweight use. I managed to make use of Let’s Encrypt for the HTTPS certificate, but only after realizing that there was a bit of a manual aspect to it that is the antithesis of an automated script for such things. Ultimately, after finding some information in a blog post form Marky Roden (of all people), I was able to get moving. The only downside wound up being that time passed, and it came time to renew
Eric and the Quest for More Coffee, pt.2
Fri, Jul 15th 2016 4:17p   Eric McCormick
Posted in the “aside” category. Submissions There were three submissions via the Google Form, and a couple more form messages via social media. Honestly, I had debated either a nondescript or far more overt mug w/ the likeness of one of the more iconic of H.P. Lovecraft’s imaginations, but this seemed a bit over the top. Suggested were: a replacement for my alma matter a Go Army, Beat Navy mug (which was never my thing) this gem from shop.Scotch.io (again, pretty overt)
Git History Searching
Tue, Jul 12th 2016 10:00a   Eric McCormick
First, A Shout-Out The recording of the session called “Normalizing XPages Web Development” that Shean P. McManus and I gave at the 2-day, virtual ICONUS (formerly IamLUG) event this year is now available from “Archive and Replays”. If you missed it, I recommend checking it out, it’s a great benefit of ICONUS and I hope that those who did get a chance to attend enjoyed the subject material. We covered a lot of ground and were able to demonstrate what is, in my opinion, one of the grea

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