Why and when to use Node.js? [duplicate]

Question

Possible Duplicate:
How to decide when to use Node.js?

Sorry if I'm a bit ambiguous, but I'm trying to understand the real advantages of using Node.js instead of other server-side language.

I'm a JavaScript enthusiast, so I'm probably going to play with Node.js, but I want to know if I should use it in my projects.

Firestone

Probably want to check out this video – Cleruchy

@Cleruchy thanks for the video share. – Jovitajovitah

@kjy112 I recommend you google video search for "ryan dahl node.js" and there should be about 4. There all good. – Cleruchy

zgadzaj.com/… – Unbrace

I find it strange that none of the answers compare/contrast node.js with the most comparable (and heavily used) alternative today, php! – Esprit

Answer 1

It's evented asynchronous non-blocking I/O build ontop of V8.

So we have all the performance gain of V8 which is the Google JavaScript interpreter. Since the JavaScript performance race hasn't ended yet, you can expect Google to constantly update performance on V8 (for free).

We have non-blocking I/O which is simply the correct way to do I/O. This is based on an event loop and using asynchronous callbacks for your I/O.

It gives you useful tools like creating a HTTP server, creating a TCP server, handling file I/O.

It's a low level highly performant platform for doing any kind of I/O without having to write the entire thing in C from scratch. And it scales very well due to the non-blocking I/O.

So you want to use Node.js if you want to write highly scaling and efficient applications using non-blocking I/O whilst still having a high level scripting language available. If needed, you can hand optimise parts of your code by writing extensions in C.

There are plenty of OS libraries for Node.js that will give you abstractions, like Express.js and now.

You don't want to use Node.js if you want (slow) high level abstractions to do everything for you. You don't want to use Node.js if you want RAD. You don't want to use Node.js if you can't afford to trust a young platform, either due to having to write large pieces of code yourself to do things that are build into other frameworks or because you can't use Node.js, because the API isn't stable yet or it's a sub 1.0 release.

Cleruchy

> "You don't want to use node if you want RAD." By that do you mean that it usually takes longer to develop things in Node? – Disarticulate

@Disarticulate RAD consists of a very high level framework that does a lot of the work for you at the cost of very little flexibility. It basically does a lot of generic boilerplate under the hood for you. node is a low level library. – Cleruchy

Good point, thanks for the answer. Although using a node framework would presumably change this? – Disarticulate

@Disarticulate depends on your definition of "framework". Express is a http framework that is very useful but still does not accomodate RAD. I believe people ported cakephp & rails to node. Those kinds of frameworks might allow RAD but are also full of bad design & anti patterns – Cleruchy

I see. On an off topic note do you have a link that describes the anti patterns in rails you mention. I'm am currently learning rails so I'm am very curious. – Disarticulate

@Disarticulate there's nothing wrong with rails. It's just a huge abstraction. There are trade offs. I just wouldn't build something like rails on top of node because node has better patterns. – Cleruchy

Ahhh antipatterns because it wasn't originally built for node? Makes sense. – Disarticulate

Normally, you write code in in Java,php,python,c# in "blocking" traditional way, that means when a tasking is executing, other tasks must wait for it to completed (in a queue) In Nodejs, the basic concept is the "non-blocking" way, that means when a tasking is executing, other tasks dont need to wait for it to completed. – Unbrace

IMHO, the main "alternative" to "server-side javascript" is php. While your answer is quite informative, I notice it doesn't address that choice. – Esprit

Answer 2

The two most oft-quoted advantages are:

• JavaScript is both server-side and client-side. There are fewer things to learn, less context switching, and the ability to reuse code across the two sides.
• Uses non-blocking I/O, and Chrome's V8 engine, to provide fast, highly scalable servers.

For me though, the most interesting part is the amount of activity happening in this area. There are a lot of very interesting ideas under development for node - be sure to check out the list of Node.js modules.

Bayou

Probably re-order those. Code re-use isn't that big of a deal. Evented non-blocking IO and a really fast scalable server is a big deal. – Cleruchy

We pretty much have to use Javascript client side. I see it as a disadvantage having to use it server side, when there are far nicer languages like Python available – Largeminded

Answer 3

When you're (or even if you are not) a JavaScript enthusiast you can/should use Node.js for a number of reasons:

• It's a low-level, lightweight and standalone framework which brings power of JavaScript to the server-side environment.
• If you like more higher level abstraction then there is a large number of modules and the npm package manager where you can find wide range of ready-to-use applications.
• Fast/unencumbered development process - for example, you don't need tons of additional tools in order to start writing serious stuff.
• Big open source based community full of enthusiasts and very talented people.
• Made for creating real-time web oriented applications - that's where the (near) future is.

