A good and well thought reply to a troll
Node.js cures cancer
11–20 of 99 posts
Re: Node.js cures cancer
#12I like how every rebuttal turns into "how fast can you compute a fibonacci number". I was looking for a function that burned a nontrivial amount of CPU, the choice of fibonacci was arbitrary. Let's move on from that. What I was showing was that if your request handler does a nontrivial amount of CPU work, it will hold up the event loop and kill any "scalability" you think you're getting from Node. If you Node guys we…
I would argue that heavily CPU-bound stuff shouldn't be run in a web app. It's much better to offload the task to a worker system via redis/zeromq/kestrel/etc. The majority of activity you see in every web app I've ever designed has been almost exclusively I/O bound.
That's cool and all but in the real world we gotta get it done.
Re: Node.js cures cancer
#13It's not the main point of the article, but I just thought I'd point out that node already does have a WSGI/Rack-style library for folks who like that kind of thing. It's called Strata ( http://stratajs.org ). Disclaimer: I'm the author.
Thanks, I didn't know that. I've added a link to the article.
Re: Node.js cures cancer
#14I like how every rebuttal turns into "how fast can you compute a fibonacci number". I was looking for a function that burned a nontrivial amount of CPU, the choice of fibonacci was arbitrary. Let's move on from that. What I was showing was that if your request handler does a nontrivial amount of CPU work, it will hold up the event loop and kill any "scalability" you think you're getting from Node. If you Node guys we…
If your using node and doing work other than serving simple pages, then your probably sending that work off. Most production serious Node-ers know not to do heavy lifting within the system. I really don't know where anyone from the Node community has ever recommended stuffing their single threaded V8 backed event processor with cpu heavy tasks. I still don't know why people are so maximist with their tools. NodeJS is…
> Most production serious Node-ers know not to do heavy lifting within the system.
So Node is reduced to the trivial work? Then why make it unnecessarily hard on yourself?
> I still don't know why people are so maximist with their tools.
Because moving parts = risk.
Re: Node.js cures cancer
#15Earlier quoted context omitted.
I would argue that heavily CPU-bound stuff shouldn't be run in a web app. It's much better to offload the task to a worker system via redis/zeromq/kestrel/etc. The majority of activity you see in every web app I've ever designed has been almost exclusively I/O bound.
That's cool and all but in the real world we gotta get it done.
Funny, because I avoid putting CPU intensive code in any request handler... in any language. if the calculation takes time, it's better done async.
(and I don't even use node)
Re: Node.js cures cancer
#16I like how every rebuttal turns into "how fast can you compute a fibonacci number". I was looking for a function that burned a nontrivial amount of CPU, the choice of fibonacci was arbitrary. Let's move on from that. What I was showing was that if your request handler does a nontrivial amount of CPU work, it will hold up the event loop and kill any "scalability" you think you're getting from Node. If you Node guys we…
The problem is that fibonacci was a bad choice in your example and it proved nothing.
It is fairly easy to scale node with multiple processes. As long as you don't have a long running (such as fibonacci) operation. If you do have tasks like that, process outside node and check for completion. Like how Tasks work in Google App Engine.
Also, most other web stacks will discourage you from running a 30s fib on a thread processing web requests. This isn't specific to node.
Node and coffeescript has worked really well for us. Product coming out later this month.
[EDIT: Just noticed that several other people pointed out the same thing. Looks like most node users are aware of potential problems, but I can see such issues being confusing for new users.]
Re: Node.js cures cancer
#17Earlier quoted context omitted.
If your using node and doing work other than serving simple pages, then your probably sending that work off. Most production serious Node-ers know not to do heavy lifting within the system. I really don't know where anyone from the Node community has ever recommended stuffing their single threaded V8 backed event processor with cpu heavy tasks. I still don't know why people are so maximist with their tools. NodeJS is…
> Most production serious Node-ers know not to do heavy lifting within the system. So Node is reduced to the trivial work? Then why make it unnecessarily hard on yourself? > I still don't know why people are so maximist with their tools. Because moving parts = risk.
One Node process is reduced to doing the trivial work, like you'd have in any other system.
Nothing is preventing the other processes from also being Node.
Re: Node.js cures cancer
#18guys guys guys. you do realize ted is trolling us all right (go look at his twitter @dozba right now. I think he is having a great time). he is a pro at this (http://teddziuba.com/2011/07/the-craigslist-reverse-programm...)
Also if his thoughts on node.js don't annoy you enough go take a look at his archive: http://teddziuba.com/archives.html. He blogs/trolls/thinks about NoSQL, OS X, twisted/tornado, python, queues and more.
Re: Node.js cures cancer
#19Earlier quoted context omitted.
If your using node and doing work other than serving simple pages, then your probably sending that work off. Most production serious Node-ers know not to do heavy lifting within the system. I really don't know where anyone from the Node community has ever recommended stuffing their single threaded V8 backed event processor with cpu heavy tasks. I still don't know why people are so maximist with their tools. NodeJS is…
> Most production serious Node-ers know not to do heavy lifting within the system. So Node is reduced to the trivial work? Then why make it unnecessarily hard on yourself? > I still don't know why people are so maximist with their tools. Because moving parts = risk.
It is up to you to figure things out based on possible worst case runtime scenario coupled with your expected usage on _your_ hardware. You choose what work is defined 'trivial' (based on your resources). Trivial is always moving, and dependent on the scenario at hand. My trivial is not your trivial.
If the 'work' is too much you move it to another process. Either another NodeJS processor or some agnostic queue based managed worker. That worker could be anything.
OR you decide to use another tool.
Re: Node.js cures cancer
#20Earlier quoted context omitted.
> Most production serious Node-ers know not to do heavy lifting within the system. So Node is reduced to the trivial work? Then why make it unnecessarily hard on yourself? > I still don't know why people are so maximist with their tools. Because moving parts = risk.
One Node process is reduced to doing the trivial work, like you'd have in any other system. Nothing is preventing the other processes from also being Node.
True, and in fact, this is how nginx works: the process that owns the event loop is separate from the process(es) that does the work.
This is a decent way of mixing an event loop and multi-core processing, but with Node, you're forced to marry the HTTP server to the application, which is a dangerously tight coupling of responsibilities.
If you really want to do something silly like write your application in server-side JS because you're familiar with it, then it should be through some interface like WSGI in Python (or even CGI in days of yore), which properly separates HTTP connection handling from application serving.