Take the 2-minute tour ×

Node.js seems to be getting a lot of column inches in the nerd blogs right now, and with a little bit of homework it's not hard to see why.

What would be good to know before diving into learning node? I assume Javascript, but any other technologies or concepts that would help? What would I need to know to go from local testing to production server?

share|improve this question
I would say this is a question for programmers.stackexchange.com –  Orbling May 24 '11 at 12:17
It would be a good idea to look into low level socket programming as well as the different protocols (HTTP, TCP/IP, TCP/IP6) so you understand what's going on behind the scenes when you run your node.js server. –  onteria_ May 24 '11 at 12:18
watch all the "Ryan Dahl" videos you can find of google. Also lurk in the node.js SO chat –  Raynos May 24 '11 at 12:42

4 Answers 4

up vote 5 down vote accepted

If you're building a vanilla request/response web application, the basics would be:

How http/s works in general

The http server example is so common in the node world because unlike another web language such as php, your node application is not living 'inside' an apache web server or the like. You are actually creating a working web server that will return responses based on requests. Its a much different way of organizing a program than the typical "stick your html/php/whatever files in the web root of apache" and go. A strength of node is that it takes something like creating a web/tcp/udp/cli server trivializes a lot of the nasty hard parts like thread pools, event loops, locks, etc.


Because you're going to have to deal with these things in a more manual fashion (at least until you either write a module or choose a module to deal with it). Many candidates I phone interview can't define for me the internal workings of how a typical language handles their session store. They just know they stick value X in variable Y and its available for the duration of the session. In reality, there's a cookie that gets set that references a file/database/whatever store somewhere by session id. In node, you pull these values off the http headers yourself (or a module does it for you) and builds on top of the more basic building blocks of http. The same is true of POST and GET data.

That being said, you can use a framework like express - http://expressjs.com/ - to great effect, and it will handle a lot of things for you. However, its still raw enough (which most nodesters prefer imo) that you can get at the internals of the http requests.


Most web applications are going to require some sort of database. Relational databases like mysql are one way to go about this -- many nodesters prefer something like mongodb because it gives them a little more freedom wrt things like schemas + migration, and a little more of a javascript feel (because things look like JSON). Luckily, its not something you have to make a hard and fast choice about because the community has many, many client libraries for the common databases.

Non-blocking methodology

As some others have mentioned, this is something that can blow your mind to a certain extent. In many other languages, unless you're using a specific non-blocking framework like twisted in python, or eventmachine in ruby, you're writing code that is synchronous in almost all cases. That means when you're asking your database for information, you're doing it like this:

result = query("SELECT * FROM users");

Instead, in node (or other frameworks that support callback/event based io), you'll likely write code that looks like:

query("SELECT * FROM users", function(result){
    // Do something with your users

In the first example (from the synchronous world) 'howdy' is going to be printed after results. In the second (asynchronous) example, 'howdy' is printed before results.

This can get tricky when you have to do many synchronous operations depend on each other. When you get to this point, its time to look into flow control libraries like https://github.com/caolan/async -- they provide tools for sequencing these operations so your code doesn't look ridiculously nested.

Clearly its a broad question. Personally I think you should just dive in and give it all a whirl. Its actually a good way to learn this stuff.

share|improve this answer
I would recommend Futures instead of async for avoiding callback hell –  Raynos May 24 '11 at 23:15
am not a fan myself -- promises/futures are not an interesting construct to me. I like to see traditional callbacks, but organized either via named functions or vanilla flow control. potato potato –  Josh May 25 '11 at 4:34

Node.js is an event-driven system, so a lot of the code you will write will be asynchronous. This means you frequently can't write code like

if( something() ) 

You'll have to do something like


(assuming something() is an asynchronous function, e.g. one that doesn't return its result but rather causes a callback (the anonymous function) to be called with its result once it's done)

This is known as the Continuation Passing Style (CPS) and is one of the biggest hurdles you need to get over to use Node.js effectively.

Here's another, more practical piece on CPS: http://matt.might.net/articles/by-example-continuation-passing-style/

share|improve this answer
Good tip, if anyone can find a clearer (read: dumbed down) explanation of CPS, that would be very useful. –  Mild Fuzz May 24 '11 at 12:50
Ask and you shall receive, here you go :) –  nicolaskruchten May 24 '11 at 15:11

Obviously (as you already said) JavaScript as a language. I recommend Eloquent Javascript for a great guide to JavaScript.

share|improve this answer
+1 Eloquent JavaScript is a great guide, which provides an interesting alternative to "The Good Parts" by Douglas Crockford. –  Eric Bréchemier May 24 '11 at 13:26

Well, since node.js elevates JavaScript to let you write full scale server applications, you will probably want to be familiar with object oriented techniques:

  • prototypes
  • self executing methods to control scope
  • JSON

This will let you organize your code :-)

share|improve this answer

Your Answer


