Existem recursos que viabilizam o desempenho em aplicações Web de forma aceitável para o usuário final. Entre elas, na minha opinião, o mais adequado é o Ajax. Existem outras alternativas como o Flex, porém, dependendo da aplicação desenvolvido pode haver demora no carregamento e processamento das requisições, mesmo sendo carregada uma única vez. Com base nisso, a utilização do Flex sobre uma intranet é uma excelente opção. Como o contexto é a internet, soluções Ajax levam vantagem pelo fato do conteúdo ser apresentado em HTML/XHTML e pelo fato de não utilizar nenhum plugin para os navegadores. Porém, quando se trata de JavaScript, muitos desenvolvedores tentam evitar por ser mais uma linguagem necessária para o aprendizado para desenvolver uma aplicação. Ironicamente, um desenvolvedor web necessita saber no mínimo três linguagens para desenvolver uma aplicação utilizável.

Em alguns casos, a utilização do javascript em alguns projetos torna-se complicada devido a dificuldade, principalmente quando projetos são feitos utilizado AJAX. Isso encorajou a criação de inúmeros frameworks e componentes que tentam tornar o desenvolvimento de aplicações que utilizam AJAX mais simples e fáceis de manter.

JQuery é um framework que tenta facilitar ao máximo a utilização de JavaScript nas páginas, sendo que, é a ferramenta mais utilizada quando se trata de recursos para a linguagem. O que chama mais atenção são os efeitos e a facilidade para desenvolver com essa ferramenta.

A comunidade Java é privilegiada com inúmeros frameworks e APIs que facilitam o desenvolvimento resolvendo problemas de vários segmentos, principalmente WEB. Acredito que, devido a dificuldade de desenvolver aplicações WEB apenas com JSP, Servlets, Filters, TagLibs, etc., os desenvolvedores tentaram diminuir essa dificuldade com frameworks, tai então a explicação da grande quantidade de frameworks WEB para Java.

Em Java, atualmente, o frameworks WEB mais utilizado, depois do Struts (legado) , é o JSF. Talvez devido ao fato de ser um produto da Sun e estar coberto por uma especificação. Não cheguei a ver detalhes da especificação 2.0, mas nas versões anteriores o desenvolvimento ainda é maçante e chato, onde existem situações que necessitam cada vez da habilidade do desenvolvedor. Porém, muito foi feito para tentar corrigir os problemas e ao mesmo tempo agregar valor ao framework com as extensões repletas de componentes para ser utilizados nos projetos, uma dessas extensões é o RichFaces. Atualmente encontra-se na versão 3.3 e vem uma série de componentes que podem funcionar sobre uma camada AJAX. A facilidade é tanta que a forma de desenvolver é a quase a mesma que desenvolver com JSF puro. Com isso, está a disposição do desenvolvedor recursos de Drag’nDrop, calendários bem elaborados, efeitos, e uma série de componentes bem desenvolvidos que funcionam sobre AJAX.  A configuração do RichFaces também é simples, basta adicionar alguns filtros, escolher o template, ou desenvolver um, configurar um ou dois XMLs e adicionar algumas taglibs no projeto e pronto, seu projeto já está configurado.

O objetivo desse artigo não é de escrever um tutorial e nem comparar as ferramentas, é de alertar sobre a má utilização dos recursos AJAX na aplicação com o RichFaces. O framework utiliza JQuery para fazer os efeitos e manipular do DOM HTML/XHTML, com isso, o conteúdo do framework vai junto com o projeto. A infra-instrutora de um projeto AJAX é repleta de JavaScript e quando projetos se tornam  complexos, conseqüentemente, a complexidades de manter os script se eleva. Com isso, existe uma estrutura de arquivos javascript pronta para suportar a arvore JSF gerada a cada requisição tornando a estrutura pesada ao ponto de ser desvantagem desenvolver a aplicação baseada em requests sobre toda a página.

Destrinchando o conteúdo carregado pelo browser, existe um tipo de arquivo que representa a chamada de sua URL que é respondida a cada requisição, é configurada no web.xml na definição da chamada para a execução do servlet. Nesses arquivos contem o emaranhado do Javascript que o servidor envia a cada requisição. No meu caso, esses arquivos ficaram em torno de 933Kb, é um tamanho considerável quando se trata de requisições. Isso pode deixar sua aplicação uma carroça quando sua aplicação for pro ar.

