Question

I’m not very experienced in web programming,
and I haven’t actually coded anything in Node.js yet, just curious about the event-driven approach. It does seems good.

The article explains some bad things that could happen when we use a thread-based approach to handle requests, and should opt for a event-driven approach instead.
In thread-based, the cashier/thread is stuck with us until our food/resource is ready. While in event-driven, the cashier send us somewhere out of the request queue so we don’t block other requests while waiting for our food.
To scale the blocking thread-based, you need to increase the number of threads.
To me this seems like a bad excuse for not using threads/threadpools properly.

Couldn’t that be properly handled using IHttpAsyncHandler?
ASP.Net receives a request, uses the ThreadPool and runs the handler (BeginProcessRequest), and then inside it we load the file/database with a callback. That Thread should then be free to handle other requests. Once the file-reading is done, the ThreadPool is called into action again and executes the remaining response.
Not so different for me, so why is that not as scalable?

One of the disadvantages of the thread-based that I do know is, using threads needs more memory. But only with these, you can enjoy the benefits of multiple cores. I doubt Node.js is not using any threads/cores at all.

So, based on just the event-driven vs thread-based (don’t bring the "because it’s Javascript and every browser…" argument), can someone point me out what is the actual benefit of using Node.js instead of the existing technology?

That was a long question. Thanks 🙂

Answer 1

First of all, Node.js is not multi-threaded. This is important. You have to be a very talented programmer to design programs that work perfectly in a threaded environment. Threads are just hard.

You have to be a god to maintain a threaded project where it wasn’t designed properly. There are just so many problems that can be hard to avoid in very large projects.

Secondly, the whole platform was designed to be run asynchronously. Have you see any ASP.NET project where every single IO interaction was asynchronous? simply put, ASP.NET was not designed to be event-driven.

Then, there’s the memory footprint due to the fact that we have one thread per open-connection and the whole scaling issue. Correct me if I’m wrong but I don’t know how you would avoid creating a new thread for each connection in ASP.NET.

Another issue is that a Node.js request is idle when it’s not being used or when it’s waiting for IO. On the other hand, a C# thread sleeps. Now, there is a limit to the number of these threads that can sleep. In Node.js, you can easily handle 10k clients at the same time in parallel on one development machine. You try handling 10k threads in parallel on one development machine.

JavaScript itself as a language makes asynchronous coding easier. If you’re still in C# 2.0, then the asynchronous syntax is a real pain. A lot of developers will simply get confused if you’re defining Action<> and Function<> all over the place and using callbacks. An ASP.NET project written in an evented way is just not maintainable by an average ASP.NET developer.

As for threads and cores. Node.js is single-threaded and scales by creating multiple-node processes. If you have a 16 core then you run 16 instances of your node.js server and have a single Node.js load balancer in front of it. (Maybe a nginx load balancer if you want).

This was all written into the platform at a very low-level right from the beginning. This was not some functionality bolted on later down the line.

Other advantages

Node.js has a lot more to it then above. Above is only why Node.js’ way of handling the event loop is better than doing it with asynchronous capabilities in ASP.NET.

• Performance. It’s fast. Real fast.
• One big advantage of Node.js is its low-level API. You have a lot of control.
• You have the entire HTTP server integrated directly into your code then outsourced to IIS.
• You have the entire nginx vs Apache comparison.
• The entire C10K challenge is handled well by node but not by IIS
• AJAX and JSON communication feels natural and easy.
• Real-time communication is one of the great things about Node.js. It was made for it.
• Plays nicely with document-based nosql databases.
• Can run a TCP server as well. Can do file-writing access, can run any unix console command on the server.
• You query your database in javascript using, for example, CouchDB and map/reduce. You write your client in JavaScript. There are no context switches whilst developing on your web stack.
• Rich set of community-driven open-source modules. Everything in node.js is open source.
• Small footprint and almost no dependencies. You can build the node.js source yourself.

Disadvantages of Node.js

It’s hard. It’s young. As a skilled JavaScript developer, I face difficulty writing a website with Node.js just because of its low-level nature and the level of control I have. It feels just like C. A lot of flexibility and power either to be used for me or to hang me.

The API is not frozen. It’s changing rapidly. I can imagine having to rewrite a large website completely in 5 years because of the amount Node.js will be changed by then. It is do-able, you just have to be aware that maintenance on node.js websites is not cheap.

further reading

http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/

http://blip.tv/file/2899135

http://nodeguide.com/