6 ms·

Why node.js excites me

82 points by pilif 16y ago

weixiyen 16y ago
The fact that Node.js isn't a complete web development stack = win.
tlrobinson 16y ago
Do we really need another superficial article praising Node.js just because someone dared to say something bad about it?
- weixiyen 16y ago
  To add to this, the other article wasn't even that bad. It was more taking some shots at a few libraries.
- pjscott 16y ago
  I would reply to the substance of your post, but the large number of upvotes that the article has received are reply enough. So I'll reply to the tone: do you really need to imply that the article's author suffers from node.js cultishness? That's unkind, and not well supported by the text of the article itself.
  - tlrobinson 16y ago
    I'm sorry but the first paragraph does come across as cultish. It sounds as though he had to write this "rebuttal" because he was flying high after returning from jsconf (I've been to jsconf multiple times and understand this feeling completely) and couldn't let an anti-Node.js post go un-rebutted. Also, the Node.js "cultishness" here would explain the large number of upvotes...
    - ericflo 16y ago
      I have to admit that if I were re-writing my blog post today, I'd add the "cultishness" to the list of reasons why Node disappoints me. It's really too bad, too, since at its core it's genuinely good technology!
      - silentbicycle 16y ago
        But it's hardly new tech. How many event-loop-based systems are there? Erlang, Tcl, K, Twisted, Tornado, Eventmachine, etc.
      - boucher 16y ago
        I don't think cultishness is inherently bad for a project, you just have to generally ignore the most enthusiastic of the followers.
mcantelon 16y ago
Providing a barebones core and allowing contributors to build onto it is a fairly tried and true strategy (Django and Drupal are two examples that come to mind). As time goes on best-of-breed contributed modules will gain acceptance (socket.io is one that seems to have achieved this).
- weixiyen 16y ago
  There is nothing bare-bones about Django, Drupal, RoR, etc. Node.js is about as bare-bones as you can get without getting into C.
  - mcantelon 16y ago
    I wasn't talking about the nature of the technology, just the degree to which they include a "standard library". There are plenty of pluggable apps for Django and contrib modules for Drupal that are used on almost all sites, but they are not distributed with the project.
monos 16y ago
"With node.js you don't worry about performance (...)" "Now we know that we can easily write well performing servers (...)" these kind of statements are why i rarely read nodejs articles nowadays. you can't just say that in general.
- railsjedi 16y ago
  Why would you dispute that the choice of technology affects performance? V8 is one of the fastest implementations of javascript. Combine that with a culture of nonblocking libraries, and it makes it very easy to write web services that scale for 99% of what developer's need. Sure, if you hit it big, you'll probably need to change things around a bit. But I think its valid to say that with Node, you don't have to worry about performance because by default its really, really fast. Overall I have mixed feeling with my experience with Node so far (the libraries are very young, and extremely flaky). However it makes it dead simple to write apps that scale to a ridiculous level without huge amounts of upfront planning.
  - ericflo 16y ago
    Performance is not the same thing as scalability. A hello world app with a 10 second pause is scalable, but replace that pause with a logging statement and you've just traded scalability for performance.
    - railsjedi 16y ago
      That's where the nonblocking comes in. It relates directly to scalability. It doesn't improve performance, but it allows more requests to come through while you are waiting for external resources like databases to return results (by far the most common cause of slowdowns on web servers). Performance and scalability are not always a tradeoff. When you increase performance at the runtime level, you don't decrease scalability. However it allows you to serve more requests in the same amount of time.
