O Ronaldo recentemente fez uma palestra sobre Seaside no TreinaTom. Aconselho todos que não assistiram que baixem a palestra gravada.

Para quem não assistiu:

• Smalltalk : o pai de todas as plataformas/linguagens orientadas a objeto de hoje. Garbage Collector? Virtual Machine? Byte-code? Introspection? Orientação-a-Objetos? Quem acha que foi Java que inventou isso, deveria mudar de faculdade.
• Squeak : é uma implementação moderna do Smalltalk. Pense no Rubinius no mundo Ruby, mas vai mais longe que isso.
• GOODS : Generic Object Oriented Database System. É a camada de banco de dados.
• Seaside : novo framework web feito em Smalltalk, que utiliza fortemente o conceito de componentes e continuações. Inspirado em outros frameworks como o excelente Apple WebObjects (um dos poucos frameworks Java realmente interessantes).
• Avi Bryant : criador do framework e de excelentes produtos como DabbleDB, evangelizador feroz de Smalltalk. Ainda não é o equivalente a um Paul Graham (do Lisp) mas está por lá.

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.