This reads a bit like a parody of all the other node is awesome blog post out there. Node is fine and all but maybe it's time to put down the kool-aid. Also I find it a little bold to claim that node is "faster than any other server language / platform out there", even worse there is absolutely no numbers to back up any of this guys claims.

I cringe whenever people bring up point 1.

Just because your front-end uses JS, doesn't mean that the same code runs on the back-end. You still have to write new code.

I guess there are 2 good parts about it, though. For one, you get awesome HTML/XML parsing & traversing out of the box. Which can be nice, I guess.

Also, you get to use some preexisting JS libraries. Underscore is the biggest one that comes to mind. (Does coffeescript work? haven't tried that one) JQuery works theoretically, but it does mostly DOM stuff, which isn't used enough to warrant the huge lib.

Yes, CoffeeScript produces plain-vanilla JavaScript that works fine on both the browser and the server. The CoffeeScript compiler itself also works in any JS runtime...

For an example of what a CoffeeScript/Node app looks like, take a peek at this:

http://github.com/jashkenas/api-playground/blob/master/src/a...

Thanks. I assumed it would. Cool link.

It depends on how complex your front-end is. As you put more logic on the client-side, the chance of some of that code being useful on the server-side grows.

For example, the Objective-J compiler and loader system ( http://github.com/280north/cappuccino/tree/master/Objective-... ) runs with almost no modification both in the browser-- for on-the-fly compilation during development-- and from the command line-- for pre-compilation prior to deployment. (As an aside it runs on Narwhal, not Node.JS. But the point stands.)

Why can't you run the same code...? Can't you at least use the same domain objects?

In theory, you could use the same code provided you wrote it so that it would work independent of it's environment. Realistically, because server-side JavaScript and Node in particular is still new, most people haven't done that. For instance, on the client-side you're probably using XMLHttpRequest to pull in data via a web service. On the server side, you'd likely be fetching that data locally using a server-side library written for node. In that regard, you wouldn't be using the "same" code. However, you could (again, in theory) reuse domain objects and even libraries like YUI or jQuery to load, parse and traverse HTML as well as do server-side event handling as the YUI team has recently demonstrated. http://www.yuiblog.com/blog/2010/04/09/node-js-yui-3-dom-man... - There is a video that goes with that somewhere and I think it was linked on HN recently as well.

OT: Can someone refresh my memory on how to emphasize something on HN?

Use asterisks to surround whatever you want italicized. Sometimes, but not always, you can click the little gray "help" next to the input textbox to get such hints.

While client side and server side validation aren't necessarily the same code, the fact that it's the same language makes it possible. If you have JS on the client and Python on the server you will have to write validation code twice regardless.

So no, it's not a given that you will avoid duplication but possible trumps impossible.

Is it possible to gain a thorough appreciation for the benefits and technical implementation of a project like Node.js without being knee-deep in the scalable web app universe? Nothing I have written has needed to handle more than, oh, six requests per eon yet, so I have never felt the constraints of "synchronous, I/O-bound" software development.

I put "synchronous, I/O-bound" in scare quotes because I don't really grok what it means. Sure, I can talk the talk and mumble a few buzzwords under my breath, but when it really comes down to it, I have only a cursory understanding of what "event driven," "asynchronous" or, Hell, even "single threaded" means. I've read the Wikipedia pages and made it to "Hello world" with a few of these concepts, but I feel like I'm really missing a huge chunk of very important knowledge & experience.

What kind of project can I work on that would go down this road? Are there any good books, physical or electronic? Or am I doomed to be disconnected from this universe of experience until one of my crappy web projects gets Digged and I learn through trial by fire? I just know there's more to this than "asynchronous method calls will not block method calls that come after them."

EDIT: I noticed that someone downvoted this--I'd be extremely interested to know why. Am I missing something incredibly obvious?

Try making something that depends on an I/O resource that is really slow, that will give you more of a feeling for it quickly.

I did this in one of my projects (Ajax-Gist.com) where I was directly querying a 3rd party API (GitHub) for each request. That meant that each request was client->server roundtrip time plus server->api roundtrip time, which worked out to be around 200ms, or a total throughput of 5 requests per second.

This is obviously unacceptable and a complete waste of resources so I re-wrote the whole thing to be asynchronous. The new application, running in a single thread on the same hardware can now handle around 70 requests per second with 30 concurrent users. That's pretty damn fast for a Rails application...

Now I didn't use Node to solve my problem (though I considered it!) but the principles and the message I took away was the same. I think it's a handy tool to have in your toolkit, but as you've already realized it's simply not necessary for a lot of projects, particularly smaller ones.

Just FYI, http://ajaxgist.com results in a 404.

What library/technique did you end up using to make your app asynchronous?

Haha, I got my own domain name wrong! Clearly it's been a long day...

Link: http://ajax-gist.com/

In the end I built what was essentially a proof-of-concept asynchronous Rails 3 application. The libraries I used under the hood to get everything async were:

* Rack/Fiber-Pool: http://github.com/mperham/rack-fiber_pool

* EM Synchrony: http://github.com/igrigorik/em-synchrony

* Eventmachine: http://rubyeventmachine.com/

Using Rails for what is essentially a thin proxy is overkill, and I could have gotten better performance with Node or by writing a Rack application directly. But I wanted to take the opportunity to get a handle on what would be involved with doing this in Rails, as not too many people have done it before that I am aware of (and at the time no-one had done it with Rails 3).

Thanks! It sounds like you definitely blazed a couple of trails. Nicely done! I shall certainly peruse all of this; I appreciate the thorough response.

No worries! I'm always happy to answer questions via email as well if need be.

learning a little about libev and epoll is a good starting place.

Wouldn't going so low-level be a bit counter-productive at this point in his learning process? I would think that playing with existing async systems like Node, EventMachine and Twisted would be more productive in the short-term and give him a base on which to build deeper knowledge...

It's not that it would be counterproductive; it's simply impenetrable. I read libev's awful homepage and perused the epoll manpage, but they don't mean anything to me--I don't have enough context for them to sink in. (Also... and I say this understanding that I am a man filled with ignorance and hubris... how relevant can libev really be, if its canonical source repo is still maintained with cvs?) But, manpages are rarely where one goes to begin learning about something... on the very first section, I am already inundated with things that mean nothing to me: what are "edge-triggered" and "level-triggered?" What does it mean to "watch" a file descriptor?

I know just enough about GNU/Linux I/O to be dangerous, so I can start to build an inkling of understanding based on this information: "watching" a file descriptor is probably how we register event listeners, and "edge vs. level" is most likely a decision about when handlers receive their data. But that's about as far as I can get before I have to start descending into the terms I don't completely understand. When I find something that explains those, it will probably rely on a bunch of other terms that I must descend into, and so forth. By the time I finally recurse all the way back up to my original quest for knowledge ("What does event-driven mean?"), I will be so inundated with new information that nothing sticks!

Thanks for the suggestion about Twisted, EM and Node.js... I'll have to make some time to play with them soon.

Exactly... That is why I recommend sticking to high-level libraries and tackling a simple real-world problem to start off.

Even just playing with writing some meaningful client-side JavaScript will be enough to give you more of a 'feel' for event-driven programming...

It's not going to give you a huge amount of knowledge straight out but it will definitely give you enough to get you started if you decide to go further.

I don't believe so, unless you know exactly what asynchronous IO is and why you might need to use it then it might just seem like a more complicated method of programming. The "why" of asynchronous IO is very well explained by the C10K problem <http://www.kegel.com/c10k.html>.

That link may be exactly what I need. Thank you!

I can't believe I'm turning into "that guy who bellyaches about profanity," but... did the "beep beep, motherfucker" really add anything to the post?

I generally hate casual swearing only for the fact that it degrades the shock value all of our best swear words.

You're right. It's a fucking tragedy, is what it is.

"She wants you to come back and play with her" is equally classy.

Yeah, I hadn't made it to that part yet, when I wrote my comment. It confused the bejeezus out of me, actually; every time I made it to one of the interstitial images with the juvenile captions, I kept thinking I had accidentally alt-tabbed to some 14-year-old's Counterstrike fansite or something. The cognitive dissonance was nontrivial.

dude stop being so old. not everyone is a crusty old programmer that can't be hyped up by anything. there used to be a time when programming was fun and we enjoyed being pumped up about new technologies. chill out MOTHER FUCKER!

You're right bro! I need to put down the NEWSPAPER (which is read by DINOSAURS) and get AMPED about some SWEET SHIT. If I can't chill out like a COOL DUDE, then I should just go narc out. With the narcs. In narctown! Thanks, guy! Dudesef! Broheim!

I am pretty interested in the potential for multiplayer game servers written in Node.js. Most every post about Node that I have seen seems to focus on it as a web server/web app platform... but it's not. Using JavaScript for the game on the client side (and I don't mean in a browser) would make it that much better.

Here are links to two in-progress fun ones (use Chrome for these), as well as some bits of their source code that are worth reading through...

Lazeroids:

http://www.lazeroids.com

http://github.com/gerad/lazeroids-node/blob/master/lazeroids...

Orona:

http://stephank.github.com/orona/bolo.html

http://github.com/stephank/orona/blob/master/src/objects/tan...

... those are in-browser, of course, but a lot of that logic isn't browser-specific.

What's the Javascript story on the server side when we have real interoperability needs? For instance, in the corporate world where there are huge Java or .NET libraries that I absolutely need to access with good performance.

Is there an easy path to access JVM and .NET code with V8? And if not, has Microsoft released an interoperability story for the ie9 javascript engine?

Clearly there is huge momentum with javascript as a dynamic scripting language, which probably is going to last a while given that the client side is going to stay javascript for a while. But I'm wondering if it can replace Jython/IronPython where those are needed.

Is this article serious, or is it a parody? (Honest question)

So how does the concurrency of node.js compare to a web framework written in Erlang?

ASP pages could be written in Microsoft's ECMAScript variation of JavaScript (JScript), and they even carried the tradition on to JScript.NET (with blazing fast performance. JScript.NET was the underappreciated step-child of the .NET ecosystem).

http://msdn.microsoft.com/en-us/library/ms974588.aspx

I don't even know if that is still around, as it never really gained much traction.

Nonetheless, I was using the "same language on the client and the server" argument 14 years ago. Nice to see the world caught up to my utter brilliance.

he left out this caveat about the nginx comparison:

"Please take with a grain of salt. Very special circumstances. NGINX peaked at 4mb of memory Node peaked at 60mb."