Nessa situação, a solução para esse problema é aplicar ao máximo os recursos AJAX na aplicação, fazendo com que apenas um trecho da página possa ser renderizada e não todo a cada requisição. Isso diminui bastante o tráfego na rede tornando a aplicação um pouco mais leve. Nas primeiras solicitações a aplicação fica muito lenta, mas quando o conteúdo está no cache o desempenho fica razoável.

Para comprovar, fiz um teste desenvolvendo uma página simples com um CSS pequeno e sem nenhum arquivo JavaScript amais. Fiz as configurações dos pacotes JSF e do RichFaces descritas em seus devidos manuais respectivamente. Fiz com que a primeira página utilizasse um apenas um <a4j:region > contendo alguns componentes, como; <a4j:form> e  um <a4j:commandLink>. Isso é suficiente para habilitar o suporte AJAX do framework, ou seja, carregando todos os JavaScript responsáveis por essa funcionalidade.

Na documentação do framework não existem tópicos que auxiliem a diminuir o tamanho do conteúdo, isso encoraja a utilização massiva dos recursos em todas as páginas e evitando request desnecessários. Não quero dizer que o framework seja ruim, pelo contrário, é uma ótima ferramenta, porém, deve ser utilizada com cuidado. A utilização de AJAX puro é uma excelente opção.

[]s.

Dediquei meus estudos para conhecer linguagens de programação, frameworks, processos, padrões, boas práticas, ferramentas, etc, mas nunca me dediquei a aprender alguma coisa de design.  Digo que design não significa manipular imagens, HTML, CSS, Photoshop, etc. o termo significa muito mais que isso, significa ter em mente a melhor forma de apresentar um produto, impacto visual, chamar o cliente, ou melhor, possuir o “conhecimento artístico” de como tocar um cliente através da arte.

Vi que isso era de extrema importância depois tentar fazer uma interface, para uma necessidade específica, que iria utilizar em um projeto. Tinha a idéia mais não tinha capacidade para colocar em prática. Frustrado com minhas tentativas em vão, consultei alguns colegas que são web designs e solicitei uma ajuda no que eu estava fazendo. Depois de alguns minutos expondo minhas idéias ele me surpreendeu afirmando que eu não sabia o que eu estava fazendo, ou seja, tinha o problema, mas formulou sua resolução de forma errada.

Quanto mais ele falava mais ficava desapontado, pois realmente, o que eu tinha em mente não tinha bulufas com a solução do problema. Para tentar mostrar melhor, ele desenhou a interface toda na minha frente mostrando o porque de cada elemento contido na tela, achei isso fantástico, além do mais, ganhei a interface de graça e utilizo até hoje no projeto. Analisando isso, me questionei sobre a vantagem de ter designs em empresas que desenvolvem software, seja web ou não.

No ponto em que fui ajudado, todas as regras de negócio já estavam completamente desenvolvidas e testadas para solucionar o problema. Tratando a interface como um item sem importância, vi que estava completamente errado sobre quase tudo que tinha feito. Ou seja, o problema que aconteceu foi que não me preocupei com a apresentação para o cliente. É obvio que, tendo uma interface sem a regra de negócio o sistema não funciona, porém, se tendo a regra de negócio e não tendo uma interface funcional e também intuitiva o fator psicológico entra em cena. Isso é fácil de exemplificar; É só observar o comportamento de uma pessoa que utiliza uma família sistema operacional quase que

a vida toda e força-la  a utilizar um sistema sem sua interface que estava acostumada. Acreditem, já vi isso acontecer e quem se ferra é o setor de suporte.

Bom, voltando ao assunto, é óbvio que a necessidade de ser ter uma equipe de design é importantíssima. A Apple faz disso o seu principal elemento de desenvolvimento de produtos e venda, eles levam a sério o Design Funcional. A Microsoft incorpora o design no seus produtos voltados para usuários comuns e incorpora o design ao produto de forma intuitiva que ajuda o departamento de vendas a fazer o seu papel de forma agressiva.

Descrevi minha experiência frustrante de tentar fazer um trabalho de design sem o conhecimento adequado para isso. Respeito muito o trabalho desses caras porque, sem eles a web (WWW) não era um elemento tão atrativo como é hoje, e o marketing não seria são eficiente como é hoje.

[]s