Nevertheless, my curiosity won out. I downloaded Node.js and tried it on several pet-projects. My daily language was Ruby, and these early trials placed Node.js slightly ahead of it, though not by much. I set it aside, and returned to my old tools, while the Node.js team perfected it’s runtime. This phase lasted for months, as Node.js became even more popular. Every few months, I would glance at the Node.js message boards, then dive back into my Rails stack.
Eventually, I couldn’t ignore Node.js anymore. During my initial tests, I benchmarked Node.js heavily, and the results were surprising. As my Rails stack began to slow under the weight of a global audience, I thought a second look at Node.js might be appropriate.
For those of you who don’t know me very well, here’s an explanation of what led to the events above. Six months ago, I launched The Machine, a broadcasting network where we produce content for independent creators and entrepreneurs. During our short lifespan, we’ve experienced tremendous growth: in the beginning, only my friends listened to our shows. Now, we serve content to over 25,000 listeners per month, a number that continues to grow rapidly.
When I launched the network, our platform was written with Rails. It was my web-development tool of choice. I was productive, and Ruby is a pleasure to write. This single application served our public facing website, embeddable players, admin panel, and tracked downloads from podcast clients. It was fine in the beginning, but six months in, the system slowed to a crawl as our audience exploded.
In my attempt to increase performance (and ultimately, serve media to an increasing number of listeners), I decided to divide each element of the service into it’s own app. The download tracer, which is arguably the most important part of our platform, was up first. With this model, I could try running Node.js in production on a few, but not all, of our services. If it failed, I could return to Ruby.
CommonJS Is Your Friend
In the world of Ruby, Python, or PHP, your code only has three main structures: everything is bare, you bundle methods into classes, or maybe include a module or two. But at the core, everything is encapsulated in a language-defined container. CommonJS, which powers the require() construct in Node.js is different, and in my experience, far more flexible.
For me, the biggest challenge was understanding how module definitions impacted the structure of my code. What if I needed to require a module several times over? Using Node’s global namespace is a bit dirty, so this is a reasonable question.
Thankfully, Node.js is smart: if you require a module 100 times and in different files, it doesn’t increase your RAM usage. Instead, it caches the first require() and directs subsequent calls to the instance in-memory. If you’re worried about memory bloat (as I was), don’t be concerned. Write your code in small, maintainable chunks and use CommonJS as it was intended.
Avoid “Callback Hell”
CoffeeScript is Cancer
Several years ago, Ted Dziuba’s post “Node.js is Cancer” sparked a huge debate. Sparks flew from both sides, as critics piled on Dziuba’s bandwagon, and Node.js developers defended the young platform. I obviously don’t believe Ted’s gospel, but I think there’s something equally dangerous gnawing at the Node.js community today: CoffeeScript.
But why? CoffeeScript is incredibly popular, and works for so many developers. I’ll answer this in the only way known to programmers: statistics.
CoffeeScript is only suitable for client-side development.
There are two versions!
From what I know, these projects don’t plan on merging; at least, not anytime soon. And while Michael Ficarra has put many hours into his “CoffeeScript Redux” project, the benefits of using it aren’t clear to me.
I say this with no hard feelings towards Michael Ficarra, or Jeremy Ashkenas, the original creator of CoffeeScript. I just don’t like it, based on the trials I’ve endured. It’s a genius idea, and a brilliant piece of software engineering — but like Ruby versus Python, everything comes down to taste. If you want to use CoffeeScript in your Node.js program, go ahead, but prepare for some rough sailing.
Rails touts it’s friendliness as a framework, and Ruby is “a programmer’s best friend.” While I agree with these statements, I prefer to make something work quickly. I’m not here to be friendly with my code, lest it become the principal activity in my life. I’m writing code to accomplish a goal, put it on the production servers, and walk away. Node.js allows me to do exactly this. I write, test, deploy, and then get back to doing what I really love: making great radio.