8

I'm trying to get my head around where Node fits in. It's niche, so to say... What obstacles is Node aiming to provide a ramp for?

I've read through the examples and seen a few demonstration videos. And it all looks very slick... Creating a simple web server; creating a simple TCP/IP chat server; using Node as an JSON-based front for a database server... But where does it fit in? I mean, except for the last example, what is there to do with Node?

I guess what I'm asking is this: What would you use Node for? And why?

cllpse
  • 21,396
  • 37
  • 131
  • 170
  • Any website application. Because its evented IO & it's JS on the server & client. – Raynos Mar 31 '11 at 21:46
  • The focus seems to be interactive websites with dynamic HTML generated server-side. – Swiss Mar 31 '11 at 21:46
  • @Swiss: So, just like IIS, or Apache, or pretty much any HTTP server? – Mark Mar 31 '11 at 21:52
  • @Mark Not quite exactly the same, because you can do more than just host websites with it, but that does seem to be the main focus of Node.js. – Swiss Mar 31 '11 at 21:56
  • @Swiss: You can do more than just "host websites" with most any HTTP server. That does, however, seem to be the most common use for them. – Mark Mar 31 '11 at 21:59
  • 1
    @Mark HTTP servers aren't really touted for hosting non-HTTP services, but Node.js is. The main type of service Node.js seems to focus on though is HTTP service. – Swiss Mar 31 '11 at 22:05

6 Answers6

14

Convince the Boss

List of reason to use node:

  • Speed. V8 is fast. It's faster then python, it's faster then php.
  • Evented IO. IO done properly. No messing about with threads, everything works nice and easily.
  • Low level web server. A good control over the abstraction in a dynamic language.
  • JavaScript. A great language with a lot of developers experience in writing asynchronous code. Development is fast and maintenance is lovely as everything can be done in one language (clientside, server-side, database access).

Libraries and tools that can be used with node.js:

  • express.js : MVC Web framework. Very lightweight. Gives you routing and views. Builds ontop of connect.js. Out of the box flexible control of views and routes with multiple css and templating engines supported. As with node.js itself it's simplistic and gives you fine grained control of your web server. Personally I find the balance between control and abstraction about right.
  • socket.io : The de-facto websocket abstraction. Lot's of graceful degradation support build in so browsers without websocket use comet techniques or a flash bridge. Allows you to talk between client and server in a no-hassle, easy and realtime manner.
  • now.js : Builds on top of socket.io and gives you a synchronized name space across client and server. Allows you to trivially call server methods from the client or vice versa.

All of these libraries are based on the fact that node.js allows you to handle everything on a low level manner and that communication with the client is smooth and streamlined because you use the same language on either end.

The selling point for me is that I have the same MVC library backbone.js on the client and the server. All my model code is re-used. The models on the client and the server are synchronized trivially over now.js.

My database access is driven by cradle (or mongoose) which is all written in JavaScript. Actually my MVC ties directly into the database and seamlessly saves my models. The models define useful methods like save and fetch to do persistent database storage. I don't manually touch the database because my MVC allows me to plug-in in a database driver to do this for me.

The rendering of my templates is done with EJS, my views are shared among the client and the server. There is simply a large amount of code-reuse and my entire web development is done in JavaScript which means I don't have to switch my coding paradigm or style.

Nor do I have trouble deciding how I should handle the grey area between what lives on the server and what lives on the client because that grey area has been completely smoothed over and the client and server integrate seamlessly.

If you're going to write a complex dynamic ajax web application then node.js is a perfect candidate. If you're going to have a static website then node.js is a perfect candidate (You set it up in 20 minutes).

If you're going to write a server heavy website with little client side functionality and postbacks then maybe you're better off using php or ASP.NET. But if you're doing that you should looking into more dynamic client side functionality and using ajax.

Community
  • 1
  • 1
