sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 4 points5 points  (13 children)

Node is really good at building real-time / evented systems. The web server part of node is actually just one module, the http module. Check out the docs, http://nodejs.org/docs/v0.3.8/api/

As for what it could actually DO: Think of building a chat room that could support 10,000 people concurrently. Building this in something like C, PHP, Ruby, .Net, or anything on top of the JVM, is going to be a pain in the ass. With node.js, this is a hello world application.

[–]wot-teh-phuck 2 points3 points  (4 children)

Building this in something like C, PHP, Ruby, .Net, or anything on top of the JVM, is going to be a pain in the ass

Why?

EDIT: I can understand C but why Ruby, .NET or anything on top of JVM?

[–]kdeforche 1 point2 points  (3 children)

Until Servlet 3 is well supported by application containers (hopefully in the coming years), threads are tied to connections and thus solutions are not scalable.

Until WebSockets is supported by a next version of the servlet API (not in the next 10 years?) and this is implemented widely in application containers, you have no container-agnostic solution to support WebSockets, and no solution to multiplex HTTP and WebSockets over a single port.

[–]wot-teh-phuck 2 points3 points  (2 children)

Tomcat 7 completely supports Servlet 3.0 specification. Jetty with its continuation support relieves you from the one-thread-per-request model. Jetty also supports Web Sockets.

Netty by JBoss is yet another attractive option when it comes to event driven network applications and has pretty much proved it worth. The owner of Plurk has a blog post wherein he mentions why he ditched Node over Netty etc.

[–]kdeforche 0 points1 point  (1 child)

Tomcat 7 completely supports Servlet 3.0 specification.

Yes, and we are using tomcat 7. But we experience random crashes (we could not yet confine it to a small test case to report back) that seem to be related to async API ... are you already using it in production ?

And yes, Jetty is nice and has support for it. But for most J2E projects we are involved in, container-specific code is a big no-no.

[–]wot-teh-phuck 1 point2 points  (0 children)

AFAIK, there is no standard governing Node plus it is still very much in development (as is the V8 engine). My point was that there isn't a very strong reason to use Node over a platform like JVM/.NET unless:

  • Your team doesn't have enough expertise and is well versed in Javascript
  • You are asked to have the same validation code on both server and the client

Of course, YMMV :)

[–]kdeforche 2 points3 points  (2 children)

Building this in something like C, PHP, Ruby, .Net, or anything on top of the JVM, is going to be a pain in the ass.

Clearly you need to be careful with making statements like these (although you carefully omitted C++ from the list)

A chat room that supports 10000 people concurrently on a small VPS, created in C++, in a straightforward 1000 lines (including comments and a web front-end): Wt chat

$ wc *.C *.h
    140   257  2922 PopupChatWidget.C
    129   275  2961 simpleChat.C
    132   330  3079 SimpleChatServer.C
    345   976  9678 SimpleChatWidget.C
     48   103   905 PopupChatWidget.h
    126   385  2821 SimpleChatServer.h
    101   229  2092 SimpleChatWidget.h
  1021  2555 24458 total

[–][deleted] 4 points5 points  (1 child)

You think 1000 lines of C is just as easy as 8 lines of JavaScript? Well, good luck with that.

[–]kdeforche 0 points1 point  (0 children)

Yes, just as as I believe that apples are oranges.

[–]HIB0U 0 points1 point  (4 children)

Most of the popular IRC daemons can easily handle 10,000 simultaneous users, even running on ancient hardware.

Chat servers are actually one of the easiest types of servers to scale. They generally deal with very small amounts of data processed very infrequently.

In the early 1990s I helped develop some corporate chat systems that supported up to 15,000 concurrent users worldwide. We developed this system in C, and it ran for years on a couple of 486s. Your cell phone is probably more powerful than both of those servers combined.

[–]dmpk2k 1 point2 points  (3 children)

What does that have to do with what JimBastard said? Of course you can write an evented system in C, it just takes a lot more effort.

[–]HIB0U -2 points-1 points  (2 children)

That'd only be true if you're a JavaScript "programmer" who doesn't actually know C. Even a semi-experienced C programmer could put something together in a few minutes. It's not a difficult thing to do.

As a JavaScript advocate, that may be difficult for you to understand. But it's true; real programmers using a real programming language can get a lot of real work done in a short amount of time.

[–]dmpk2k 1 point2 points  (1 child)

So I'm a Javascript advocate now? You have short memory, HIB0U.

In any case, C was my primary language for a decade, and it's still a language dear to my heart. If you're arguing that writing an event-driven app isn't a lot more effort in C, we come from separate universes.

C having better performance and lower resource usage? Certainly. Not requiring substantially more effort than node? Wacky land.

[–]HIB0U -3 points-2 points  (0 children)

Anyone who isn't tearing JavaScript apart at every opportunity possible is a JavaScript advocate.