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.
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.
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.
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).
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!
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:
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.