It seems more and more so that people are interested in building their applications in node.js yet there are few reviews on what it’s actually like to work with the framework. I’ve designed and am nearly finished building out all of the features of a full scale (user accounts etc) social news site in node. (www.exipe.com) Here are a few of the things I’ve found and maybe they can help you in your decision to go with node. I will choose to ignore the thing that people point to first: because its event oriented it can handle more concurrent users better. Lets assume that as true and talk about some things that less people are talking about.

There’s a steep asynchronus learning curve

Even though I’ve made many a javascript application before working on this project, including fooling around in node some, I found adapting to the asynchronous programming style a significant challenge. Every database interaction you do, every file system read or write, even http requests are asynchronous and need callbacks. This means that quite often if you want to do 10 different things for example you can end up with spaghetti code with 10 different scoping levels of indentation. As you learn and grow with the tools in node you learn that you can attach listeners to things and create separate functions to mitigate these problems and shortly after it almost feels natural.

The Node.js project and its libraries move fast, and you have to keep up

As many of you know node is a very new open source framework that has undergone many changes (some of which can break things) in the last few months. (since I started working with it on Exipe) This meant that I needed to be careful to notice what changed in the update and make sure I fixed anything that broke when updating. Some would ask “why don’t you just use the old version?” My response to that is the bug fixes and improvements are well worth the small changes in node. Another thing that happens is libraries such as mongoose (which we have been using to interact with our MongoDB database) undergo many changes as well. If I had any advice to give here it would be keep up with the latest going on in node and the packages/libraries you use because if you fall behind there may be no one willing to support an older version.

The community support is amazing and very active

Like many programmers I frequent sites like github, google groups and stackoverflow. Upon asking questions, posting comments or sharing bugs about anything node related on those sites I’ve found a response that was fast, cordial and most importantly … correct. This has made any headaches in dealing with such a new framework relatively painless because so many others are going through or working on the same issues. I think I even heard that the node github page is more active than the rails project page.

Some of the libraries can save you a ton of time

I found that one of the features I wanted in the site was a facebook login. While I’ve previously dealt with facebook connect in php and found it relatively painless there I expected something like that might be a headache in node. After finding the connect-auth library it turned into a piece of cake with a little monkey see monkey do thrown in from following the examples. I wanted to interact with S3 to store images and found a wonderful project called knox. Pretty much anything you can think of theres probably a tool that integrates with node that is of high quality and actively developed.

Server stuff is often easier to handle

Working on php applications I often remember having to learn the black magic of configuring apache to do what I wanted. While not rocket science it seemed to be overly difficult and finding easy to understand, accurate documentation was hard. In node, if you use it as the server things like changing the port you’re hosting it on is as easy as changing which number you tell it to listen on. (these things are often/can be internal to node)

You can “cut corners” on requests easier

It is fairly trivial to tell node to return a web request (say a user voting on a link) before interacting with the database, thus minimizing the time that the user is waiting for feedback. While I never got deep enough on a big project to want to do this with php, I’m not sure of how to do it off the top of my head.

Interacting with other websites is simple

Telling your webserver to go out, download a web page, parse it and return something of significance to you is very easy in node. Something I have found more challenging in other languages and frameworks. (while possible and very doable they don’t support it so directly as node does)

You can MVC all you want

In one of my previous posts I talk about a simple MVC setup with node.js. Similar to frameworks in other languages it is not only possible, but easy to set up and powerful

NPM is awesome

If you want to install/update any of the packages you are using for node it is always very easy to do so with a tool like NPM. A simple npm install whatever_package and bingo you have it, ready to go.

Hopefully this post has convinced some people to try out node for its active community/powerful tools and dissuaded some not intent on the extra learning/maintenance because that’s what I’ve found you’re probably in for. Whether node.js is the choice for you or not, I’ve found that the pros outweigh the cons in development of exipe and have loved working with the framework. Shameless plug: If you feel like checking out what a node.js website feels like head over to www.exipe.com and sign up for our beta coming in March.

For those of you from HackerNews waiting for me to open source the more specific/thorough example of a node MVC setup, worry not as its nearly done and I’ll share it soon

23 Responses to What it’s like building a real website in Node.js

This goes into my bookmark. Thank you very much for sharing. Looking forward to the open source project you mentioned. I am learning node.js myself and something like this would be immensely helpful.

By the way, I really like your color combination. If you can make everything fit into the page so that one need not have to scroll, it will be perfect (only because it is a beta-signup page). Just m two cents though

I found Q for Node.js tremendously helpful for doing sequencial tasks. I know it defies the the purpose of asynchronism and have to learn the CommonJS Promise primitives in order to use Q, but there are many cases where I need to perform a task given another task is finished.

Great post, I agree with everything on it. NPM is the best package manager I’ve used in a framework. And hell, all the nodejs tools move very fast, it might be a pain to catch up sometimes, like the new Mongoose API.

> Telling your webserver to go out, download a web page, parse it and return something of significance to you is very easy in node.

I imagine this is true especially if you have fetches contingent on other fetches, some of which may be done in parallel. I’ve used threading for this in the past but events would probably be cleaner because I wouldn’t have to manually split serial tasks into threads. A diamond dependency (not fetching a page twice if two threads lead to it) would also be easier to handle in a single thread, as would other things.