pjscott 16y ago
The problem with node.js, as well as a great thing about it, is that it's still immature and evolving quickly. For example, I notice you mentioned node-paperboy, a handy minimalistic library for serving static files. It's nice, but buggy. If you don't specify a 404 handler function, it'll default to just keeping those connections open indefinitely. If you aren't running it behind something like nginx, there's a trivial security hole where you can encode "../" as "%2E%2E/" in your URL and get access to whatever files node has read access to. Your app seems to be safe (thanks, nginx!), and your code is good stuff, but the node world is full of pitfalls like this. (GitHub self-pimpage: since I use node-paperboy myself, I fixed the security hole and all the stability problems I could find. The patches haven't been merged into the main repo yet, but here's the fixed version: http://github.com/PeterScott/node-paperboy http://github.com/PeterScott/node-paperboy)
- andrewvc 16y ago
  Small world, I've contributed a fair amount of code to node-paperboy. In fact, I'm the person who forgot to check for URL encoding in paths! Thanks for finding that. I thought about the whole 404 thing, funny thing is, I didn't really think of it as a bug at the time, since I had a specific set of use cases where not specifying a 404 would have been senseless. That's the likely cause for my myopia there. However, the deal with paperboy is it's more of a starting point for writing your own file based HTTP server, not so much a drop it in and serve static files affair. It's got some other problems as well. I'd fix them, but I don't really use node.js anymore. If I were still using node here's what I'd look at with paperboy: 1. No tests (ugh) 2. I'm not sure what would happen if you tried serving a large file to a slow client (it reads in a stream based fashion, but since writing to the socket doesn't block, that memory has to go somewhere) Reads might need to be throttled. 3. It doesn't have sensible defaults, like the 404 thing. All that stuff would be trivial to look at, hopefully someone will. I myself am not a node.js developer anymore (doing a lot of eventmachine). Thanks for the patch, I'm sure felix will add it in soon enough.
  - wolfhumble 16y ago
    ". . . but I don't really use node.js anymore." Why is that?
viraptor 16y ago
Since it seems like we're going to be swamped with NodeJS posts this week, could someone tell me why should I look at it if I'm already happy with (diesel | monocle | twisted | eventmachine | poe | ...). Is it simply another way to do the same things, or is there something new about it? Edit: Just realised this looks trollish. Sorry about this - I'm genuinely interested, since I write some evented code, but couldn't find any notable differences here... I'm not sure if I should take time to explore node.js, or is it same old stuff in a new package.
- lzw 16y ago
  If you're happy, then you don't need to look at it now. It could be argued that one is better than the other, but node.js despite seeming to be the anointed one, is not yet at the "you get fired for not using it" stage. It is still the early days for it.
- russell_h 16y ago
  If you're hoping to hire people to use your chosen framework, Node.js might be a better choice than any of the ones you've listed. Its not so much that there are more Node programmers than, say, Twisted programmers (although at this point there very well might be, especially in the Bay Area), but lots of people know Javascript, and both Javascript and Node itself are relatively easy to learn. Edit: I don't mean to pick on Twisted here, I've been using it for about two years, and Node for only around two months, and I really like both.
  - viraptor 16y ago
    I don't agree with this. If you're writing something that's http-only, then this might be true, since that's relatively easy (get data, push data). But if you write anything else, require custom protocols and thinking about state machines implementing specific behaviour with retries and reliable timeouts... "easy to learn" language, is the last thing you're worried about.
    - russell_h 16y ago
      Why not? Using an easy language on a hard problem means you can hire someone who knows a lot about the problem instead of having to worry about the langauge. At least until the language starts getting in your way (and, in my limited experience, between Javascript and Node's Buffers, you won't find yourself too limited on protocol implementations).
lzw 16y ago
My concern about node.js is that it seems difficult to write server code that is readable later.... Since you're constantly creating handlers, it is kinda like programming the movie inception to me. Maybe a higher level abstraction on top might solve that.
- dfox 16y ago
  That higher level abstraction is called "threads" and that is exactly what node.js tries to avoid :)
  - pjscott 16y ago
    Or coroutines, like eventlet uses in Python. It's very readable, and asynchronous. http://eventlet.net/ http://eventlet.net/
    - denik 16y ago
      Another similar library: http://gevent.org http://gevent.org
  - lzw 16y ago
    Processes (or threads) are not the problem, it is shared state / memory / side effects. Erlang has solved this pretty well, and I love the way it works, but do not find myself looking forward to the syntax. Either choice means that the code is harder to read, but erlang is easier to read than node code, I suspect. (Will have to investigate.)
    - fauigerzigerk 16y ago
      You always have shared state somewhere. It makes no sense to me to force myself to have it exclusively in the database by choosing a platform that cannot do shared state or makes it extremely tedious. I agree with you on the handler maze though.