Raynos
  • 166,823
  • 56
  • 351
  • 396
  • 1
    It would be interesting to me to take the ideas used in Node and apply them to some other framework. It seems to me that there's nothing tying this HTTP server paradigm to JavaScript or the V8 engine. – Mark Mar 31 '11 at 21:57
  • @Mark eventmachine for python is similar. There is indeed nothing tying it to JavaScript. but the fact that we have javascript allows you to handle it differently. JavaScript as a language and as a community is very suited to this http server paradigm – Raynos Mar 31 '11 at 22:01
  • 1
    What ties it to JavaScript is that JavaScript is naturally asynchronous, and lacks synchronous libraries. What ties it to V8 is that V8 is really really fast. – generalhenry Mar 31 '11 at 22:32
  • @generalhenry although the fact its tied to V8 is probably bad. It should be able to build on any JS interpreter (within reason). – Raynos Mar 31 '11 at 22:46
  • @generalhenry What do you mean when you say "JavaScript is naturally asynchronous"? The Wikipedia entry on JavaScript doesn't have the word "asynchronous" in it. – Mark Apr 01 '11 at 13:53
  • @Mark you try to write asynchronous code in C. JavaScript has first class functions, which allows to naturally write asynchronous code. – Raynos Apr 01 '11 at 14:02
  • @Raynos so, it's difficult to write asynchronous code in C, therefore, JavaScript is naturally asynchronous? It doesn't logically follow. Node.js might be awesome, but you shouldn't need to make stuff up to convince people. It's trivial to write asynchronous code in any one of a hundred languages, what makes JavaScript better than them? – Mark Apr 01 '11 at 14:05
  • 1
    @Mark it doesn't. What does make it better is that in the web development sector, javascript is one of the view languages where a large group of software engineers have experience writing asynchronous code in. So it's natural to use JavaScript for a server-side asynchronous language in the web development sector since people are familiar with it. – Raynos Apr 01 '11 at 14:16
  • @Raynos then you should say that, instead of making a ridiculous claim that the language is somehow "naturally" asynchronous. Doing so weakens your argument and diminishes your credibility. – Mark Apr 01 '11 at 14:20
  • 2
    @Mark I didn't make that claim. generalhenry did. I said you can write asynchronous code in a natural manner. – Raynos Apr 01 '11 at 14:25
3

I believe that one of Node.js's proclaimed strong points is it's suitability as a websockets server. Connections in Node.js are cheap (because there's very little framework around it), and therefore a single system can support many persistent connections.

Mark
  • 11,257
  • 11
  • 61
  • 97
3

well node is suitable for maintaining high amount of open connections (to other nodes, services & etc.) in general.

this should give you insight on its performance compared to others(+ a discussion as bonus): Scale Stack vs node.js vs Twisted vs Eventlet

Node also fits well as shell/terminal scripting language, good example is this: github.com/indexzero/forever

And as javascript @ server-side solution - shrinks the gap between building frontend (html/js) & backend (in current case nodejs) solutions.

You can find this useful too: List of Projects, Applications and Companies Using Nodejs

outbounder
  • 31
  • 3
2

You can get a lot of node.js use cases if you look at the modules page for example. It varies from tons of libraries like routers, static file servers, web frameworks and WebSockets servers to lots of DB specific connectivity modules, standalone databases, TCP/IP servers and popular protocol/library wrappers which are all waiting to be used for building other madness like these companies did.

I would say you would want to use node.js in case when you want to take advantage of lightweight, low level and fast server side framework which is using evented IO and offers rich set of open source community driven libraries (you should, or rather have to, also know JavaScript to certain level) in order to build other modules or use it as a foundation for standalone project (or as a supplement for specific functionality which node.js can do better than other solutions).

yojimbo87
  • 65,684
  • 25
  • 123
  • 131
1

It's a good question! As you said, coding with Node is fast and simple. It's not the only fast and simple tool out there, though, so what makes it unique? I look forward to the other answers!

My contribution: one of the advatanges of using Node, is that you can write both your client-side and your server-side code in JavaScript. This gives you a margin of code reusability you wouldn't have otherwise.

salezica
  • 74,081
  • 25
  • 105
  • 166
  • I would hazard a guess that the code reuse between the server-side and client-side would be minimal. – Mark Mar 31 '11 at 21:53
  • You think? In a simple web page, form input validation can be reused, and in complex web applications with high levels of interaction, I can imagine nontrivial code being shared. No? – salezica Mar 31 '11 at 21:55
  • 2
    @Mark code re-use is huge. I'm writing a heavy client/server multiplayer game. 70% of the code is re-used. – Raynos Mar 31 '11 at 22:00
  • That's quite surprising to me. And very interesting. – Mark Mar 31 '11 at 22:01
1

at the moment i am using a great isometric game engine written in node.js network created paths,viewports,cameras,maps.. if you happen to want to make a MMO for millions of ppl.. then node.js can be an option.

Ron
  • 11
  • 1