Vou falar aqui sobre os resultados da votação de Web Frameworks. Vendo este whiteboard, levanto algumas questões:
- Porque JSF é lider?
- Porque tem gente que ainda utiliza Struts e Struts 2?
- Quem são os malucos que utilizam Spring MVC?
- Que tipo de desenvolvedores utilizam Tapestry?
- Porque em tão pouco tempo, o uso do Wicket cresceu a ponto de ultrapassar Tapestry, Grails e Rails?
Porque JSF é lider?
Para mim, o principal motivo é simples: JSF é uma especificação definida pelo JCP. Isto favorece a adoção por grandes empresas e projetos que preferem algo padronizado e que possui uma grande oferta de cursos, livros e produtos.
Mas me questiono: o JavaServer Faces puro (Reference Implementation) não tem nada demais. A produtividade com ele é baixa, o suporte das IDEs só é bom quando amarrado a componentes de terceiros e como comentei num post anterior, usa-se muito SOP (String Oriented Programing.) A solução para torná-lo verdadeiramente produtivo é sempre abraçar algum framework JSF mais robusto (leia-se: mais componentes e uma arquitetura engessada), como o JBoss Seam, Oracle ADF Faces ou o da Sun (experimente o NetBeans 6 e notará que vários componentes são específicos da Sun... não sei exatamente de onde vem, qual o projeto, mas sei que tem.)
Abraçar um produto JSF implica em se amarrar a este produto e seus componentes customizados, não podendo mudar de Vendor assim como é prometido pela especificação e tantos desenvolvedores, gerentes e arquitetos ainda, sendo enganados pelo marketing, acreditam.
Sei, e concordo, que há espaço para o JavaServer Faces, mas vamos parar com o euforismo de que JSF é produtivo, padronizado e livre de implementação, ok? Ninguem mais vai trabalhar com JSF RI. A solução será sempre escolher entre uma especialização ou outra (Seam, ADF, etc ...) para tornar essa máxima verdadeira.
Porque tem gente que ainda utiliza Struts e Struts 2?
Desenvolvi em Struts 1.x durante boa parte da minha carreira, e assim como postei da outra vez, acredito que foi-se o seu tempo. Entramos numa era de programação baseada em componentes, e não actions. Reutilização de código na composição de paginas agrupando componentes: este sim é o modelo de hoje (visto no JSF, no Tapestry, Wicket e alguns outros).
Então porque tem gente que ainda utiliza Struts e Struts 2? O primeiro é simples: manutenção. Tem muito sistema que foi feito em Struts e por falta de tempo ($$) não existe o interesse em migrar para outro framework (nem que fosse o Struts 2). O segundo fica difícil de dizer exatamente o porque, mas me arrisco a dizer que é pelo simples fato de ser a junção de duas fortes comunidades (Struts e WebWork) que são devotos do modelo Action-based. Esta comunidade está presa a um modelo de construção Web, onde se sintam confortáveis e confiantes na hora de construir suas telas. Eu entendo. Já me senti assim um dia... :) Mas só por um dia.
Acho que o número de projetos em Struts e Struts 2 diminuirá com o tempo. Minha previsão é que, assim que JSF 2.0 sair oficialmente, teremos uma queda drástica na adoção de Struts 2 como framework web para novos projetos. Deste modo, dois frameworks irmãos irão se encontrar no limbo da manutenção.
Quem são os malucos que utilizam Spring MVC?
Alguém ae utiliza Spring MVC? Por favor, comenta aqui quais os motivos que o levaram a adotá-lo! Porque eu não faço a menor idéia. Na minha opinião, é apenas um Action-based amarrado ao Spring. O que ele tem que outros frameworks neste modelo não oferecem?
Deixo a resposta desta pergunta para os comentários... :)
Que tipo de desenvolvedores utilizam Tapestry?
O tipo que quer correr riscos e gosta de seguir um Pastor. O risco de sair uma versão nova com mudanças tão grandes na API que o forçam a duas únicas opções: ficar largado na versão anterior ou migrar para a última. Se você não sabe, o Tapestry é escrito praticamente, por um único desenvolvedor chamado Howard Lewis Ship. Isso implica que, se o cara decidir (como já fez entre as versões T3, T4 e T5) ter idéias novas e implementá-las, ele o fará sem dó nem piedade da comunidade que utiliza o framework.
Minha sugestão: fique longe de frameworks sem compromisso com seus usuários.
Porque em tão pouco tempo, o uso do Wicket cresceu a ponto de ultrapassar Tapestry, Grails e Rails?
Foi uma surpresa para muitos, quando o framework foi incorporado pela Apache rapidamente. O processo na incubadora foi rápido, o que demonstra a maturidade e o compromisso dos desenvolvedores. Além disso, é notável ver que este compromisso é diário visto o número de dúvidas respondidas (muitas até instantâneas via IRC) pelos commiters e usuários avançados.
Não há como negar que a comunidade Wicket já está consolidada, ao ponto de ultrapassar a do Tapestry e Grails. Mas não basta ter comunidade (voltemos ao exemplo do Struts), é preciso mais que isso. Aos que já colocaram seus dedos em algum exemplo de Wicket, viram o quanto é produtivo e rápido a construção de telas e componentes genéricos. Mas ainda, não é isso que atrai novos adeptos ao framework. É divertido desenvolver com Wicket.
Foi-se o tempo de apanhar para XMLs e Strings escritas por engano. Ou de taglibs monstruosas cheias de parâmetros. O conceito de POJO + POH é o que faz a diferença em relação aos outros frameworks. Some isso a uma API bem moldada a ponto de ser comparada com a do Swing, e você terá uma facilidade incrível para entender os métodos e classes do framework.
Para 2008, o plano é apresentar ainda mais a capacidade do Wicket a vocês que frequentam este blog. Não que eu queira iniciar uma religião com isso, mas apenas mostrar que existem alternativas mais produtivas. :)
[]'s
miojo
