Bruno Pereira

Um amigo meu me pediu umas dicas de estudo para se tornar um desenvolvedor web produtivo e com boa empregabilidade. O ideal para ele é ter como base a plataforma Java, mas sem ficar restrito a Java. Talvez isso possa ser útil para outras pessoas também, então colocarei as dicas a seguir.

Framework web Java

Considerando o critério empregabilidade, é fundamental conhecer razoavelmente Struts 1.x. Eu creio que poucos projetos hoje em dia sejam iniciados usando o Struts 1.x, mas a quantidade de aplicações em produção com esse framework é enorme, e durante um bom tempo essa realidade ainda se manterá.

Depois do Struts 1.x, nenhum outro framework web Java conseguiu adoção semelhante, então é difícil recomendar uma opção mais moderna que garanta alguma coisa. É provável que a melhor opção “moderna” em termos de empregabilidade seja Java Server Faces, mas não me sinto bem em recomendar que ninguém estude JSF. Se alguém quer seguir na linha do JSF, eu recomendaria o JBoss Seam, do qual ouvi boas avaliações, mas nunca usei.

Dos frameworks web Java mais recentes, o meu preferido é o Spring MVC 2.5.x. O importante da versão 2.5 em diante é que os controllers suportam anotações para configuração, em vez dos XMLs monstros que eram a opção anterior. A maioria dos frameworks web está seguindo numa abordagem RESTful de arquitetura, o que me agrada também. O Spring MVC é um dos que está fazendo isso, e com uma abordagem legal.

Além disso, todos os componentes do Spring acabam te “seduzindo” a usar outros componentes dele, pela conveniência e pela qualidade dos mesmos. Então se você usar o Spring MVC, é muito provável que use a injeção de dependências, o controle transacional, talvez o web flow, entre outras coisas.

Frameworks web da “nova geração”

Qualquer desenvolvedor web hoje em dia TEM OBRIGAÇÃO de olhar pelo menos um entre Django, Grails e Ruby on Rails. O ideal mesmo é avaliar os três e ter um deles como opção principal. Eu já conheço legal o Grails e estou evoluindo rápido com o Django. Em algum momento esse ano eu dedicarei um bom tempo avaliando e fazendo algo relevante com Ruby on Rails também.

Pode parecer que leva um tempo enorme para conhecer os 3, mas isso não é verdade. Os 3 são extremamente produtivos e têm muitas características semelhantes. Quando você começa a utilizar um deles já tendo experiência com outro, a curva de aprendizado fica muito rápida.

Um aspecto muito legal do aprendizado desses frameworks da “nova geração” é que você tem contato com outras formas de fazer software (para quem tem um background Java), outras comunidades, e várias idéias interessantes que te farão um programador melhor em qualquer linguagem ou plataforma. Se você ainda não conhece nenhum dos 3, não perca mais tempo e escolha um para começar. E de preferência conheça os outros em seguida também

HTML, CSS, Web Standards

Estamos em 2009. Embora ainda vejamos muitos sites bisonhos que só funcionam com o IE, se você é um desenvolvedor que se preza você precisa conhecer bem HTML, CSS e os web standards. Na verdade, fazer o site funcionar no IE 6 por exemplo é secundário. Você precisa aprender primeiro a gerar HTML e CSS válido de acordo com as normas da W3C, que garantem padrões de qualidade e interoperabilidade entre browsers. Leia de cabo a rabo todos os tutoriais referentes a essas coisas no W3Schools. É muito rápido estudar por lá, e é uma ótima referência depois.

Depois que você conhecer isso, um pouco de prática na escola norueguesa de software fará suas aplicações rodarem no IE 6 também

Javascript

Ainda há pessoas que escrevem javascript na unha, mas acho que elas são cada vez mais raras. Temos hoje uma oferta enorme de bibliotecas javascript para resolver todos os problemas comuns dos desenvolvedores web. Eu era um fiasco em javascript antes de conhecer o jQuery, mas há um bom tempo eu gosto MUITO de javascript, e minha produtividade no client-side melhorou absurdamente.

O jQuery tem uma abordagem que eu acho excepcional. Temos 3 aspectos claramente distintos para tratar em uma página web: Estrutura (HTML), Estilo/Visual (CSS) e Comportamento (Javascript). Se você fizer tudo direitinho e usar o jQuery, essas 3 coisas ficam totalmente desamarradas.