- troygoode 16y ago
  I develop in - and enjoy - node, but that Inception metaphor is brilliant! You do get used to it though. :-)
mcmc 16y ago
"With node.js... you really, truly and most awesomely don't worry about race conditions." Most of node.js's fanbase well and truly believes this nonsense, that you can't have race conditions simply because there is no pre-emption of your running code. In fact, single-threaded, event-based logic can very easily end up in situations where the timing or ordering of network frames impact a response in an unanticipated manner.
- silentbicycle 16y ago
  Hell, you can even get race conditions in Erlang. Despite a fully immutable model. Joe Armstrong makes a point of introducing them early on, so people know to watch for them. Avoiding parallelism removes several kinds of race conditions, sure, but not all of them. You have to know how they occur, how to prevent them. You can't just use node and hope they all go away.
guelo 16y ago
People that love node.js should just admit that the reason they love it is because of Javascript. The js code slingers finally get their shot at server-side, congratulations! The whole event-driven thing comes naturally to them since that's what they've been dealing with on the browser. There are pros and cons to that style, but that's the story of every tool.
nicpottier 16y ago
Can someone point to some more complicated apps that have been built with Node.js? Seems like people always point to some application to validate that Node.js is real and a viable substitute to Rails/Django/Whatever, but then those apps turn out to be incredibly shallow. Even this article's proof positive is a one feature ultra simplistic web app. Where are the Amazons, GitHubs, Diggs, Onions, etc.. Considering that most sites will have to scale on features before they have to worry about scaling on performance it seems like too much focus is put on the groovy non-blocking nature of Node.js.
- tjarratt 16y ago
  Given that I'm writing a client/server app that uses messaging and multi-party communication as an integral feature, you might find the node.js chatroom that Ryan wrote to be interesting. http://chat.nodejs.org/ http://chat.nodejs.org/ It's fairly basic, but I'm not sure what you're looking for given that it hasn't been available for very long. Amazon, github, digg, onion, were all built on very mature technology.
- aaronblohowiak 16y ago
  Node is still very, very young. I think it is a good question to ask, but we aren't there yet.

82 points by pilif 16y ago

The fact that Node.js isn't a complete web development stack = win.

Do we really need another superficial article praising Node.js just because someone dared to say something bad about it?

weixiyen 16y ago
To add to this, the other article wasn't even that bad. It was more taking some shots at a few libraries.
pjscott 16y ago
I would reply to the substance of your post, but the large number of upvotes that the article has received are reply enough. So I'll reply to the tone: do you really need to imply that the article's author suffers from node.js cultishness? That's unkind, and not well supported by the text of the article itself.
- tlrobinson 16y ago
  I'm sorry but the first paragraph does come across as cultish. It sounds as though he had to write this "rebuttal" because he was flying high after returning from jsconf (I've been to jsconf multiple times and understand this feeling completely) and couldn't let an anti-Node.js post go un-rebutted. Also, the Node.js "cultishness" here would explain the large number of upvotes...
  - ericflo 16y ago
    I have to admit that if I were re-writing my blog post today, I'd add the "cultishness" to the list of reasons why Node disappoints me. It's really too bad, too, since at its core it's genuinely good technology!
    - silentbicycle 16y ago
      But it's hardly new tech. How many event-loop-based systems are there? Erlang, Tcl, K, Twisted, Tornado, Eventmachine, etc.
    - boucher 16y ago
      I don't think cultishness is inherently bad for a project, you just have to generally ignore the most enthusiastic of the followers.

mcantelon 16y ago

Providing a barebones core and allowing contributors to build onto it is a fairly tried and true strategy (Django and Drupal are two examples that come to mind). As time goes on best-of-breed contributed modules will gain acceptance (socket.io is one that seems to have achieved this).

weixiyen 16y ago
There is nothing bare-bones about Django, Drupal, RoR, etc. Node.js is about as bare-bones as you can get without getting into C.
- mcantelon 16y ago
  I wasn't talking about the nature of the technology, just the degree to which they include a "standard library". There are plenty of pluggable apps for Django and contrib modules for Drupal that are used on almost all sites, but they are not distributed with the project.

