Como decidir quando usar o Node.js?

Fizeste um óptimo trabalho a resumir o que é fantástico no Node.js. Minha sensação é que o Node.js é especialmente adequado para aplicações onde você gostaria de manter uma conexão persistente do navegador de volta para o servidor. Usando uma técnica conhecida como "long-polling", você pode escrever uma aplicação que envia atualizações para o usuário em tempo real. Fazer longas pesquisas em muitos dos gigantes da web, como Ruby on Rails ou Django, criaria uma carga imensa no servidor, porque cada cliente ativo come um processo do servidor. Esta situação equivale a um ataque tarpit. Quando você usa algo como o Node.js, o servidor não tem necessidade de manter threads separados para cada conexão aberta.

Isto significa que você pode criar um aplicativo de chat baseado em navegador no Node.js que quase não precisa de recursos do sistema para atender a um grande número de clientes. Sempre que você quiser fazer esse tipo de polling longo, o Node.js é uma ótima opção.

Vale a pena mencionar que Ruby e Python têm ambos ferramentas para fazer esse tipo de coisa (eventmachine e twisted, respectivamente), mas que o Node.js faz isso excepcionalmente bem, e do zero para cima. O JavaScript está excepcionalmente bem situado em um modelo de concorrência baseado em callback, e ele se sobressai aqui. Além disso, ser capaz de serializar e deserializar com JSON nativo tanto para o cliente quanto para o servidor é bastante elegante.

Estou ansioso para ler outras respostas aqui, esta é uma pergunta fantástica.

Vale ressaltar que o Node.js também é ótimo para situações em que você estará reutilizando muito código em toda a lacuna cliente/servidor. O Meteor framework torna isto realmente fácil, e muitas pessoas estão sugerindo que este pode ser o futuro do desenvolvimento web. Eu posso dizer por experiência própria que é muito divertido escrever código em Meteoros, e uma grande parte disso é gastar menos tempo pensando em como você vai reestruturar seus dados, para que o código que roda no navegador possa facilmente manipulá-lo e passá-lo de volta.

Aqui está um artigo sobre a Pirâmide e as sondagens longas, que acaba por ser muito fácil de montar com uma pequena ajuda do gevent: TicTacToe e Long-polling with Pyramid.

Eu acredito que o Node.js é mais adequado para aplicações em tempo real: jogos online, ferramentas de colaboração, salas de chat, ou qualquer coisa onde o que um usuário (ou robô? ou sensor?) faz com a aplicação precisa ser visto por outros usuários imediatamente, sem uma atualização de página.

Devo também mencionar que Socket.IO em combinação com Node.js irá reduzir a sua latência em tempo real ainda mais do que é possível com sondagens longas. Socket.IO voltará a sondagens longas como o pior cenário possível e, em vez disso, utilizará soquetes web ou mesmo Flash se estiverem disponíveis.

Mas também devo mencionar que praticamente qualquer situação em que o código possa bloquear devido a threads pode ser melhor tratada com o Node.js. Ou qualquer situação em que você precise que a aplicação seja movida por eventos.

Além disso, Ryan Dahl disse em uma palestra que uma vez eu assisti que os benchmarks do Node.js rivalizam muito com o Nginx para pedidos HTTP antigos e regulares. Então, se construirmos com o Node.js, podemos servir nossos recursos normais de forma bastante eficaz, e quando precisamos do material orientado por eventos, ele está pronto para lidar com isso.

Além disso, é tudo JavaScript o tempo todo. Lingua Franca em toda a pilha.

Para que seja breve:

O Node.js é bem adequado para aplicações que têm muitas conexões simultâneas e cada requisição só precisa de muito poucos ciclos de CPU, porque o loop do evento (com todos os outros clientes) é bloqueado durante a execução de uma função.

Um bom artigo sobre o loop de eventos no Node.js é Mixu's tech blog: Understanding the node.js event loop.