Howardism Musings from my Awakening Dementia
My collected thoughts flamed by hubris
Home PageSend Comment

My Node.js Perspective

After spending more than ten years creating web applications in Java, I finally chose to build one using Node.js, and thought I'd share the results… especially since I keep running across various perspectives on Node-base projects.

First a bit of background on the purpose and requirements for the project.

I was given a team of junior engineers in China, with Java experience. In fact, except for one engineer, Java was the only language they knew. (Yes, graduating software engineers who only know one computer language continually stuns and amazes me).

In order to guarantee continued funding, we scheduled the project's alpha release three months after we began. This would challenge a team of seasoned veterans, much less my young team.

Some of the requirements for the product were:

  • Work on mobile devices and desktops alike
  • Interact with user dynamically (like a real desktop application)
  • Run in the same cloud it'd control

Oh, and I'd also have to teach them Agile development methodologies. I admit, I didn't have much hope.

Why on Hell?

With the requirement of a dynamic web application that could work on an iPad, clearly we'd be building a JavaScript client application. So I'd have to teach some of my engineers JavaScript.

With a short development cycle, I didn't want my team to spend precious cycles with Java ornamentation and the all-but-impossible-to-troubleshoot Spring configurations. Scripting languages, even on the server, are good choices for prototype projects, so which language/framework should I choose?

While I would like to have chosen Groovy, Ruby was a better choice, since the other back-end teams chose to work with the same language as Cloud Foundry.

Choosing Ruby would meant that I would have to split my team into the front-end JavaScript team and the back-end team… but not if I chose the same language for both.

Yep, that was the final piece of straw that swayed us.


We flew to China to meet and train our teams. The main points to my lessons were:

  • You don't know JavaScript. You must learn JavaScript.
  • Asynchronous and functional programming is different.
  • Our only savior will be automated tests.

After teaching them Agile development, Git, and REST, I began with a short history of JavaScript shamelessly stolen from Mr. Crockford. I even made them all read his book, JavaScript: The Good Parts. However, I knew that the asynchronous nature of Node would prove a challenge to engineers with a deficient education (I don't blame the Chinese universities, as it seems that American universities are churning out poor graduates as well).

I've always believed the best way to learn is to teach, so after each scrum, we'd alternate teaching each other a new concept. We called them 10 Minute Sharing episodes, as the time-limit needed to be in the title.


I next built out a JavaScript-oriented infrastructure, which is something that Java developers take for granted, like:

A young technology, like Node.js, surprised me with such a mature community of support.

Many of the deficiences found, I easily remedied by either forking and fixing projects (like updating Mocha) or wrapping them up in a new project (like jake-utils and node-idocs).


Simply put: We made our alpha release with few bugs, and acceptable performance metrics. Our unit tests covered 100% of the code. The product even looked good.

Sure, the passion and eagerness of my team key, but I also attribute Node.js for part of the success.
Code written in Node is considerably simpler than client-side JavaScript, and with easily written unit tests, we often refactor initial code to more straight-forward solutions.

Keep in mind:

  • Variables in a node module are not global, so data abstraction is a given.††To make a variable or function available to other modules, you have to explicitely export it or assign it to the globals variable.
  • The NPM module framework is pretty good; better than any other dynamic language I've used. It means you don't have to have stupid kludges like rvm.
  • Each module follows the singleton pattern and maintain its own internal state in a module-level scope.††See my essay for details on this feature.

We had our share of gotchas, especially since asynchronous coding requires a new brain. However, we easily identified these sorts of *race conditions* and soon, enlightenment arrived, and we ate callbacks for our lunch and drank event emitters for our tea.

The Cloud and Node

Node fits well in a world of the cloud, that is, an architecture built from micro-server instances:

  • Each instance has a small, dedicated purpose
  • Each instance holds no state
  • Loosely coupled through either REST interfaces or Redis queues

Sure, Python, Ruby and other dynamic languages work well in the cloud with this architecture, however, Node fit well in this world.

Final Thoughts

The project was great fun, and I fell in love with JavaScript and Node, and found it to be a great prototyping system. Would I build an enterprise solution in Node.js? Hrm, I highly doubt it.

First, I sorely miss types.
Also 100% code coverage doesn't mean as much as it does with a Java project. You really need 300% to cover enough negative tests of passing in arrays, strings and objects.

Second, a single Node.js app isn't that performant‡Have we decided on a spelling for this new word? and a cloud-based architecture even more-so. While the resulting code isn't that fast with huge loads, I found my Node.js project to be fast to code, easy to maintain, and coherent to organize code functionality and structure (given Node's module system).

Now, the dynamic client-side part of the project… well, that is a whole other story that I should tell someday.

Tell others about this article:
Click here to submit this page to Stumble It