[jjm]

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 a tool. It works well with your _other_ tools.

There - is - no - perfect - tool, no perfect programmer, not even perfect intent.

[tedjdziuba]

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

[jjm]

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.

[exogen]

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.

[tedjdziuba]

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.

[hampusw]

There's nothing keeping you from running a separate web server and then proxying requests to Node using HTTP. Why is it a problem that you do this using HTTP? What alternative protocol would be so much better? FastCGI isn't really that different (each have their pros and cons) and CGI has obvious problems...

WSGI applications can use a built-in HTTP server too (or FastCGI or ...). Node has an internal interface (similar to WSGI) for handing over requests to the web application and so on. That's not fundamentally different from WSGI. The main difference is that WSGI is a standard API, so there are several "WSGI servers" implementing the same thing (each of them similar to Node in some sense).

[ricardobeat]

You're not "forced to marry" the HTTP server to the application, you can keep them as separated as you want.

[exogen]

I'm not sure if many people are choosing Node just because they're familiar with JavaScript. Most people would probably rather be less familiar with JavaScript. More likely they're choosing it because the runtime is very fast and a lot of libraries are packaged for it.

The WSGI/CGI bit is in fact mentioned in the article. :)