monos 16y ago

"With node.js you don't worry about performance (...)" "Now we know that we can easily write well performing servers (...)" these kind of statements are why i rarely read nodejs articles nowadays. you can't just say that in general.

railsjedi 16y ago
Why would you dispute that the choice of technology affects performance? V8 is one of the fastest implementations of javascript. Combine that with a culture of nonblocking libraries, and it makes it very easy to write web services that scale for 99% of what developer's need. Sure, if you hit it big, you'll probably need to change things around a bit. But I think its valid to say that with Node, you don't have to worry about performance because by default its really, really fast. Overall I have mixed feeling with my experience with Node so far (the libraries are very young, and extremely flaky). However it makes it dead simple to write apps that scale to a ridiculous level without huge amounts of upfront planning.
- ericflo 16y ago
  Performance is not the same thing as scalability. A hello world app with a 10 second pause is scalable, but replace that pause with a logging statement and you've just traded scalability for performance.
  - railsjedi 16y ago
    That's where the nonblocking comes in. It relates directly to scalability. It doesn't improve performance, but it allows more requests to come through while you are waiting for external resources like databases to return results (by far the most common cause of slowdowns on web servers). Performance and scalability are not always a tradeoff. When you increase performance at the runtime level, you don't decrease scalability. However it allows you to serve more requests in the same amount of time.

pjscott 16y ago

The problem with node.js, as well as a great thing about it, is that it's still immature and evolving quickly. For example, I notice you mentioned node-paperboy, a handy minimalistic library for serving static files. It's nice, but buggy. If you don't specify a 404 handler function, it'll default to just keeping those connections open indefinitely. If you aren't running it behind something like nginx, there's a trivial security hole where you can encode "../" as "%2E%2E/" in your URL and get access to whatever files node has read access to. Your app seems to be safe (thanks, nginx!), and your code is good stuff, but the node world is full of pitfalls like this. (GitHub self-pimpage: since I use node-paperboy myself, I fixed the security hole and all the stability problems I could find. The patches haven't been merged into the main repo yet, but here's the fixed version: http://github.com/PeterScott/node-paperboy http://github.com/PeterScott/node-paperboy)

andrewvc 16y ago
Small world, I've contributed a fair amount of code to node-paperboy. In fact, I'm the person who forgot to check for URL encoding in paths! Thanks for finding that. I thought about the whole 404 thing, funny thing is, I didn't really think of it as a bug at the time, since I had a specific set of use cases where not specifying a 404 would have been senseless. That's the likely cause for my myopia there. However, the deal with paperboy is it's more of a starting point for writing your own file based HTTP server, not so much a drop it in and serve static files affair. It's got some other problems as well. I'd fix them, but I don't really use node.js anymore. If I were still using node here's what I'd look at with paperboy: 1. No tests (ugh) 2. I'm not sure what would happen if you tried serving a large file to a slow client (it reads in a stream based fashion, but since writing to the socket doesn't block, that memory has to go somewhere) Reads might need to be throttled. 3. It doesn't have sensible defaults, like the 404 thing. All that stuff would be trivial to look at, hopefully someone will. I myself am not a node.js developer anymore (doing a lot of eventmachine). Thanks for the patch, I'm sure felix will add it in soon enough.
- wolfhumble 16y ago
  ". . . but I don't really use node.js anymore." Why is that?

viraptor 16y ago

Since it seems like we're going to be swamped with NodeJS posts this week, could someone tell me why should I look at it if I'm already happy with (diesel | monocle | twisted | eventmachine | poe | ...). Is it simply another way to do the same things, or is there something new about it? Edit: Just realised this looks trollish. Sorry about this - I'm genuinely interested, since I write some evented code, but couldn't find any notable differences here... I'm not sure if I should take time to explore node.js, or is it same old stuff in a new package.