Você não precisará colocar nenhuma declaração de estilo na estrutura (leia-se: sem CSS inline). A definição do comportamento fica totalmente por fora da estrutura. A beleza do jQuery está em aplicar todo o comportamento da página de uma maneira não-intrusiva, e com uma abordagem muito limpa. Ah, e o javascript funcionará em todos os browsers sem você ter que tratar disso explicitamente. Um sonho, não é mesmo?

Há várias outras opções, e não estou defendendo a idéia de que se use apenas uma. Eu uso o jQuery para tudo que posso, e até hoje não precisei de outra biblioteca, mas vá em frente e experimente algumas opções até encontrar o que lhe atender melhor.

Plugins legais do Firefox

Firebug

Além do jQuery, outra descoberta que mudou minha opinião e gosto por client-side foi o Firebug. Ele ajuda MUUUUUITO na criação do HTML/CSS das páginas, pois você consegue inspecionar de forma fácil o conteúdo e o estilo, e aplicar mudanças imediatas sobre o que está vendo. Depois de acertar as coisas pelo Firebug, você simplesmente aplica as mudanças no HTML/CSS originais e continua implementando sua página. Além disso, ele te permite debugar javascript e analisar as requisições HTTP detalhadamente. Eu já o utilizo há pouco mais de 1 ano, e ele contribuiu muito para meu amadurecimento no client-side, e me dá muito mais produtividade.

Web Developer

Um companheiro freqüente do Firebug é o Web Developer. Ele te permite inspecionar detalhadamente uma porção de coisas na sua página, como informações de todas as imagens, todos os formulários, estilos, entre outras coisas. Além disso, permite a manipulação de cookies, valida HTML/CSS/Javascript, e tem muitas outras funcionalidades úteis. É indispensável para trabalhar com web, assim como o Firebug.

Screengrab

É muito comum termos que mostrar uma página para outras pessoas, e nem sempre elas têm acesso à nossa máquina. Para facilitar isso, podemos usar o Screengrab, que é semelhante a um Print Screen, mas salva o conteúdo completo da página como uma imagem. Isso é bem melhor do que o Print Screen, pois pega apenas a área útil da página (sem pegar barras do Firefox e barra de tarefas) e pega toda a área útil. As regiões da página que precisam ser “roladas” para visualização também são incluídas na imagem, o que é certamente o desejado.

NoScript

O NoScript é um plugin bem incômodo para uso em geral. Ele bloqueia a maioria dos javascripts e você precisa ficar liberando a execução de scripts toda hora. Quando não estou desenvolvendo eu sempre deixo ele desligado.

Entretanto, para desenvolver ele ajuda em algumas situações. Por exemplo, você pode precisar desabilitar alguns scripts específicos da sua página para testar alguma coisa, ou testar se a página funciona sem scripts. Ou então você pode ter uma situação como uma recente minha.

Eu tive que customizar um plugin do jQuery que faz algumas animações, e aí o HTML da página ficava mudando o tempo todo. Eu precisava customizar o HTML/CSS de vários “instantes” da animação, mas era impossível fazer isso com a animação rodando. Para resolver isso, eu usei o NoScript para interromper os scripts exatamente no trecho da animação que eu precisava mudar o HTML/CSS. Com isso, eu conseguia um HTML estático que eu podia mexer pelo Firebug, e consegui trabalhar tranqüilamente nas customizações que eu precisava fazer.

Conclusão

Deixei algumas opiniões e dicas sobre algumas coisas de desenvolvimento web, mas é óbvio que eu também tenho muita coisa a aprender. Se alguém discordar de alguma opinião minha ou quiser acrescentar sugestões, estejam convidados a participar :)  Além disso, se alguém tiver mais dicas de extensões do Firefox para desenvolvimento web, eu sempre estou interessado.

Ontem fui na palestra do Nico Steppat (da Caelum) sobre JBoss Seam no RioJUG. A palestra foi interessante, mas infelizmente não deu tempo pra ele mostrar tudo, e eu não vi muita coisa além do que eu já sabia.

Entretanto, um ponto destacado por ele me deixou ligado em um recurso interessante. Como ele mencionou, o Seam busca ajudar bastante em aplicações que precisam de estado, como um carrinho de compras. A proposta é de ser uma camada de ligação entre componentes stateful do JSF e EJBs stateful.

