The Node.js Revolution, or: How I Learned to Stop Worrying and Love the Node

16 Apr

Hello, Node!

As a self-admitted JavaScript lover, I was neither surprised nor disgusted (as some JS “haters” were) when I first heard about Node.js bringing server-side JavaScript to the masses!  Running on top of Google Chrome’s V8 JavaScript engine clearly gave it an advantage not shared by its predecessors like Microsoft’s JScript (atop the Windows Script Host) and Mozilla’s Rhino.

That said, I investigated Node.js early in its life and the stability I was seeking from it in order to utilize it for enterprise-level production-ready server-side JavaScript (for a purpose very similar to the one outlined by David Padbury on his blog) was simply not there yet, especially on the Windows platform.

And so I shelved looking at Node for about 9 months.

Nine Months Later…

Perhaps Node.js was pregnant unbeknownst to me when I left her… because when I returned to my abandoned fling 9 months later, I found that she had given birth to a great many new and wonderful things!  Weird analogies aside, what I hadn’t noticed happening due to my absence from the scene was that many strong JavaScript developers in the community had rallied around Node.js.  Eager for a reprieve from the web-based world where JavaScript was bound by browser incompatibilities and inconsistencies, they happily brought their skills and ideas to the beautifully browserless world of Node.js and began to form an incredibly rich and thriving ecosystem around it.

While existing tools like PhantomJS and Esprima became even more useful than before, many new tools — Mocha, BusterJS, node-cover, and coveraje, to name just a few — came into existence to improve upon existing but stale tools (e.g. JsUnit/QUnit/Jasmine, JSCoverage).  More recently, Grunt, a promising new build tool for front-end projects was released, again built atop Node.js.

Also, having a completely server-side environment also drove home the importance of JavaScript’s lack for modules, and so CommonJS and Asynchonous Module Definition (AMD) were both solidified as a result.

What Does It All Mean?

The Good:

  • I think the new libraries and tools created as a result of the Node.js revolution are amazingly useful — but better yet, even though most of them were created for use with Node.js, they still apply (or have been retrofitted to apply) to the traditional browser-bound world of JavaScript as well.
  • Having CommonJS and AMD for module specs is great!  In fact, I actually prefer AMD over ECMAScript Harmony’s proposal for native module support.
  • Node.js has rallied the JavaScript community to band together again as professionals doing cool stuff as a collective group.

The Bad (or Regrettable):

  • Unfortunately, it seems that many of the JavaScript world’s best and brightest have almost completely abandoned the frustrating traditional browser-bound world of JavaScript in favor of the unshackled browserless world of Node.js.  While this is good for them as individuals and for the Node.js community, I can’t help feeling that it is also a loss for those of us still fighting the never-ending battle with client-side JavaScript in a world of incompatible, inconsistent browsers.  That said, again, we have still seen some residual benefits in the form of new libraries and tools that apply to both worlds.

So what do you think about the Node.js Revolution?


One response to “The Node.js Revolution, or: How I Learned to Stop Worrying and Love the Node

  1. Kamran Ayub (@kamranayub)

    2012-04-17 at 8:47 AM

    I’ve played with Node and found the Windows experience sub-optimal, that was a few months ago. I switched to playing with it on Ubuntu and it was much better there. It wasn’t necessarily the fault of node, it was mostly the fault of not-as-sexy command-line interfaces in Windows. I want all the colors, damn it!

    I think client-side JS will still be important even to Node developers because template engines and some libraries are being targeted both for Node and the browser.

%d bloggers like this: