Tempos atrás andei pensando sobre uma aplicação Ajax. O que ela deveria ser, como deveria funcionar, tudo o que precisaria ter. Incrementei a idéia, pensando na acessibilidade, usabilidade, unobstrusividade, essas coisas. Cheguei a conclusão que não existem muitas dessas por aí.

Não que essa idéia fosse “a aplicação ajax perfeita”, mas sim a ideal. Demoraria muito a ser feita, mas eu consideraria uma obra de arte.

Padronização

Essa parte é a parte fácil, que todo mundo sempre deveria se dar ao trabalho de fazer: manter seu trabalho dentro dos web standards.

Validar sua marcação, seus CSSs, isso todo mundo faz (ou deveria). Mas às vezes um certo item é deixado de lado: seus XMLs, que não causariam muito problema, a não ser um XML em especial: os feeds. Ou seja, valide tudo que possa ser validado.

Manutenção

Código bom é código comentado. Disso ninguém discorda. Sempre comente seus códigos, tanto para seu uso em futuras manutenções e atualizaçãoes, quanto para seus visitantes que querem descobrir o segredo daquela técnica inovadora que você implementou. JavaScript ninguém esconde, e uma técnica nova deveria poder chegar a todos que quisessem, mesmo que seja investigando seu código. Melhor ainda se ele estiver comentado, mesmo que seja somente em partes mais obscuras.

E o tamanho do código não aumentaria? Sim, mas você só precisará comentar partes essenciais, aquelas mais complicadas que você sabe que irá esquecer com o tempo. Além do mais, se você esquecer de seu código, perderá muito tempo até lembrar o que cada parte faz.

Compatibilidade

Outra parte facílima, mas indispensável. Se tudo for seguido, nem tanto, mas ainda assim se torna muito mais agradável usar uma aplicação que funcione como deveria funcionar.

Com todas as opções de browsers existentes hoje, sempre haverá aquele que terá problemas (geralmente o azulzinho que todo mundo já conhece). Mas existem maneiras de amenizar o problema. Isso não só com Ajax, mas qualquer “defeito” de JavaScript e CSS que possa atrapalhar a experiência do usuário.

Essa parte pode, sem problemas, ser deixada para os frameworks já existentes, que fazem seu trabalho muito bem. A compatibilidade vem sendo muito focada por essas bibliotecas, facilitando, e muito, seu trabalho.

Controle de readyStates

Agora começa a parte divertida. Tudo que está logo acima qualquer um faz. Vamos começar adicionando nossos diferenciais.

Geralmente, costuma-se cuidar de apenas dois readyStates: 1 e 4 (aberto e carregado), que resultam no clássico “Carregando…” e a requisição completa. Não que seja necessário, mas um controle completo de estados poderia ser bom.

O usuário saber que sua requisição está sendo processada ajuda, já que não pensaria que a requisição travou (isso acontece bastante quando a requisição demora demais).

Coloquei os readyStates, o que significam e uma sugestão para o texto de carregamento. Os readyStates 0 e 4 não precisam disso, já que 0 não tem muito uso, e 4 terá sua própria função.

• Não Inicializado (0)
• Aberto (1): “Abrindo Requisição” ou “Iniciando Requisição”
• Enviado (2): “Enviando Dados”
• Recebendo (3): “Carregando” ou “Recebendo Dados”
• Completo (4)

Não que seja necessário, mas também seria válido cuidar dos status da requisição também, pelo menos 200 (OK), 404, 500, e os outros erros mais comuns.

Histórico

Esse é o maior problema das aplicações Ajax. Já faz tempo que as primeiras soluções para histórico apareceram, e outras melhoradas, e ainda há centenas de aplicações que não se dão ao trabalho de implementar qualquer das soluções.

O histórico sempre deve ser implementado, mesmo que sua aplicação não queira dominar o mundo.

Cache

O cache, considerado uma praga por muitos, pode ser de uma grande ajuda para sua aplicação. Sempre que se faz uma requisição estática (que não muda em pouco tempo), deve-se usar o cache, pois quando refizermos essa requisição, ela terminará mais rápido.

Além do mais, usando o histórico, podemos guardar requisições “cacheadas” no próprio JavaScript. Assim, mais rápido ainda.

É claro que, em requisições dinâmicas, não devemos usar essa técnica. Ela pode prejudicar o usuário, pois não há maneira de atualizar a página através do F5.

Filas de Requisição

Todos sabem que se quando uma requisição estiver em andamento, e outra for iniciada, a primeira será cancelada.

Assim como o histórico, já existem milhares de soluções diferentes para fila de requisições. Esse recurso deve também ser usado sempre que possível (ou seja, sempre). Isso pode evitar aborrecimentos ao usuário.

Inobstrusividade

Essa é a questão mais polêmica. Sua aplicação não deve usar JavaScript obstrusivo (ou usar o menos possível), fazendo-a de maneira que funcione corretamente em qualquer browser.

E o Ajax sem JavaScript, como fica? Também tive idéias mirabolantes quanto a isso. Você deve usar o mesmo script server-side tanto para requisições assíncronas (Ajax) quanto para as síncronas (me refiro àquelas via browser). Para isso, usamos aquele header X-Requested-With, que seu server-side deve identificar.

Dessa maneira, não “trancamos” o conteúdo nem ao usuário nem aos buscadores e afins. Benefícios ao usuário e a você (e ao seu bolso, se for o caso).

Lembre-se de tornar o conteúdo Ajax-less atrativo aos olhos do usuário também, usando o mesmo layout do resto da aplicação (ou a mesma estrutura, caso seja XML).

Desempenho

O desempenho é outra característica muito essencial. Em tráfego de dados muito grande, devemos tomar cuidado com o JavaScript. Muito XML gera muitas chamadas ao DOM, e isso leva tempo. Aí o JSON entra em cena.

O Profiler do Firebug pode ser muito útil, já que ele monitora o tempo de execução da sua aplicação e das requisições que ela faz.

Bem, é isso. Quem sabe um dia veremos uma aplicação destas. Estou trabalhando em uma função que faça boa parte disso, espero que consiga terminar. Fui!