JSF não é dos frameworks que eu mais goste, mas realmente essa característica utilizada pelo Seam faz sentido em alguns dos projetos que eu participei. Por exemplo, alguns casos de uso envolvem fluxos com algumas telas, e é necessário guardar os dados ao longo do fluxo de um caso de uso. Entretanto, muitas vezes não é necessário que os dados permaneçam disponíveis para outro caso de uso, então o escopo de sessão é maior do que esta necessidade específica.

Este escopo do qual estamos falando é o escopo de conversação, e eu já sabia que o JSF oferecia algo neste sentido, mas eu não tinha ainda parado pra pensar muito sobre isso. Os dados neste escopo têm o ciclo de vida igual ao de uma conversação, que mapeia bem o fluxo de um caso de uso.

No caso do Seam, ele faz uso deste escopo de conversação para 2 coisas principais. Ele consegue manter os dados vivos por vários requests sem usar o HttpSession, o que é positivo, pois sabemos que é difícil escalar o HttpSession. Além disso, ele resolve o problema de casos em que o usuário usa o back do browser e submete novamente os dados referentes a um fluxo que ele já havia concluído.

No último projeto que eu participei com formulários de mais de uma etapa, consegui resolver esse problema do back do browser com uma solução customizada simples. Quando eu criava as etapas eu criava um hash aleatório e associava a cada uma das etapas que o usuário fosse preencher. Dentro do formulário eu colocava um campo hidden contendo esse hash, e quando o usuário submetesse o formulário conseguiria identificar qual etapa ele estava preenchendo. No final da “conversação” eu limpava esses hashes das etapas que o usuário preencheu, e caso ele tentasse submeter novamente os dados, o hash não estaria mais presente e o submit não seria aceito.

Entretanto, neste projeto eu colocava os dados no HttpSession e destruía o HttpSession no final do fluxo. Nesta situação seria mais interessante usar esse escopo de conversação, pois eu deixaria de pendurar dados no HttpSession e pouparia recursos do servidor.

Felizmente eu verifiquei ontem mesmo que o Spring Web Flow também suporta esse escopo de conversação, e então fica para mim o dever de casa de conhecer o Web Flow e passar a utilizar essa abordagem. O Spring MVC é atualmente o meu framework web Java preferido, e foi ótimo saber que eu não precisaria de JSF para ter uma solução para este problema

No mundo de software nós freqüentemente encontramos ferramentas, frameworks e outros ítens que nos abstraem alguns conceitos, e nos dão uma maneira de trabalhar “mais alto nível”.

Nessas situações, é comum ouvirmos que essa abstração é “transparente para o desenvolvedor”, “transparente para o usuário”, ou “transparente alguma coisa”. Essa terminologia abstrai (usar esse termo aqui foi irresistível ) dois tipos de abstração bem diferentes, então vou falar um pouco sobre os dois tipos de abstração encontrados em software, com algumas opiniões sobre ambos.

O que eu chamo de Abstrações Transparentes são as que te oferecem uma forma de trabalho num nível mais alto, mas te permitem ver (é transparente afinal de contas) o que está por baixo dos panos sem tanto esforço. Um exemplo disso eu diria que é o que acontece no Struts e no Spring MVC.

Frameworks web deste estilo tentam te dar um desenvolvimento mais produtivo, sem que você tenha que se preocupar com tudo que está envolvido no processamento de requisições e respostas HTTP. Entretanto, o fluxo de processamento da requisição e resposta é bem intuitivo do ponto de vista do que está acontecendo na interação do usuário com o servidor. E se você quiser manipular a requisição e a resposta, você conseguirá facilmente, sem “burlar” a proposta do framework.

O que eu chamo de Abstrações Opacas são as que também te oferecem uma forma de trabalho num nível mais alto, mas te escondem bem mais o que está acontecendo por baixo dos panos. O objetivo é de fato que você não precise saber dos detalhes, e não queira se meter com eles. Um exemplo disso é o que acontece no JSF e no Wicket, e também no Aqualogic Service Bus.

O JSF e o Wicket oferecem um paradigma de desenvolvimento web diferente do tradicional modelo “Request/Response”. Eles têm um modelo componentizado, no qual a requisição e a resposta HTTP ficam bem encapsulados, e as suas interações com o usuário devem ser totalmente focadas nos componentes. A idéia é que você realmente não veja o que está rolando por baixo dos panos, e não se envolva mesmo com os detalhes.