Bicorn

You don't have to be a JavaScript enthusiast! – Cleruchy

Answer 4

Personally, I'd most likely use Node.js when:

• I want to write a server that doesn't use the HTTP protocol.
• I'm prototyping a server implementation.
• I'm writing a server that isn't expecting a ton of traffic (although I've never profiled a Node.js implementation next to, say, a matching C++ implementation).
• I want to get active in the community (which is apparently growing quite rapidly).

Johathan

@DemianBrecht I think you'll find node.js is a really fast server that can handle a lot of traffic. If you want something better hand write a HTTP server in C. – Cleruchy

@Cleruchy I figured it would be able to simply based on the fact that it's using V8 :) Having said that, forgive my ignorance, but imho, when building large scale servers (for say games, etc) you lose FAR too much in strongly typed, OO, compiled languages. – Johathan

@DemianBrecht since when is Javascript strongly typed & compiled ;). What you want to do for large scale servers is use JavaScript for your easy maintenance scripting and hand optimise parts of your code by extending node with C libraries. Like how you use lua. – Cleruchy

@Cleruchy Could be that I'm not explaining myself well enough.. In any case, I really need to dig into node.js further :) I'm not worried about the optimizations as much as I am the overall system architecture. I realize the benefits of scripting some of the subsystems, but I can't see developing an entire system framework in Javascript lending itself well to extensibility, etc which is why I was mentioning the loss that you'd suffer from veering away from using a strong typed, OO, compiled language as your base. – Johathan

[cont'd] I could however, see writing your own server in say, C++ or Java and then integrating the V8 engine to script your subsystems (using V8 as an alternative to a LUA interpreter) – Johathan

In any case, it's fun, super high ROI and has a large following already :) – Johathan

@DemianBrecht you don't lose anything moving away from strong typing, OO and compilation. It's just a different attitude. You writing functional style code. You can just as easily write a spaghetti maintenance nightmare in C++ as you can in JavaScript. You can also write an equally strong maintainable architecture in JavaScript as you can in C++. JavaScript is not a toy language. It's Scheme like. – Cleruchy

@Cleruchy I agree that it's not a toy language and has definitely come a LONG ways in the last few years (not so much the language itself, but how we use it). I also agree that you can find horrendous spaghetti code written in C++ as well. However, a well architected system that uses the full capabilities of a true OO language will always be easier to maintain, extends and debug than a prototype-based language. Really though, this is a totally subjective conversation bordering on religious-ness (old(er) school vs. new school?) ;) I have a feeling that we'll just have to agree to disagree ;) – Johathan

@DemianBrecht I'm still going to say you missed the entire functional approach boat. Yes classical OO is more powerful then prototyping. But we have first class functions. You can write code that's just as powerful by passing functions around and using closures. I would say it's your lack of exposure to well written functional architecture that's causing this. Now about debugging you have a valid point. The eventloop kills the stack, this is a known issue and the node team is working on this. Also your suggesting there is no good C architecture ;) – Cleruchy

@Cleruchy - Both methods have their strong and weak points. Yes, you can write code that's just as powerful. Yes, you can hack away at any language and create horrendous code. I've had exposure to both functional and OO architectures and have heard arguments for and against both. My own experiences lead me to believe that, when you're dealing with code bases with hundreds of thousands of lines of code, OO architecture seems to be easier to work with, especially when you're working in a team setting, when also dealing with "people" variables, like turnover and tranining. – Johathan

[cont'd] But again, all arguments are highly subjective and, while this is a great discussion and one I'm sure many people are having as more people jump on the node (and other functional architectures) bandwagon, it's gonna take a LOT more than SO comments to sway either of us either way ;) – Johathan

@DemianBrecht I can agree in some aspects that classical C++ style OO allow you to deal with large codebases where all the developers have a range of training expertise. At least I can confirm it's based on sound reasons rather then ignorance. Writing large maintainable 100k+ code bases in node is a gigantic task. C++ already has had it's trail and error phase for this. Your right though a few comments on SO isn't the way to go, maybe a debate over a couple of pints? – Cleruchy

@Cleruchy - LOL - Anytime you're in the Vancouver area :) – Johathan

@DemianBrecht that's no good. Let me know when your in the london area though. – Cleruchy

I just wanted to point out that strongly-typed OO and functions-as-first-class-object approaches aren't mutually exclusive. I think where JS, and the other scripting languages truly excel is that they make the syntax much more terse. E.g. writing anonymous methods in Java is slow and ugly! – Nad