Node.js & the Event Loop – by Tim Fulmer, VP of Engineering at HopSkipDrive

Remember when object instantiation was such a big deal, EJBs made sense?  It cost so many CPU cycles to allocate a new object, it made sense to cache objects in a pool and swap state in and out of them. I once saw a system that couldn’t stand up under load because of Object.newInstance.

So, I’ve done a lot with Java.  Enough to have wandered into the depths of the JVM more than a few times.  And friends, I’m never going back.

RAM and virtualized CPUs, cheaply and readily available through your cloud provider of choice, have made the JVM as obsolete as EJB.  Node.JS is one of a new generation of single threaded execution environments helping to serve content.

Intelligent memory allocation strategies and horizontal CPU capacity allows for a stack of functions, each with everything needed right in memory, maximizing CPU cycles on as many CPUs as it takes.  Literally getting things done as fast as possible.

This runtime environment also accurately models what’s happening at the hardware level. Making an HTTP request in code queues up some state on the bus, the CPU pulls a bit to notify the network adapter to make the call, the network adapter reads the packet off the bus and sends it on its way. Later, the network adapter pulls a bit to notify the CPU, and a response is delivered back to the code.

Linux has been asynchronous for many years, which has been making its way up the stack.  Node.JS uses the V8 event loop to accurately model the underlying process, while taking away most concurrency concerns.

Of course, there are some trade-offs.  JavaScript is probably one of the more loosely typed languages in comparison.  There are many things that can be done with JavaScript, which really aren’t good ideas.  Automated code quality tools like JSHint/JSLint can help, and there are some good SaaS tools available as well.

It’s also really easy to make changes in a JavaScript system.  This can of course be a good thing, though can also lead to some very interesting application behavior.  At the code level, we’re used to anything being undefined at any time however when combined with a schema-less Mongo database, and much of the traditional, a strongly typed software development safety net will be missing.  At an overall process level, this makes automated unit and integration tests consisting of a comprehensive regression test suite an absolute must.

This isn’t necessarily a bad thing, add some continuous integration/continuous deployment into one of the auto-scaling cloud providers mentioned above and we’re starting to achieve a very high velocity tech environment.

Are there some things to look out for in a JavaScript system, absolutely.  At the same time, navigating these trade-offs can lead to a fast moving technology solution, scaling linearly and predictably with load. I’m certainly never going back :)

Tim Fulmer can be reached at