Eu pensei um pouco sobre isso hoje mais cedo, mexendo com o Aqualogic Service Bus. Troquei umas idéias sobre o que ele faz quando ocorre mais de uma chamada a mais de um web service dentro da mesma transação, e na hora eu pensei: “Ainda bem que essa abstração é opaca!” :)  A ferramenta é sensacional e cuida de muitos detalhes cabeludos do trabalho com WS-* sem que você precise fazer na mão.

Sobre os dois tipos de abstração, a decisão de qual é mais adequado varia muito com a situação e com gostos pessoais. Em relação a frameworks web, eu tenho me dado muito melhor com Abstrações Transparentes, pois eu quero ver os detalhes e quero ter controle sobre eles.

Em situações em que não queremos controlar os detalhes do que está sendo feito, as Abstrações Opacas são muito boas, pois nos poupam esforços. É interessante saber em cada situação qual tipo de abstração você quer, porque a sua escolha de tecnologias e ferramentas será traçada com isso em mente.

Então na próxima ver que alguém disser que alguma coisa é “transparente”, veja logo se é Transparente ou Opaca

Eis que num fim de semana chuvoso, com minha noiva viajando, fico eu várias horas em casa estudando para a prova de Arquiteto Java.

Tudo bem, a culpa é minha mesmo. No final do ano passado eu resolvi aproveitar uma das promoções de vouchers com retake da Sun, e comprei não 1, mas 2 vouchers de uma vez. Naquela época eu achava que iria gostar de estudar para as provas de EJB 3 e Web Services.

Bom, ao longo desse ano eu estudei bastante mesmo. E coisas muito legais. Mas em nenhum momento me senti tentado a fazer nenhuma dessas provas, e fui enrolando, enrolando, e meus vouchers vencem dia 30/11. Em setembro eu já sabia que não tinha nenhuma hipótese de eu fazer 2 certificações, então resolvi estudar para a de arquiteto, e usar 1 dos vouchers para a prova teórica, e o outro para a parte prática. E é pra isso que estou estudando, mas como é chato!!!

Para esta prova eu não sabia muito bem que material seguir, então estou lendo o único livro que me pareceu razoável:

Na verdade eu não estou gostando do livro, mas estou lendo alguns tópicos por ele. Os 4 primeiros capítulos falam de aspectos gerais de arquitetura, análise e projeto OO e aplicabilidade da arquitetura Java EE. Eu passei rapidamente por eles, e acho que deve ter sido tão divertido como escutar a “Voz do Brasil”. Teoricamente os assuntos poderiam ser interessantes, mas a exposição é feita de forma tão enfadonha e repetitiva que acho que não consegui obter nada de útil desse conteúdo.

Basicamente eu lia uma porção de coisas que eu já sei, algumas coisas que eu discordo, e alguns devaneios da Sun. É, por exemplo aquele papo insano de que designers podem escrever JSPs… hahahaha! Se eu tentasse ensinar JSP pro designer do meu time ele ia fazer dezenas de caricaturas e montagens minhas no Photoshop, pra eu aprender o que é trabalho de designer

Bom, nesse momento eu estou acabando a parte dedicada a estudar padrões de projeto. Certamente posso dizer que está sendo a melhor parte do estudo, mas me fez refletir um pouco também. Nessa prova são abordados todos os padrões do GoF e todos os Core J2EE Patterns. São 24 padrões do GoF e 22 do Core J2EE Patterns. Uma boa parte eu já conhecia e estou revendo, e outros eu nem conhecia.

Sempre é bom dedicar um tempo para estudar padrões de projeto, mas deveria ser possível filtrar apenas o que interessa. Eu não gosto de Singletons, não gosto de DTOs e não gosto de usar EJBs, então eu já poderia limar facilmente uns 10 padrões dessa lista. Eu gosto bem mais dos patterns do “Patterns of Enterprise Application Architecture (PEAA)”, mas esses infelizmente não estão na prova…

