5 ms·

Why Node.js Is Totally Awesome

21 points by chetan51 16y ago

zbanks 16y ago
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.
- mcantor 16y ago
  Why can't you run the same code...? Can't you at least use the same domain objects?
  - WesleyJohnson 16y ago
    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-manipulation-oh-my/ 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?
    - mcantor 16y ago
      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.
- paulbaumgart 16y ago
  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-J/ 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.)
- jashkenas 16y ago
  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/app.coffee http://github.com/jashkenas/api-playground/blob/master/src/a...
  - zbanks 16y ago
    Thanks. I assumed it would. Cool link.
- cletus 16y ago
  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.
mcantor 16y ago
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?
- zbanks 16y ago
  "She wants you to come back and play with her" is equally classy.
  - mcantor 16y ago
    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.
- hoffmabc 16y ago
  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!
  - mcantor 16y ago
    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!
- jimmyjazz14 16y ago
  I generally hate casual swearing only for the fact that it degrades the shock value all of our best swear words.
  - mcantor 16y ago
jimmyjazz14 16y ago
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.
mcantor 16y ago
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?
- jimmyjazz14 16y ago
  learning a little about libev and epoll is a good starting place.
  - aarongough 16y ago
    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...
    - mcantor 16y ago
      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.
jcromartie 16y ago
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.
- jashkenas 16y ago
  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://www.lazeroids.com http://github.com/gerad/lazeroids-node/blob/master/lazeroids.coffee http://github.com/gerad/lazeroids-node/blob/master/lazeroids... Orona: http://stephank.github.com/orona/bolo.html http://stephank.github.com/orona/bolo.html http://github.com/stephank/orona/blob/master/src/objects/tank.coffee 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.
darkhorse 16y ago
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."
ergo98 16y ago
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 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.
ph0rque 16y ago
So how does the concurrency of node.js compare to a web framework written in Erlang?
ericflo 16y ago
Is this article serious, or is it a parody? (Honest question)
equark 16y ago
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.

21 points by chetan51 16y ago

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.

mcantor 16y ago
Why can't you run the same code...? Can't you at least use the same domain objects?
- WesleyJohnson 16y ago
  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-manipulation-oh-my/ 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?
  - mcantor 16y ago
    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.
paulbaumgart 16y ago
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-J/ 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.)
jashkenas 16y ago
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/app.coffee http://github.com/jashkenas/api-playground/blob/master/src/a...
- zbanks 16y ago
  Thanks. I assumed it would. Cool link.
cletus 16y ago
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.

mcantor 16y ago

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?

zbanks 16y ago
"She wants you to come back and play with her" is equally classy.
- mcantor 16y ago
  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.
hoffmabc 16y ago
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!
- mcantor 16y ago
  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!
jimmyjazz14 16y ago
I generally hate casual swearing only for the fact that it degrades the shock value all of our best swear words.
- mcantor 16y ago

jimmyjazz14 16y ago

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.

mcantor 16y ago

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?

jimmyjazz14 16y ago
learning a little about libev and epoll is a good starting place.
- aarongough 16y ago
  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...
  - mcantor 16y ago
    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.

jcromartie 16y ago

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.

jashkenas 16y ago
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://www.lazeroids.com http://github.com/gerad/lazeroids-node/blob/master/lazeroids.coffee http://github.com/gerad/lazeroids-node/blob/master/lazeroids... Orona: http://stephank.github.com/orona/bolo.html http://stephank.github.com/orona/bolo.html http://github.com/stephank/orona/blob/master/src/objects/tank.coffee 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.

darkhorse 16y ago

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."

ergo98 16y ago

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

ph0rque 16y ago

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

ericflo 16y ago

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

equark 16y ago

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.