Select Page

I recently started working on a few Node.js applications. Coming most recently from PHP (and Drupal in particular), I found the transition to Node.js to be surprisingly easy. Pleasurable, in fact. But I had to learn to think differently about a few things.

Below I list the five things I think every PHP developer should know about Node.js.

1. Node.js Is Built On Chrome’s JavaScript Engine

Google’s browser, Chrome, has a notoriously fast JavaScript engine called V8. And this JavaScript engine can be cleanly separated from the web browser. Node.js is built on V8. This is one of the main reasons why Node.js is so fast.

This has several positive implications for you, the developer:

  • You don’t need to learn a new “dialect” of JavaScript. I find myself referencing Chrome’s and Mozilla’s JS documentation all the time, because Node works the same way.
  • With V8’s JIT (Just In Time) compiling, apps run at near-native speeds (benchmarks indicate it’s much faster than PHP and Ruby, in terms of running analogous computational tasks).
  • As V8 improves, Node will too.

2. Node.js Isn’t (Just) A Web Server or Platform

Unlike PHP, Node.js is not “web centric” (yes, you can run CLI apps in PHP, but that wasn’t the original intent). Node.js is a general-purpose JavaScript runtime with a host of powerful libraries — one of which happens to provide an HTTP/HTTPS server implementation.

But you can do much more with Node. It is easy to build command line clients and other TCP/IP servers.

On the one hand, this is great news. Node.js is so flexible.

On the other hand, since Node.js isn’t HTTP-centric, you may find yourself having to implement code to do things once provided for you by the framework. In other words, in node, there is no$_GET.

3. Node.js Is Object-Oriented (In That Weird JavaScript Way)

I love jQuery. But it’s made me lazy. It’s made it very easy to write quick and dirty scripts without thinking about architecture. When using JavaScript for a few pieces of browser bling, perhaps this isn’t a bad thing.

But Node’s clearly not about browser bling. It’s about application building. Which means architecture. When you write code in Node.js, you’re going to want to get neck-deep in JavaScripts prototypal object model.

Having that strong 10-years-in-Java background, I thought that JavaScript’s weird prototype system would drive me crazy. And sometimes it does. But surprisingly, I’m falling in love with it. Node.js (and NPM, the amazing Node Package Manager) make such good use of the prototypal JavaScript system that merely writing code “like they do” helped me clear many of the hurdles that my Class/Interface mind thought would be hard to grok.

4. Evented I/O?

Now we’re to the most controversial aspect of Node.js. Node itself runs in one thread. ONE! (Compare this to your typical Apache/PHP system where a dozen or more PHP instances are running at once.) Yet somehow it is fast and efficient.

What’s the secret? Sharing execution time, and offloading intensive IO processes to other threads.

I could go off on a long jargon-filled tangent about the benefits and drawbacks of “evented I/O”, but instead I’ll stick to the practical: When writing in Node.js, you need to think a little harder about whether your task is slow (and I/O bound) or fast. Use asynchronous functions with callbacks or event handlers for the slow work.

The important thing is to make sure that your application code doesn’t allow one request to monopolize the main Node process for too long without giving opportunities for other requests to get some work done.

5. Package Management is a Must!

Be honest. Do you love PEAR? Do you turn almost all of your code into PEAR or PECL packages? Not that many PHP developers do (and a surprising number of them don’t even know what PEAR packages are!).

You probably don’t want to carry that mentality over to Node.js.

  • Node.js is designed to be a minimalistic framework. 90% of the stuff you find in PHP’s core will not be present in Node.js’s core. Need an example or two? Database drivers? Not in Node’s core. Mail libraries? Not in Node’s core. HTML support? Not in Node’s core.
  • But a modular architecture is in Node’s core. And you will use it because it is awesome.
  • The npm tool (Node Package Manager) is the second thing you should download — right after Node. With it, a world of Node.js libraries will be available to you. Drivers, parsers, formatters, servers… there are thousands of packages.
  • Building and publishing your own packages is dead simple. I released my first one only a few days after starting with Node. It’s just that easy.

If you’re a Drupal developer, you can think about Node’s packaging system as something similar to Drupal modules — but with the developer (and not site-builder) in mind.