E outra coisa, é fundamental não ficar bitolado nesses patterns. Se você tiver uma overdose de patterns, sua criatividade ficará prejudicada e talvez você siga por um caminho não muito legal só porque existe um pattern para aquilo. Padrões de projeto são interessantes pela possibilidade de te trazer idéias novas para problemas comuns. Mas o importante é que você adquira o know-how e as ferramentas de raciocínio, e pense por si mesmo. Eu já peguei projetos em que parecia que os desenvolvedores estavam procurando problemas para aplicar os patterns, em vez de usar os patterns como idéias para resolver bem um problema que havia surgido. Mais importante do que qualquer padrão de projeto é raciocinar, pensar bem no problema. Rabisque qualquer abobrinha num papel e resolva bem o seu problema com bom software. Ser uma enciclopédia de patterns não faz de ninguém um programador ou arquiteto melhor.

Bom, para finalizar meus rabujos sobre esta prova, devo dizer que estou decepcionado com o que estou absorvendo em minha preparação para ela. Quando eu me preparei para as provas de SCJP e SCWCD, eu nitidamente evoluí como desenvolvedor neste processo. Foi muito válido fazer essas 2 provas e o tempo que dediquei estudando para elas me tornou um desenvolvedor mais eficiente.

Agora, esta prova de SCEA não está me agregando nada até o momento. Eu poderia estar estudando outras coisas mais interessantes e eu não vou ser um arquiteto melhor por ter este título. Talvez a parte prática dessa certificação seja mais legal, mas até agora ela está servindo apenas para eu não desperdiçar meus 2 vouchers que estão expirando.

Será que na prova prática eu posso usar os patterns do PEAA e montar uma arquitetura sem EJBs, sem SOAP, sem JSF e sem DTOs?? Ou será que isso vai ser censurado? Bom, acho que vou pagar pra ver, pelo menos vai ser bem mais divertido!

Toda semana eu e o Silvano discutimos vários aspectos das nossas aplicações. Como melhorar algumas delas, novos componentes que podem trazer ganhos interessantes, mudanças de arquitetura, etc. Os principais objetivos são: trazer mais qualidade para os projetos e produtividade para a equipe.

Alguns meses atrás estávamos falando com freqüência sobre frameworks web. A maioria das aplicações na Globo ainda usa Struts 1.x. O Struts 1 foi por muitos anos o framework web padrão Java. Ele trouxe muitos ganhos interessantes, comparando com o desenvolvimento usando apenas Servlets + JSP.

Um ponto “fraco” do Struts 1 é que ele não tem nenhum suporte a componentes visuais. Toda a parte visual das aplicações fica por conta dos desenvolvedores, assim como os recursos “Web 2.0″. O problema é que desenvolver esta parte visual de forma customizada em todos os projetos é muito trabalhosa, não é produtiva. Com isso surgiram inúmeros frameworks mais modernos, com suporte visual muito mais rico, trazendo boa produtividade neste aspecto.

O fato é que com esta enorme gama de opções, não temos mais um framework que se destaque de forma absoluta sobre os outros. Temos várias opções para cada projeto. Entretanto, não dá para querer abraçar o mundo, então é comum que busquemos 1 ou 2 opções que nos atendam em quase todos os casos.

Na nossa equipe nós já temos uma aplicação com JSF, que na verdade foi concebida ano passado, antes da minha mudança de equipe. Eu estou usando o Wicket em um projeto pessoal e ainda estou aprendendo o framework, ainda não o domino a ponto de usá-lo de forma produtiva. Com alguma freqüência nós discutimos sobre estes 2 frameworks, e eu ainda tenho a opinião que descrevi anteriormente.

Neste escopo das discussões sobre JSF vs Wicket, também falamos algumas vezes sobre Rails e Grails. Algumas semanas atrás eu e o Silvano começamos a estudar Grails, e fizemos pequenas aplicações de exemplo. Eu já li inteiro este livro de Grails disponível no InfoQ. Ele estava aqui na minha lista de “Livros que quero ler quando tiver tempo”, mas já o movi para a lista de livros que li

Eu estou gostando bastante do Grails, pois ele é extremamente produtivo para aplicações nas quais eu acho que ele faz sentido. Você consegue em 2 dias desenvolver aplicações que provavelmente você demoraria 1 semana ou mais com frameworks Java tradicionais. Eu ainda não o utilizei o suficiente para saber os limites de uso do mesmo. Provavelmente para projetos com requisitos mais críticos de carga e customização das interfaces, ele já não será uma opção tão boa assim. Entretanto, em aplicações internas, com carga limitada e sem grandes necessidades de customização visual, ele é perfeito.

