Common Node (https://github.com/olegp/common-node/) gives you the best of both worlds: it's easy to develop in & debug just like Ringo yet has low memory usage and is easy to integrate with existing Node libraries.

Here's a very simple CMS I wrote in it: https://github.com/olegp/mcms

Here's a canonical blog example that also shows the use of the synchronous Mongo driver: https://github.com/olegp/notes

Cheating! It's not in core. Yes, it largely solves the problem at hand, but we're not talking about node + fibers or even the node + features they're currently working on. We're talking about node. Node doesn't have fibers. Although I wish it did! Fibers really don't belong in the user-space ...

Also, even if one opposes the idea of co-routines due to the problem of not knowing which function will yield, there's no denying that they provide one of the best current solutions to the flow control issues with a clean upgrade path to generators when those become available in V8 in 18 months or so.

The majority of software like a CMS is not self-sufficient. It needs a database, a filesystem, it talks to the http server, it might talk to a dozen other services (generate thumbnails, upload some files to a CDN, scan for viruses in an upload, etc. etc.). You get the idea.

Each external dependency is a blocking dependency. You need to handle it and it isn't easy. Node provides you the tools, but unlike in our first example, where the only thing that blocks is the filesystem, here you have dozens of services that block, with hundreds of pain points. Writing code becomes a chore that is very unpleasant.

That's not the worst of it.

If you miss a blocking operation and don't handle it properly in node, which is very easy, your entire server will go down. In a thread-based or multi-process server-side language mistakes are painful, but not fatal. In node, missing a blocking operation is fatal.

The node guys get this. That's why they're busy trying to cook up a solution around this problem. But they don't talk about it or advertise it.

As of right now, node is definitely not a general purpose solution. It is, however, an excellent solution where you don't have a lot of dependencies that block.

The alternatives are to run everything in its own process, which uses too much RAM or to use threads, which are very difficult to reason about. (Did you really acquire locks in an order that guarantees you will never deadlock? Is your date formatting library threadsafe?) Finally, there is threads and STM, but STM adds overhead and retrying transactions wastes resources.

None of those solutions are very good, and node is in the same place: it is another not very good solution to concurrency. Right now, nobody in the world can come up with anything better. To do concurrency right, you have to be very careful, and those caveats apply to all the other concurrency mechanisms. node's event model is basically equivalent to the other mechanisms; fatal if done wrong. Doing one thing in one place makes the process model work. Not having any state shared between application operations makes threads work. Event-driven systems are a compromise between the two: you can share state between logical threads of execution, but the order in which state updates occur is deterministic.

Every model has its strengths and weaknesses, and node has strengths and weaknesses.

I'm also a bit puzzled by your statement that there are people working on the problem but not talking about it. Do you have some inside information? :) I do agree that it is a solvable problem, however.

A blocking operation is essentially anything that takes a while to complete. It blocks everything, because node is focused on doing that one thing. Usually this happens with external services, where node requests something and then waits for a response. Those are easy to spot. But you can write code in any language that takes a while to do something. And it's very easy to do so and miss your mistake =)

> I'm also a bit puzzled by your statement that there are people working on the problem but not talking about it.

I don't mean it's a secret or something. They talk about it on Google Groups and in change logs. I'm saying that's something that should be on their front page of their website explaining things. Maybe have a nice little chart of dos and don'ts.

As soon as you code an endless loop in a function it blocks the server forever. Do a long calculation: it blocks for the time running. Node is no magic dust which turns everything it touches into asynch high speed code.

Node is asynch only when it comes to operations that are external to your code. (network, file system) . One could even argue that CPU intensive code being external to node but running on the same server could block if it's not running on a different CPU altogether.

My latest project runs Python/Pyramid and MongoDB for the more traditional computational stuff. We have a notification architecture running through node.js/socket.io sending real-time events down to the browser.

It works beautifully.

All of that COULD have been implemented within the Pyramid layer (or Twisted..or whatever), but it would have been much more difficult and time-consuming to do.

I could have done it in PHP, but it would have been an absolute nightmare.