❄ powdahound

Nerd on skis.

Analysis paralysis and the Node.js ecosystem

22 January 2015

For the past 5 years @SquawSnow has been sending out a tweet whenever it snows at Squaw Valley (which is not often enough these past few years).

This was done by a PHP script that scraped Squaw’s snowfall tracker every hour to check for changes. But last month I was looking to build something “real” in Node and decided that rewriting this script would be a good place to start.

Node noob

I’d never built anything in Node before. In fact, the last time I did serious JavaScript work was in the days when we still had to consider IE6 (ugh). But I figured it wouldn’t be too hard to get a basic project set up, especially since I didn’t need the power of a full framework. I was quickly slowed by the ~120,000 npm packages, multiple async styles (classic callbacks, fibers, ES6 generators), and an overwhelming feeling of choice. These are signs of a rich ecosystem and progress, but I was overcome with analysis paralysis.

Analysis paralysis is the state of over-analyzing (or over-thinking) a situation so that a decision or action is never taken, in effect paralyzing the outcome. (Wikipedia)

It’s natural to want to do things “the right way”, and I just kept thinking; Is this package already outdated? Is this random person on GitHub actually maintaining this package? Will X play nicely with Y? What would someone experienced use here? Didn’t I just read something about a fork of Node that was going to progress even faster?

Perhaps this is just typical of all newer languages/frameworks and I had false expectations about Node feeling more mature given its popularity. Turns out that the Node ecosystem poses a challenge for some experts as well:

It’s easy to see all of these new things flying by, combined with changes to JavaScript itself, and feel completely overwhelmed. To be honest, over the past two years, even as a maintainer of Ember, I have experienced very serious hype fatigue.

— Yehuda Katz of Ember.js/jQuery/etc on HN discussing The State of JavaScript in 2015 (worth a read)

So maybe that’s just the way it’s gonna be. Time to make some choices and start coding.

Making choices

After a reading a few tutorials and opinions I decided a few things:

  1. I’d use Node 0.11x invoked with the --harmony flag for ES6 for generator support (details). After using Twisted’s deferred.inlineCallbacks for years I can’t imagine returning to callback hell. And flow control libraries like async still feel dirty to me. Language-level support is where it’s at.
  2. Koa looked like a nice basic web framework to start with.
  3. Heroku would make a nice host since they support Node well.

It works!

And here’s the code: https://github.com/powdahound/squawsnow

It really doesn’t do all that much, so didn’t take too long to put together. The hardest part was probably figuring out which external packages were going to play nicely with ES6 generators/Promises for Koa. There are surely things I’ve done wrong but it’s in the wild and I learned a lot along the way. If this project were of more importance, this might even be one to throw away.

Now I wonder how things will change before my next Node project…