O próximo passo para mim é tentar utilizá-lo em casos mais complexos. Estou pensando seriamente em utilizá-lo no @dvogado.com, um software para advogados que eu desenvolvo no meu tempo vago, mas que está congelado há alguns meses por falta de tempo. Quando eu conseguir um pouco mais de tempo vou tentar implementá-lo com o Grails, e acho que consigo fazer isso bem rapidamente. O Grails atenderia bem à minha proposta de distribuir um pacote completo com tudo que o usuário precisa, tornando o deployment o mais simples possível. Com o Grails eu utilizaria o Jetty + HSQL que ele traz por padrão, e precisaria adicionar apenas o JDK no pacote.

Uma discussão muito interessante também é a de Grails vs Ruby on Rails, mas isso fica para um outro post em breve

Just beginning 2008, I went to a new area, new team at Globo.com. There are several promising projects for this year, and this team switch will make it easier for me to properly evaluate and judge what I consider the 2 leading Java web frameworks nowadays.Like I said here, on my spare time I (try to) develop a lawyer application which uses Apache Wicket as its web framework. One of the projects I’m now working at Globo.com uses Java Server Faces. This should be a great opportunity to finally go deeply on both frameworks and see in which cases each one is better than the other. Based on what i have already studied and used of both, i do have some opinions that may or may not change several months from now.

First, a little background. When i was studying to pass the SCWCD exam, I saw enough of tag libraries to get really sick of them JSTL, Struts 1.x Taglib, Expression Language, etc etc etc. Every new taglib was a new syntax to learn, and the result of using taglibs to implement complex web pages is the famous tag soup. Not being a purist, although I don’t like scriptlets in general, I do think that in some cases they produce much cleaner code than the heavy use of taglibs.

Having said that, let’s start talking about JSF. Being a standard technology backed by Sun, and present on Java EE 5 specifications, you know that you’re gonna find plenty of support by development tools, many examples on the web and an already mature community of users to help you. JSF offers a huge set of components ready to use, and many of them are very pretty and easy to use. In my case, we’re using JBoss Tools + Rich Faces, and the Eclipse plugins avaiable here are just awesome.

Most of the web applications I have worked until now used Struts 1.x, and although Struts is by far the most successful Java web framework til now, developing with JSF is reasonably easier and more pleasant. However, even considering the clear evolution of JSF over Struts 1.x, I still qualify both within the same paradigm. That is, both have a massive dose of non-markup code in their views, and if you’re gonna work with them, you better have your spoon ready to dig into the tag soup Ok, ok, JSF offers very nice components and manages a lot of the work that was left to the developer in the old times, such as managing the application state and offering a beautiful presentation layer without requiring the direct manipulation of javascript. But you’re still going to have your view layer full of taglibs, coding in a special syntax (the custom tags syntax) that will make it tough to track for problems when they happen within the tag soup. You better have a magical spoon to manipulate it

Rather new in the Java web frameworks field is the very innovative Apache Wicket project. Wicket allows Java programmers to focus on what they do best: write Java code. No taglibs, how refreshing! Wicket also uses componentized development, and it isolates the view from your model in the best manner I have seen til now in Java frameworks. It does not seem so intuitive in the beginning, because you code for a web application in a similar way as you would code a Swing application. Specifically the component’s event handling code in Wicket reminds me a lot of the approach used in Swing applications.

Being a new framework that went out of the Apache incubation just several months ago, you can’t expect great tooling support at this point. Drag and drop tools to design screens? Forget about it! Component options similar to JSF ones? You’re not gonna find it either. However, Wicket has a very active community and it’s evolving fast. The second book on Wicket will be avaiable in a few months and the number of users and successful implementations is growing steadily. The set of avaiable components is growing and it’s becoming much easier to find support in their forums.

As I said, I’m far from an expert in both frameworks, and I hope this year I’ll have a long enough exposure to them and probably in a few months I’ll have more valuable opinions. Something I think about is that perhaps knowing Wicket and JSF well can be really useful, because it doesn’t seem like we have a “one size fits all” choice here. Wicket seems great for a company to base its developments and have good and maintainable code that will be easy to build over for several years. JSF certainly can offer that too, but i find it tough to consider taglib code as easy to maintain. However, JSF offers such great components that even a Java developer like me with no talent to create good looking pages is able to generate a very decent user interface.

I’ll confess I have a natural preference for Wicket since the beginning, but I promise I’ll try to evaluate these 2 options without any passion during this year and later this year I’ll post again telling my conclusions (if any)