22

I've noticed that Node.js has become very popular, and I've seen several instances of people doing small-scale projects in it.

I've also looked at pros and cons lists to get an idea of what Node.js can do, but I'm still not clear on how it differs from other, more mature server-side tech like PHP, Perl, or Ruby on Rails.

What, specifically, differentiates Node.js from the current alternatives, and why?

Saeed Neamati
  • 18,142
  • 23
  • 87
  • 125
  • 1
    @downvoter - why the downvote? except for the second paragragh (you can't really ask why start something when someone else has done it because you could always do it better), I find this question to be intriguing. I've often thought this myself. – David Peterman Sep 09 '11 at 15:05
  • It's a minor nit to pick, but if you google on the *quoted phrase* **"node.js"** you get about 3 million hits. – Peter Rowell Sep 09 '11 at 15:24
  • @Peter, yeah, I tried that, and you're right. But 3 million is still two much. You can come back a year later, and this figure is probably gone up to 10 million. :) – Saeed Neamati Sep 09 '11 at 15:25
  • 3
    @Mark, thanks for outstanding edit. It's clearer now. – Saeed Neamati Sep 09 '11 at 15:28

3 Answers3

19

There is two important things that make Node.js different to existing server-side frameworks, asynchronous events and the use of JavaScript as a programming language.

Asynchronous Events

While most of the existing server side frameworks use a synchronous architecture, Node.js uses an asynchronous architecture, which JavaScript can handle well. This means that the server reacts to events and sends events (messages) to e.g. the database. This style of programming is very different to a synchronous style, and may be hard to use with other languages. Node.js employs an asynchronous style with asynchronous IO and can scale well.

See also Event Driven Architecture

JavaScript

JavaScript is the programming language that web applications are using on the client. Using the same language on the server-side means that the developer can apply his JavaScript knowledge both on the client and the server, and use the same functions as needed.

I would recommend the presentation Introduction to Node.js with Ryan Dahl where he explains Node.js event-driven architecture in more detail.

Community
  • 1
Jonas
  • 14,867
  • 9
  • 69
  • 102
  • 2
    This is easily the best answer so far, but I'd put the Asynchromous Events first, as that's really what makes Node.js so appealing as a server-side framework. Good job though, mentioning asynchronous I/O and scalability. That's the heart of it. – Adam Crossland Sep 09 '11 at 17:44
  • Well @Jonas, I still don't understand. ASP.NET is also event-based. Then what is the difference between Node.js, and ASP.NET? Is it only because it's asynchronous? In that case, I think using multi-threading in ASP.NET can do the same, can't it? – Saeed Neamati Sep 09 '11 at 18:44
  • 3
    @Saeed: ASP.NET is threaded and synchronous, e.g. when accessing the database, the thread is blocked and is waiting for a reply from database. And when using many threads (e.g. one per request) a lot of memory is used (each thread needs quite large amount of memory), that may be a bottleneck. Node.js sends messages and reacts to events, so it never (hopefully) blocks the thread. With node.js you are using the same programming model as on the client side with Ajax (**Asynchronous** javascript and XML), and the same language. – Jonas Sep 09 '11 at 18:55
  • You forgot the great open source community behind it. – Raynos Sep 09 '11 at 19:21
  • 3
    When C#5 rolls around with the new `async` stuff though that may change. The issue isn't that you *can't* write scalable asynchronous code in other languages, it's that it's more difficult to do (correctly) without good language level support. – Davy8 Sep 09 '11 at 22:22
  • @Davy8: I didn't write that it can't be written in other languages, just that it may be harder (since you probably need to use threads). `async` support in the language doesn't help much. You need to change the architecuture of the web-server (IIS) to be event-driven instead of threaded, and change the way it handles connections to the database (ADO?) to be asynchronous instead of synchronous as it is now. – Jonas Sep 10 '11 at 09:37
  • @Jonas Sorry, I didn't mean to imply that I thought you said it couldn't be done in other languages. Regarding the new `async` stuff, from what I've been reading `async` actually does seem to make the model implicitly event driven by rest of a method following an `await` into a callback function so it does actually become event-driven behind the scenes. In fact the exact stack trace of a method after an `await` statement isn't guaranteed and depends on whether the operation it's waiting for has completed prior to hitting that line of code. It looks really promising. – Davy8 Sep 10 '11 at 17:48
  • @Davy8: By using a programming language with `asynch` support doesn't change the architecture of the server (IIS) and you need to use an asynchronous database driver (e.g. probably not ADO.NET or any existing ORM). In Java you can use [Netty](http://www.jboss.org/netty) and a driver like [ADBCJ](http://code.google.com/p/adbcj/) to be on par with `Node.js` or even better. Then the application language (e.g Java) can be single threaded and doesn't need asynch support, as long as the events can be served quickly. – Jonas Sep 10 '11 at 18:12
6

Its diffrent because its event-driven. This makes the server highly scalable.

In a nutshell;

Thread Model

  1. Client asks for something
  2. Server goes off and process the request
  3. Gives it back to the client
  4. Ready to process a new request

Event Model

  1. Client asks for something
  2. Server passes the request on for processing. Ready to process a new request
  3. Server handles more requests as they come in
  4. Server gives data back to the client when the request has finished processing
Tom Squires
  • 17,695
  • 11
  • 67
  • 88
  • @Tom, what do you mean by event-driven? ASP.NET WebForms is also event-driven and you can see handlers like `Session_Started` or `Context_Authenticated` or `Page_Load`? – Saeed Neamati Sep 09 '11 at 16:23
  • 1
    Calling it event-driven is more ambiguous than is necessary, and it doesn't really get to the heart of Node.JS: asynchronous I/O. – Adam Crossland Sep 09 '11 at 17:40
2

I've been under the impression that it's popularity was due to the use of JavaScript. Since lots of web developers know JavaScript, it is a selling point that they can now develop server-side code using the same language. This has a few advantages that I can think of:

  • Code files can be shared between server and client, preventing duplication of effort just to handle the two sides of the system.
  • Developers don't need to mentally switch between languages. (not a big deal in my opinion)
  • Architects don't need to choose multiple languages when architecting a web solution.
  • Someone who never developed server-side code can now do so without learning a different language. (Not likely to be a valuable argument, IMHO)
John Fisher
  • 1,795
  • 10
  • 12
  • Node.JS is popular because it is fast and scales well. That it is in JavaScript is nice, but largely incidental. – Adam Crossland Sep 09 '11 at 17:42
  • 2
    What's more valuable is that server-side developers can write client-side code in the same language, and that you can share server-side modules with the client. Not the other way around. I would not want to port hacked client-side code to the server, that's shooting yourself in the foot. – Raynos Sep 09 '11 at 19:23
  • @Adam: Why is node.js becoming popular when there are already technologies that fit the "fast and scales well" description? -- Because it's JavaScript. – John Fisher Sep 09 '11 at 20:22
  • @John It's more difficult to write apps that *don't* scale well in Node.js. If your app is disk/network intensive than CPU-intensive (which most are) you can easily support many times more simultaneous connections on a single core than most other servers unless you write some very tricky threading code. – Davy8 Sep 09 '11 at 22:16
  • @Davy8: I guess that all depends on the other frameworks/systems you've used. The ease of scalability you describe is already simple with the tools I use. The only thing Node.js offers from my viewpoint is the JavaScript flavor, which is not compelling. – John Fisher Sep 10 '11 at 01:07