De qualquer forma, sendo pragmático: aprendam Smalltalk, aprendam Seaside. Como Dave Thomas (The Pragmatic Programmer) diz: aprenda pelo menos uma nova linguagem todo ano. Smalltalk é definitivamente uma ótima escolha. Erlang, Haskell, Scheme, O’Caml, todas excelentes escolhas que representam uma quebra de paradigma do estilo procedural/OOP que estamos acostumados.
Mas será Seaside um bom substituto para Rails? Difícil dizer. Minha sensação é que voltamos à discussão do começo dos anos 90: componentização. O fator principal disso são estados persistentes sendo desenvolvidos num protocolo que não suporta estados (HTTP). Já passamos por isso. Precisamos ver até onde vai o buraco do coelho nesta nova tentativa. Definitivamente, o StrongtalkVM (que a Sun tornou open source recentemente) é uma VM que eu gostaria de ver rodando Ruby – mais do que eu já gosto de ver o JRuby ou IronRuby.
Eu ainda não encontrei nenhum bom (e sério) benchmark específico de Seaside. Mas sobre deployment, não é muito diferente do que já estamos acostumados com Rails: Load Balancing. A diferença: Rails usa o conceito shared-nothing (inspirado no PHP) ou seja, vá jogando múltiplos processos e múltiplas máquinas ao problema. No Seaside (que usa o Comanche ou Aida) há um gotcha: Seaside depende muito de Sessions (lembram da discussão de componentização que mencionei? Estamos falando de stateful. Para os javeiros: lembram da diferença entre um Stateful EJB e um Stateless EJB?). Portanto, estamos falando de Load Balance com Sticky Sessions. Vejam alguns insights neste blog. Esta discussão também pode ajudar. Assim como em Rails, não há mágica quando estamos falando de ambiente de produção.
Do mesmo autor do artigo acima, esta receita para instalar Seaside no Ubuntu deve ser melhor (novamente, leiam os comentário também).
Finalmente, leiam este artigo no caboose, principalmente os longos comentários depois do artigo para terem a contra-visão. Mas não esperem nenhuma conclusão, este assunto ainda está longe de se esgotar. Eu ia traduzir mas o artigo é tão longo e boa parte do filé estão nos comentários, então desisti :-)
Infelizmente, o problema não são os frameworks é o protocolo. O tempo todo estamos buscando maneiras de compensar suas limitações. O problema: é extremamente difícil criar um novo HTTP (imagine substituir TODA a internet, de servidores a browsers). Daí as abstrações: podemos ficar perto do HTTP (objetos request, response – PHP, Rails) ou abstrair ao máximo no nível de componentes (WebObjects, ASP.NET, Tapestry, Seaside). Já vi essa discussão acontecendo 10 anos atrás, e até hoje não chegamos a um consenso pelo fato que estamos discutindo uma camada acima do problema: HTTP é praticamente imexível, portanto essa discussão está bem longe de acabar.
Vale lembrar por que o HTTP é do jeito que é: não foi deliberamente uma burrice do seu criador. Foi uma solução inteligente dados os requerimentos da época: performance, estabilidade, redes lentas, conexões que se quebram (não existiam links de 8mbits que temos em casa hoje). A nova investida sobre o mesmo assunto são continuations que permite componentes stateful com performance comparável a stateless. Rife, no Java, usa conceitos similares às continuations de Scheme, outros frameworks também estão começando a investir nessa funcionalidade. Novamente não há mágica: Ruby suporta continuations desde 1998 mas provavelmente será retirada da próxima versão.