Vou explicar um pouco do contexto geral das aplicações, mas dar ênfase (não exclusividade) para o front-end.
Por muitos anos, minhas atividades envolveram predominantemente desenvolvimento de back-end, ou seja, camada de persistência, negócio, etc, e meu ponto fraco era o front-end. Não tinha habilidade (nem paciência) para fazer uma camada de visualização bem elaborada e agradável para o usuário.
Decidi que iria romper essa barreira. Foi então que comecei a explorar mais alguns frameworks baseados em componentes (Component-Based) que implementam a especificação JSF.
- Component-Based é um termo utilizado para descrever frameworks de front-end que oferecem vários componentes prontos para serem combinados na tela, como tradicionalmente se faz para aplicações Desktop, só que para aplicações Web. Em outras palavras, é possível desenvolver uma aplicação web quase como se estivesse desenvolvimento uma aplicação Desktop.
Os dois com que mais me deparei foram Richfaces e Primefaces.
Tudo começou com o desenvolvimento de um projeto que utilizava Java EE 5, com JSF, rodando sobre um Jboss AS 5. Por baixo havia um Hibernate mapeado com HBMs, nenhuma Annotation, e os componentes visuais desenvolvidos com Richfaces. Integrando tudo isso estava a versão 1 do framework Demoiselle, do Governo Federal. Tudo desenvolvido por outra equipe e entregue de pára-quedas para a minha equipe. Para complicar mais ainda, era um sistema extremamente complexo e importante para a empresa (top 5) e, logo, com prazos muito curtos.
Por algum tempo não tive final de semana. As dores de cabeça com erros muito esquisitos nos mapeamentos do Hibernate em um emaranhado de tabelas e algumas limitações do Richfaces nos fizeram recorrer a algo mais definitivo. Algumas reuniões com o cliente e conseguimos convencê-lo de que, para que o sistema pudesse ser concluído e oferecesse uma boa manutenibilidade futura, seria extremamente valioso fazermos um upgrade em toda a arquitetura da aplicação.
Adiantando então a primeira conclusão deste post, a experiência com Richfaces não foi muito gratificante. Alguns fatos foram que a equipe (incluindo eu) era de certa forma inexperiente com este framework e a aplicação já tinha vindo para nós com uma combinação muito complexa de RichFaces com javascript e outras coisas.
A solução mais definitiva que adotamos foi de migrar para o Demoiselle 2, que trabalhava com Java EE 6, desfrutando de CDI (Injeção de Dependência nativa no Java EE 6, antes oferecida somente por frameworks de terceiros, como Spring), JPA (deixando o Hibernate transparente) e, especialmente, JSF 2, tudo rodando sobre um JBoss AS 6.1 (compatível com Java EE 6).
Com as novidades veio o Primefaces 3, implementação do JSF 2 com uma maturidade surpreendentemente maior do que as soluções utilizadas anteriormente.
A experiência da equipe com o Primefaces foi positiva em vários aspectos, dentre os quais:
- Desenvolvimento muito rápido da camada de visualização.
- Uma quantidade imensa de componentes para pronta utilização.
- Suporte excelente e muito simplificado para Ajax.
Enfim, eu, pessoalmente, gostei muito do Primefaces e acredito que neste momento quebrei tal barreira que tinha com front-end. Mas estava recém começando! javascript e CSS ainda eram meio nebulosos pra mim.
Estudei muito a utilização do Primefaces com toda essa arquitetura do sistema que mencionei. Desenvolvi alguns projetos por conta explorando essa gama de recursos e comecei a enfrentar os primeiros obstáculos que me fizeram repensar a primeira impressão. Minha experiência com jQuery era absolutamente nula, portanto, customizar os componentes do Primefaces para criar algum comportamento diferente era muito difícil, para não dizer quase impossível. Driblei alguns requisitos utilizando o que o framework oferecia pronto e ignorei alguns outros, mas fazer exatamente como era a ideia inicial não foi possível em alguns casos.
Há muito tempo vinha ouvindo sobre a ascensão do jQuery para desenvolvimento de aplicações Web em qualquer linguagem (Java, Ruby, PHP, etc.) e sobre as novidades do CSS 3, HTML 5, enfim, as tecnologias dominantes nessa parte de front-end e defendidas como conhecimento obrigatório de desenvolvedores Web. Percebi que tinha mais uma barreira a ser quebrada e comecei a ir atrás.
Alguns blogs e livros, como este, ampliaram minha visão em vários aspectos, especialmente no aspecto de começar a pensar em deixar cada tecnologia com sua devida responsabilidade (e especialidade). Por exemplo, se eu tenho alguma dificuldade com Primefaces e recorro à comunidade, um desenvolvedor PHP ou Ruby não conseguirá me ajudar. Já jQuery domina o pedaço para gerar o dinamismo nas telas e CSS domina a personalização de layout, ambos oferecendo quase infinitas possibilidades por sua versatilidade. E se você desejar migrar seu front-end para outra plataforma de desenvolvimento, aproveitará muita coisa, senão tudo, enquanto que migrar um front-end Primefaces para Rails, por exemplo, seria impossível, aliás, para uma aplicação Java que não utilize JSF já seria impossível.
O momento dessas conclusões coincidiu com minha alocação em outro projeto, onde trabalhar com PHP não foi tão gratificante (perdoem-me os fãs do PHP), mas aprender jQuery, ExtJS e CSS mais a fundo foi o que faltava para romper a segunda barreira, e foi sim muito gratificante. Além de trabalhar eu conseguia me divertir também. :o)
Aí entram os frameworks Action-based, que são baseados em ações (não diga!), ou seja, dentre outras flexibilidades, têm um suporte especial para outra forte tendência no desenvolvimento de software atual: REST, onde métodos HTTP indicam à camada de controle da aplicação qual operação deve ser executada (consulta, inserção, atualização, deleção, etc.).
O REST já se tornou um padrão no desenvolvimento de aplicações Web e Web Services, e aí é onde os frameworks Component-based, na minha opinião, mais perdem espaço. O desenvolvimento, a testabilidade (TDD) e o padrão de separação de responsabilidades fluem muito melhor por respeitar muito mais o padrão MVC, e a eventual necessidade de migração de tecnologia não põe tudo a perder, pelo contrário, aproveita muita coisa.
Algumas vantagens do Action-Based:
- Alta produtividade depois de bem aprendidas as principais tecnologias de front-end.
- Alta testabilidade (sem misturar visão com controle)
- Possibilidades praticamente infinitas de implementação de componentes e efeitos visuais.
- Alívio da sobrecarga de memória no servidor (pecado do JSF).
Concluindo, tive então essa experiência com jQuery, ExtJS (que oferece muitos componentes prontos em javascript e uma comunidade gigante), CSS, dentre outras tecnologias. Foi muito gratificante por saber que todo esse aprendizado tinha um alcance muito maior (não limitado ao Java) e me fez decidir optar por frameworks action-based para os próximos projetos.
Alguns frameworks Action-based:
Alguns frameworks Component-based:
Recomendo algumas bibliografias, não por serem as melhores (não sei se são), mas porque foram as que li e achei excelentes:
- JavaScript: The Good Parts - Passo inicial para entender bem como funciona o javascript e, especialmente, seu tratamento de classes e objetos, essencial para entender melhor jQuery e ExtJS.
- JavaScript & jQuery: The Missing Manual - Muito bom, especialmente sobre jQuery
- JQuery - A Biblioteca do Programador Javascript - Tão bom quanto o anterior
- Ext JS 4 First Look - Livro sobre Ext JS muito completo e didático.
- CSS: The Missing Manual - Livro sobre CSS muito completo e didático também.
Alguns dos vários links que vi de boas discussões e postagens sobre o tema:
Neste post, não detalhei a forma de utilização destas tecnologias, pois quis focar mais na opinião sobre as duas abordagens. Posts mais técnicos e detalhados podem aparecer na sequência.
É isso então!
Até a próxima!
Valeu, seu post me ajudou bastante.
ResponderExcluir