Ao exibir conteúdos em uma página só e carregar apenas as informações necessárias, para garantir eficiência e agilidade, os desenvolvedores Ajax quebram a cabeça com o despreparo dos browsers.
Cinco meses após o primeiro artigo sobre Ajax (“Não é tecnologia, é um jeito”, veja ao lado) muita coisa aconteceu e já há uma maturidade maior para se falar sobre isso. Antes de mais nada:
Ajax veio pra ficar
Quando falamos de web 2.0, falamos em serviços na internet, softwares na internet. Ora, isso é completamente inviável sem Ajax ou algo parecido. Quer dizer, na verdade, existem centenas de tecnologias pra se fazer softwares na web, de “JavaApplets” (que o Box.net usa de forma linda, no qual se pode arrastar e soltar uma pasta do computador para a internet). Existem também plugins. Isso é muito antigo. O Ajax foi a primeira tecnologia a aparecer com uma solução nativa do navegador. Sem precisar instalar nenhum plugin.
Além disso, o passo que nós já demos em direção à web 2.0 não pode ser desfeito. Seja com Ajax ou alguma tecnologia similar, jamais se deve deixar uma página ser recarregada a cada comando que o usuário dá.
Algumas utilidades já consagradas para o Ajax
Algumas coisas que podem ser feitas com Ajax têm o poder de viabilizar vários sites e novos serviços que estão aparecendo por aí. Vamos tentar relacionar algumas destas competências:
Interface numa única página. Sem recarregar a página a cada comando, é possível fazer softwares na internet com performance semelhante à do software local. Isso não era possível antes − embora as tecnologias que compõem o Ajax estejam aí há muito tempo, este jeito de pensar em desenvolvimento web é muito novo.
Arrastar e soltar. Você já imaginou um sistema operacional como o Windows sem o recurso de arrastar e soltar? A internet era mais ou menos assim. Agora, com o Ajax, ficou fácil trabalhar com arquivos (como o Box.net), com blocos de informação configuráveis (como o Netvibes), entre várias outras funcionalidades que só apareceram na internet quando se tornou possível arrastar e soltar.
Páginas mais rápidas. Quem não sabe disso, né? A função principal do Ajax é deixar tudo mais rápido. Sem esperar tudo recarregar, a gente consegue induzir o usuário a fazer coisas que de outra forma ele jamais faria, por preguiça ou falta de tempo. Novamente o mesmo exemplo: eu teria preguiça de clicar em um formulário de contato se souber que vai demorar para carregar. Mas não teria se fosse instantâneo. Qual é a diferença aqui? Um site com Ajax dá mais retorno − teoricamente.
Maior capacidade de personalização. Com Ajax se tornou possível fazer um site e deixar cada usuário remoldá–lo como quiser. Antes já era possível? Sim, era. Mas era terrívelmente difícil. Agora basta clicar em um link “edit” em algum canto, clicar num comando e está pronta a mudança no site. Ou clique em um conteúdo e arraste para outro lugar. Ou clique em um botão de avaliação sem precisar parar de ler a notícia… Enfim, sem espera, sem chateação, deixe o site do jeito que você quiser.
Essa lista poderia continuar, porém o mais importante está aí. Além do mais, trabalhando na minha empresa (Desta.ca) com Ajax tenho tido algumas dores de cabeça e percebo que a maioria dos programadores ao redor do mundo tem os mesmos problemas… Quero falar um pouco sobre isso.
Alguns problemas relacionados ao Ajax
Uma tecnologia tão nova não poderia deixar de ter problemas. Estes problemas acontecem ou pela falta de maturidade da tecnologia e conhecimento dos programadores que estão começando a trabalhar com isso, ou porque a própria internet não está totalmente pronta para essa revolução.
Aí vão algumas preocupações e problemas, classicamente apontados quando se trata de Ajax. Vou chamá–los, carinhosamente de bichos–papões do Ajax.
1. Favoritos. Se a interface do seu site é toda em uma página só, como o usuário vai guardar um determinado artigo nos seus favoritos? Como ele vai enviar este conteúdo para um amigo? A falta de um link permanente (problema também quando se faz um site todo em Flash) é um monstro. Porque um dos corações da web 2.0 são os blogs… Como eu vou falar no meu blog sobre um artigo, video, áudio ou qualquer conteúdo, sem ter um link direto para ele? Cada programador está procurando sua própria solução, mas nós temos que procurar padrões para essas soluções. Assim a tecnologia vai ter maturidade mais rápido.
2. Botão Voltar. O que acontece quando você clica no botão Voltar em um site Ajax? Hoje temos duas opções (fora as gambiarras com programação suja): ou não acontece nada, ou não volta para o lugar que você queria. Acontece que os navegadores não têm um evento para o programador dizer o que acontece na sua página quando o usuário clica Voltar. O máximo que o navegador consegue dizer é que o usuário saiu da página. E aí, recomendamos ao usuário não clicar no botão Voltar e damos o problema por resolvido?
3. Recarregar. Acontece a mesma coisa com o botão Recarregar. O navegador só entende que o usuário saiu da página… mas recarregar uma página e voltar para a anterior são ações muito diferentes. Por que o navegador não tem “eventos” para os botões Voltar e Recarregar? Simplesmente porque antes não era preciso. Agora, com Ajax, é preciso. Novamente, alguns programadores fazem gambiarras (como iframes escondidos, que causam um mooonte de bugs no sistema) para driblar esses problemas. Mas é preciso uma solução padronizada, simples e limpa para isso.
4. Compatibilidade entre navegadores. Pelo tamanho do nome já se vê que esse deve ser um mostro enorme, que sai de baixo da cama quando os programadores apagam a luz em seus quartos. Realmente, é um problemão programar em JavaScript pensando nas frescuras de um browser e de outro. Tableless não resolve o problema, cada browser interpreta CSS de um jeito. O Internet Explorer tem um monte de bugs ao trabalhar com Javascript (por exemplo, às vezes quando se escreve um código, ele simplesmente “esquece” de passar um parâmetro). Os programadores ficam loucos com isso. Isso aumenta o custo do produto final e deixa todo mundo bravo.
5. Segurança. Quando você faz um monte de processos pelo lado do cliente, e não no servidor, se o programador não for bom, pode ser abertas brechas enormes de segurança. A tecnologia ainda não tem padrões muito bem definidos para segurança quando se trata de Ajax. Por enquanto eu não ouvi falar de nenhum problema sério, mas os programadores têm um pouco de medo quanto a isso.
A comunidade continua trabalhando. A internet está mudando. O mundo todo está mudando. Basta ter paciência para ver a maturidade dessa tecnologia chegar e todo mundo ser mais produtivo. Um pouco de boa vontade do pessoal dos navegadores, um pouco de boa vontade dos programadores em compartilhar as soluções e todos poderemos dormir um pouco mais tranqüilos.
Por
Nenhum comentário:
Postar um comentário