|Latest 7 Posts
| Go Evergreen|
Tue, Oct 17th 2017 83
| Change is in the Air|
Fri, Sep 1st 2017 2
| Open Source Contribution|
Fri, Jun 16th 2017 3
| Docker Quick Tips|
Fri, Apr 28th 2017 3
| Notes in 9: Dev Tools Grab Bg|
Tue, Apr 4th 2017 1
| Custom JSON Serialization With GSON|
Mon, Jan 23rd 2017 6
| Recapping 2016|
Mon, Jan 16th 2017 7
| Go Evergreen|
Tue, Oct 17th 2017 83
| Building Java Objects From JSON|
Thu, Jan 22nd 2015 11
| Manually Renewing HTTPS w/ Let's Encrypt|
Wed, Jul 27th 2016 11
| Server REST Consumption with Authentication|
Mon, Aug 18th 2014 8
| Notes in 9: Docker + SonarQube|
Wed, Feb 24th 2016 8
| Using Node to Connect to ... Almost Anything|
Mon, Apr 18th 2016 8
| Rebirth: An App of Ice and Fire|
Wed, Dec 14th 2016 8
| A Few ConnectED Thoughts|
Thu, Jan 29th 2015 7
| Headless DDE Builds With Jenkins CI|
Fri, Mar 25th 2016 7
| SCM Survey Results|
Tue, Apr 12th 2016 7
||In Defense of Bower
Where It Began
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 (
- specify the destination (where the dependencies install to, via the
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 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)
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.
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
src/ path inside the main project directory (at an equivalent level); aka-
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
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 (
package.json) is relatively irrelevant
- 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
| Recent Blog Posts
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
Mon, Jan 16th 2017 3:00p Eric McCormick
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
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
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.
I had p
Everything Old is New Again|
Mon, Oct 24th 2016 8:00p Eric McCormick
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