Será que os dias de Dom Quixote do Jester estão próximos ao fim? Kevin Dangoor, conhecido pelo seu trabalho com o TurboGears está com uma proposta ousada e interessante. Em um post em seu blog ele faz uma espécie de roadmap com a lista do que falta no JavaScript para que ele possa ser usado como uma linguagem de desenvolvimento no lado do servidor de forma factível. Entre outras coisas: a fragmentação das diversas implementações, a falta de uma biblioteca padrão cross-implementação, o problema de interfaces, namespaces…
Para tentar dirimir alguns desses problemas, Kevin criou um grupo de discussão, para tentar aglutinar todos os players, e procurar alguma solução em comum. Algumas coisas já estão caminhando: já existe um padrão semelhante ao WSGI e ao Rack para JavaScript, uma página wiki já foi criada no site da Mozilla, um canal de IRC (#serverjs) já existe no FreeNode, e das coisas não lançadas publicamente temos o Rhino on Rails, do Steve Yegge.
Vejam que ainda que fosse liberado logo o código do Rhino on Rails, ele não é ‘portável’ para outro ‘interpretador’ de JavaScript. Ainda temos um longo caminho a percorrer 
Abaixo, um vídeo do Yegge falando do Rhino on Rails.
Tava procurando aqui nas pilhas de e-mail minha última manifestação sobre js no servidor. Achei:
http://article.gmane.org/gmane.comp.mozilla.devel.jseng/8004
Essa mensagem já tem dois anos e eu não movi uma palha nesta direção. Alias, experimentei com algumas coisas, é verdade, mas a tarefa me pareceu tão abrangente e complexa que fiquei desmotivado. Não que seja algo abrangente e complexo fazer o apache se comunicar com o spidermonkey (ou esses outros brinquedos recentes). Certamente fazer o rhino tomar conta das requisições do tomcat é, no mínimo, trivial.
Porém, JS é tão minúscula que fazer um design da camada seguinte ao core me perturbou. Novamente, não porque seja difícil fazer um dlopen, adicionar API de conexão com SGBDs, manipulação de arquivos, e a parafernália necessária. Certamente podemos adicionar todas essas pontes e funcionalidades num trabalho basicamente braçal. Isso, com certeza, não seria uma tarefa de design, e sim, uma tarefa de colocar a disposição o que as outras linguagens (python, ruby, php..) já fazem, sob o risco de fazer algo tão semelhante, que até os erros são copiados.
Agora, implementar e oferecer estas funcionalidades respeitando a natureza do JS, considerando suas características (closures, herança por protótipos, especialmente) e considerando a importância desse forro para os usuários-programadores….isso, definitivamente, é um projeto não-trivial. E, se pessoas o fizerem, se isso gerar frutos….eu não acredito que serão maduros. Por outro lado, se alguém fizer isso bem feito, eu terei uma grande motivação para voltar a querer fazer “webstuff”.
Esse é o Tsilva que eu conheço … a procura do código perfeito