I'm not sure why it is bad for building a CMS. Admittedly, node isn't all that mature so doing so might be a little lower level right now than doing the same with, say, Rails. But it has one huge advantage which is that any modern CMS is going to have a good chunk of client side code, and there are immense advantages to having the same language on the client and server.
The majority of services out there are self-sufficient. Take a very simple http server. It needs to talk to the local filesystem and serve the content requested. The only thing in that equation that might block is the filesystem. Node provides you the tools to deal with that and more. Building an http server in node is enjoyable, easy, and the end result performs well.
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.
I disagree with this. Handling one blocking operation is as easy as handling n blocking operations. Yes, you have to handle them, or they will 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.
That makes sense, mostly, but I'm a bit confused as to what you mean by saying it is easy to "miss" a blocking operation such that it will take down your server. It seems pretty hard to have any operation be blocking in node. To my knowledge everything I can do in node is asynch (with exception of a few blocking file functions, but I don't use those as there are asynch versions which are recommended anyway)
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.
> It seems pretty hard to have any operation be blocking in node.
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.
> It seems pretty hard to have any operation be blocking in node ... To my knowledge everything I can do in node is asynch
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.