lzw 16y ago
If you're happy, then you don't need to look at it now. It could be argued that one is better than the other, but node.js despite seeming to be the anointed one, is not yet at the "you get fired for not using it" stage. It is still the early days for it.
russell_h 16y ago
If you're hoping to hire people to use your chosen framework, Node.js might be a better choice than any of the ones you've listed. Its not so much that there are more Node programmers than, say, Twisted programmers (although at this point there very well might be, especially in the Bay Area), but lots of people know Javascript, and both Javascript and Node itself are relatively easy to learn. Edit: I don't mean to pick on Twisted here, I've been using it for about two years, and Node for only around two months, and I really like both.
- viraptor 16y ago
  I don't agree with this. If you're writing something that's http-only, then this might be true, since that's relatively easy (get data, push data). But if you write anything else, require custom protocols and thinking about state machines implementing specific behaviour with retries and reliable timeouts... "easy to learn" language, is the last thing you're worried about.
  - russell_h 16y ago
    Why not? Using an easy language on a hard problem means you can hire someone who knows a lot about the problem instead of having to worry about the langauge. At least until the language starts getting in your way (and, in my limited experience, between Javascript and Node's Buffers, you won't find yourself too limited on protocol implementations).

lzw 16y ago

My concern about node.js is that it seems difficult to write server code that is readable later.... Since you're constantly creating handlers, it is kinda like programming the movie inception to me. Maybe a higher level abstraction on top might solve that.

dfox 16y ago
That higher level abstraction is called "threads" and that is exactly what node.js tries to avoid :)
- pjscott 16y ago
  Or coroutines, like eventlet uses in Python. It's very readable, and asynchronous. http://eventlet.net/ http://eventlet.net/
  - denik 16y ago
    Another similar library: http://gevent.org http://gevent.org
- lzw 16y ago
  Processes (or threads) are not the problem, it is shared state / memory / side effects. Erlang has solved this pretty well, and I love the way it works, but do not find myself looking forward to the syntax. Either choice means that the code is harder to read, but erlang is easier to read than node code, I suspect. (Will have to investigate.)
  - fauigerzigerk 16y ago
    You always have shared state somewhere. It makes no sense to me to force myself to have it exclusively in the database by choosing a platform that cannot do shared state or makes it extremely tedious. I agree with you on the handler maze though.
troygoode 16y ago
I develop in - and enjoy - node, but that Inception metaphor is brilliant! You do get used to it though. :-)

mcmc 16y ago

"With node.js... you really, truly and most awesomely don't worry about race conditions." Most of node.js's fanbase well and truly believes this nonsense, that you can't have race conditions simply because there is no pre-emption of your running code. In fact, single-threaded, event-based logic can very easily end up in situations where the timing or ordering of network frames impact a response in an unanticipated manner.

silentbicycle 16y ago
Hell, you can even get race conditions in Erlang. Despite a fully immutable model. Joe Armstrong makes a point of introducing them early on, so people know to watch for them. Avoiding parallelism removes several kinds of race conditions, sure, but not all of them. You have to know how they occur, how to prevent them. You can't just use node and hope they all go away.

guelo 16y ago

People that love node.js should just admit that the reason they love it is because of Javascript. The js code slingers finally get their shot at server-side, congratulations! The whole event-driven thing comes naturally to them since that's what they've been dealing with on the browser. There are pros and cons to that style, but that's the story of every tool.

nicpottier 16y ago

Can someone point to some more complicated apps that have been built with Node.js? Seems like people always point to some application to validate that Node.js is real and a viable substitute to Rails/Django/Whatever, but then those apps turn out to be incredibly shallow. Even this article's proof positive is a one feature ultra simplistic web app. Where are the Amazons, GitHubs, Diggs, Onions, etc.. Considering that most sites will have to scale on features before they have to worry about scaling on performance it seems like too much focus is put on the groovy non-blocking nature of Node.js.

tjarratt 16y ago
Given that I'm writing a client/server app that uses messaging and multi-party communication as an integral feature, you might find the node.js chatroom that Ryan wrote to be interesting. http://chat.nodejs.org/ http://chat.nodejs.org/ It's fairly basic, but I'm not sure what you're looking for given that it hasn't been available for very long. Amazon, github, digg, onion, were all built on very mature technology.
aaronblohowiak 16y ago
Node is still very, very young. I think it is a good question to ask, but we aren't there yet.