Three weeks of real node.js development.

If you don’t know what node.js is, go to the website now and watch Ryan’s introduction. In a few words, is a non blocking framework, you write your code in javascript and is run on top of V8. All IO is (or should) be non blocking to take advantage of the insane speed the framework gives you.

This means that you need to understand asynchronicity and be comfortable passing around callbacks, but I’m getting ahead of myself.

Node ecosystem and packages.

I knew the ecosystem from before since I have been playing with node.js for a while now, but even with that knowledge I’m surprised how mature is in most areas.

Installing node is fairly simple in most *nix systems. After installing node the next step should be to install the package manager npm .

One of the problems you may encounter is not the lack of libraries but exactly the oposite. There are quite a few packages to help you deal with a given task. The issue with this is that you may need to try a few until you find the one that really works well.

It helps to visit the project page for the package before installing it or take a look at the readme file. I found that the good packages have somehow good documentation and even example projects that help you to understand their usage.

Web development.

This is one area that node is fairly mature for a 2 years old technology. Connect seems to be the de facto middleware framework. You can think of it as an equivalent of Rack or wsgi. Connect abstract all the server, request and response implementations giving you a consistent api.
But you don’t even need to deal with connect directly. You can use express.js and build on top of it. That have been my aproach. ExpressJs takes it’s inspiration from Sinatra.

If you are looking for something at an even higher level, you may want to check out geddy . Geddy (as express) have been around for a while now. It comes packed with generators and helpers that favored RAD.

BTW: There are more than 30 different web frameworks out there. These are the two I’m more familiar with.

TDD in node land.

I do consider myself a Test first guy. My methodology for using Test as a design tool have been evolving with time and I was certainly worry about finding a good tool for node.js.

Javascript has several testing frameworks and some of them (actually a lot) have been ported or modified to be able to run in node.js and other commmon.js environments.

At the time I’m using expresso (comes bundle with expressjs but you can install it on it’s own) with should and I’m ok with it.

I’m also looking at cucumis to drive some outside in development when the moment comes.

I personally think that having a good harness of test surrounding your system is fundational to any software that hopes to have any future. This is even more so when using a dynamic language.

Check out this github page for a comprehensive list of testing tools.

Productivity

If you are proficient with JavaScript node have to be one of the most productive stacks out there. I was able to acomplish “A LOT“ in a very short period of time, without cutting corners or sacrificing code quality.

Deploying to a “real” server/environment.

You have several alternatives. You could build your own EC2 instance (they have a free tier for a year) based on your favourite Linux distro (I choose Ubuntu).

Utilize some of the cloud offerings available (most of them are on Beta are you will need to request an invitation).

Nodester, Joyent , Dotcloud and nodejitsu are some of the offerings out there (If I’m missing somebody just ping me).

I so far tried DotCloud and they have been very good and responsive whenever I found a problem. I really like the way their api work and how I can use different stacks in the same sytem. I as well use the EC2 alternative with Ubuntu for some custom installs.

Clean that code!

Javascript has bad rept with some developers, specially those that come from an static language. I will be the first to admit that it’s not for everyone and that there is a lot of terrible code out there. We all know the horrors of the 90’s when we copy each other code and we polute the global namespace while writing our silly rool over menues.

I will admit it. I wrote code like that. But that was a long time ago. Today there is practically no reason to write bad JavaScript as there is no reason to write bad Ruby, Perl, Python, C#, you name it.

A good testing strategy is good but not enought. Code may work but still can be bad code. I recommend getting a copy of Javascript: the good parts and also watch the videos by Douglas Crockford on the subject.

The use of JSlint can also help you to find common problems in your code before is too late. I recommend running jslint as part of your “build” process.

Your code may be clean but it’s so difficult to read.

Another common complain/concern is that the way that you see most node.js code writen (and JQuery code for that matter) is very difficult to follow.

I understand the concern but at the same time I disagree. I don’t think this is an issue with node.js in particular.

What I’m talking about is the temptation to pass anonymous functions as callbacks in every single call.

This can get ugly really fast.

My solution is to only use anonymous functions in the simples of cases and pass function names other wise. As a rule if I found that I’m repeating myself and writing the same function in more than one place I refactor and just pass the name.

Instead of this:

I prefer to write something like this:

Conclusion.

So far my experience have been really positive. I find myself writing very little plumbing code and focusing more in the business domain. In a few cases I have to change strategies or completelly scratch out one library from another, but that’s ok. It happens in any stack.