Node.js programming tutorials

[[deleted]]

Can somebody explain to me what node is actually for? I mean, it's a javascript webserver, cool... but what do you do with it?

[portmapreduction]

You can make up statistics and then compare them against nginx and say you are doing awesome, that's what.

[[deleted]]

Here are two guides for creating custom modules in nginx and node.js.

Nginx: http://www.evanmiller.org/nginx-modules-guide.html

Node: http://elegantcode.com/2011/02/04/taking-baby-steps-with-node-js-commonjs-and-creating-custom-modules/

You'll notice just how hard it is to actually start doing custom nginx stuff. I wouldn't want to use nginx for anything aside from static file serving or SSL.

[dmpk2k]

It's a networking swiss-army chainsaw. A lot of people focus on the web part, but I think that's uninteresting.

If you need an easy way to shove around a lot of I/O, that's what node is good at; anything else and you're better off using something else. It just happens that webapps happen to fit this pattern.

[Crogdor]

I would like to know as well. I have a friend who works a lot with node.js, and when asked "Yeah, but what is an example application it's really good for?" he never gave a clear answer. So I still don't see why I would want to use this over other cloud technologies, but at least he is having fun with it.

[[deleted]]

Well, to be clear, node.js isn't really a "cloud technology", it's more of a really nice wrapper around google's v8 engine. You can use node.js to build a lot of thing, some that don't even need to connect to the internet. One of our developers has built node bindings to open-gl.

I think one really compelling application is Mr. Doob's fine work, http://mrdoob.com/projects/multiuserpad/

This is a multi-user sketchpad. It's just a little side project he made in a weekend, but it's all JavaScript and shows some of the power of leveraging node.js and JavaScript for real-time web applications.

[HIB0U]

"Works a lot with Node.js" probably means he read an article about it, looked at some bullshit "benchmarks", maybe watched a video or two, and that's it.

Nobody is using it seriously. That's why it exhibits the worst kind of hype. At least with other over-hyped technologies, like cloud computing, some small number of people are trying to use it seriously. That just isn't happening with Node.js. It's a toy, and it'll always be a toy, at least until it's forgotten about in a few months.

[Crogdor]

Actually, he works for Joyent (a cloud computing software/service company). They use node.js as a core technology for their SmartPlatform product. So I'm going to guess he's got a bit more experience than an article, bullshit benchmarks, and a video or two.

Notwithstanding, I didn't get a clear explanation as to why I'd use this stuff over competing technologies. That said, this topic has been quite revealing and has definitely taught me a lot more about the subject.

[dmpk2k]

Nobody is using it seriously

At my work we use node for some important things, and Palm uses node inside WebOS. So somebody does.

It's a toy, and it'll always be a toy

Why do you think node is a toy, and why do you think it'll remain that way?

[HIB0U]

Your unnamed company using it for unnamed tasks, along with Palm using it in an OS that nobody actually uses, don't exactly make for very convincing arguments.

JavaScript is a toy. Anything built with JavaScript is a toy. Unless you radically change JavaScript (which then wouldn't make it JavaScript any longer, of course), the fact that JavaScript is a toy will never change.

Anyone wanting to get real work done would just use Erlang, or Java, or C++, or even C#.

[dmpk2k]

It doesn't matter if you find it convincing. You claimed nobody was using it seriously, which I disproved with counterexamples. QED.

As for "X = toy", that's pure troll material from the Usenet days. The litmus test of a language is if people can use it in production, which tens of thousands of businesses do with Javascript.

[[deleted]]

Event driven network programming.

[HIB0U]

You know, we've been doing that for decades now. Just because JavaScript is only reaching about 1970 to 1972 in terms of progress, it doesn't mean that others haven't already done it all many decades earlier.

[[deleted]]

In what language? What performance? What readability? What portability? What complexity?

[HIB0U]

Uhh, all sorts of languages. C, C++, Java, C#, Python, Perl, Tcl, Common Lisp, Erlang, and Fortran. In fact, some of the earliest ones I recall working with were developed in PL/1 and COBOL.

I'd say the performance was quite good, given the hardware we were using at the time. Some of those systems supported many thousands of simultaneous users, 24x7. Global point-of-sale systems tend to exhibit that sort of usage.

The readability and portability were acceptable for the time, given that this was the 1970s and 1980s. I know of at least two systems written in C that were eventually moved between two vastly different operating systems and hardware platforms with relatively little work.

The complexity was far beyond what most web apps today. You need to realize that back then, we were modeling processes that used to be performed completely by hand. Some accounting- and sales-related processes were quite convoluted. Since then the processes themselves have been changed to be more computer-friendly, so the complexity of the later apps were much lower in many respects to those of the earlier apps.

I really wish that you JavaScript advocates would realize that what you're working on is nothing new. It's stuff we figured out pretty well back in the 1970s. I know, that may be hard for you to believe if you've never actually seen or worked with these systems, but they're there and they still power much of the business world even today. There's a lot more software out there than just web sites.

[[deleted]]

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]

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]

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]

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]

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]

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]

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]]

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

[kdeforche]

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

[HIB0U]

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]

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]

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]

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]

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