Para evitar que o caos venha a este mundo, surge outra palavrinha: Hijax. Mas primeiro vamos voltar a algumas premissas do desenvolvimento web: aprimoramento progressivo (progressive enhancement) e degradação elegante (graceful degradation), e me desculpem se errei a tradução dos termos…

Aprimoramento Progressivo – Primeiro o Conteúdo

Ninguém começa (ou pelo menos não deveria começar) a desenvolver uma aplicação primeiro pela camada de comportamento, isso vai completamente contra a filosofia de desenvolvimento em camadas (primeiro o conteúdo, depois a apresentação e, por último, o comportamento).

A idéia é começar o desenvolvimento de baixo. Em outras palavras, desenvolva da maneira antiga, usando links como sempre se usou desde que a Internet é Internet, devolvendo páginas inteiras como resposta. Depois, somente depois, comece a adicionar funcionalidades que melhorem a experiência do usuário (nada de frescuras que o usuário só vai achar bonito, pra que reinventar o link?).

Degradação Elegante – Útil sem perder a elegância

“Degradação elegante” significa perder alguns recursos sem perder suas funcionalidades. Pode-se perder algumas animações e outros fru-frus, mas perder acesso ao conteúdo é inadmissível. CSS não é tão importante quanto as informações que queremos mostrar. Nunca ouviu a frase “mais ajuda quem não atrapalha”? A idéia é a mesma.

O desenvolvimento progressivo e em camadas é o caminho mais rápido para a degradação elegante. Mesmo utilizando Ajax, o conteúdo ainda deve continuar acessível através de um link comum. É aí onde Hijax entra.

Hijax – Seqüestrando os Links

O próprio termo explica bem o uso da técnica. Hijax, do inglês hijack (“seqüestrar”), quer dizer seqüestrar os links comuns, e transformá-los em links Ajax. Simples assim.

“Simples assim”? Bem, nem tanto, eu confesso. Seus scripts server-side precisam estar preparados para decidir se enviam o “pacote completo” ou a “versão básica” da página, se for uma requisição normal ou uma requisição assíncrona, respectivamente. Uma breve dica: header X-Requested-With. Duas versões do site? Nunca mais, isso morreu junto com o Netscape, há muito tempo.

Vale lembrar que somente o uso de Hijax não faz uma aplicação completamente acessível, usável e rica. Há muito mais a se pensar. Já falei sobre alguns aspectos para uma boa aplicação Ajax, mas tenho absoluta certeza que não passei nem perto de tudo que é necessário. Mas tudo isso já é uma boa base a ser levada em consideração, e com isso já é possível criar algo melhor que muita coisa que existe por aí, tenha certeza. E você, tem feito seu dever de casa e seguido princípios para tornar sua aplicação disponível a todos?

Posts Relacionados

• Ajax vs. Acessibilidade
• Ajax vs. Moda vs. Performance
• A Aplicação Ajax Perfeita
• Fila de Requisições em Ajax
• Ajax com a Mootools

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!

Posts Relacionados

• Hijax: Ajax Acessível
• Ajax vs. Acessibilidade
• Fila de Requisições em Ajax
• Ajax vs. Moda vs. Performance
• Ajax: Requisições HEAD

Vamos à uma discussão rapidinha. Pense: vale a pena escrever uma montanha de código JavaScript, correndo o risco de ficar completamente inacessível para alguns browsers, quebrar a cabeça, fazer algo bonitinho que demora o dobro pra carregar, sabendo que você podia escrever uma (uma só, nada mais, sem exagero) única linha? É o caso do pessoal que faz todos os links usando Ajax.

E não é só isso. Há muita coisa que poderia ser evitada. Carregar páginas quase inteiras, pequenos textos estáticos (babem…), outras coisinhas irritantes que pulam na tela… Quer que eu prove que não melhora a performance? XML HTTP Performance and Caching. Creio que posso te convencer.

Descartando a acessibilidade por enquanto. Um site que use Ajax, pra ser mais útil e mais rápido, precisa de muito planejamento. Um ótimo exemplo de planejamento é o Gmail e Google Reader. Inclua a acessibilidade: ainda temos o Google na frente (Gmail sem Ajax também existe). Uma boa discussão sobre isso também rolou lá no Ajax Online.

Apesar de tudo, ainda acredito que já evoluímos muito, e estamos evoluindo. O Ajax no Brasil já amadureceu bastante (até o Ajax Online abandonou a versão 100% Ajax, evolução). Ainda temos muito a progredir, e vai demorar, eu sei, mas não podemos parar. Graças a muita gente já temos trabalhos bons. Agora queremos trabalhos ótimos, basta amadurecer a idéia.

Esta é a minha opinião, não tomem como certa. Apenas pense sobre isso, concorde ou não. Até!

Também já havia falado sobre essas algumas questões relacionadas a Ajax em Ajax vs. Acessibilidade. Também falei sobre A Aplicação Ajax Perfeita, que pode colocar algumas minhocas em sua cabeça…

Posts Relacionados

• Hijax: Ajax Acessível
• Ajax vs. Acessibilidade
• A Aplicação Ajax Perfeita
• Fila de Requisições em Ajax
• Ajax: Requisições HEAD

Por incrível que possa parecer, a grande parte dos desenvolvedores torna suas aplicações utilizando Ajax completamente (ou quase completamente) inacessíveis, principalmente para os motores de busca.

Como os motores de busca não lêem JavaScript, como eles encontrarão o conteúdo de seu site, se ele for feito completamente em Ajax? E os seus usuários, como irão “favoritar” algum artigo que gostaram, se não há links?

Como já disseram, e eu repito, use ajax com moderação. Mas se você ainda deseja utiliza-lo ao extremo, seja por modismo, necessidade ou mesmo para se mostrar para os amigos, vamos tornar isso tudo acessível.

Antes de Tudo…

Como o Micox já disse em seu artigo, você deve planejar todo seu site como se Ajax não existisse. E eu estendo um pouco: planeje seu site como se nem o JavaScript existisse. Mais acessibilidade ainda? Planeje seu site como se CSS não existisse. Não, não estou louco. É possível, bem difícil, mas é possível. Essa é a grande sacada do desenvolvimento em camadas: primeiro o conteúdo, depois a apresentação e por último o comportamento.

Tá certo que hoje em dia são poucos os navegadores que não suportam CSS, mas nunca se sabe. Já o JavaScript é bem complicado mesmo.

Links

Primeiro de tudo: Ajax não veio para reinventar o link. O link é a alma da web. Mas podemos incrementa-lo, lógico. Utilizando o conceito de que você deve pensar em sua página como se JavaScript não existisse, o href não pode ser deixado de lado. Trocar o href de uma página por “javascript:” é suicídio. E pior ainda: trocar por “#alguma-coisa”. Se o usuário não tiver o JavaScript ativo, adeus pra seu site.

Então, como fazemos? Deixe o href como o link verdadeiro para suas páginas, sem ajax, sem javascript. E aí, no onclick, use:

ajax.request(...); return false;

Com o tempo a gente acaba descobrindo coisas interessantes: onclick não é a melhor maneira para capturar links. Leia: Hijax: Ajax Acessível

Isso fará com que, depois de clicado, o link apenas ative o JavaScript desejado, retornando false, para que não aconteça mais nada.

E quanto ao nosso querido hash? Sim, há lugar para ele também. Depois de toda a ação do JavaScript, antes de terminar sua função, inclua: top.location.hash = .... Simples, rápido e indolor.

Costume dos Usuários

Convenhamos: a tecnologia chega, mas nem todos estão preparados para ela. A maioria dos usuários está acostumado a esperar o “loading” do browser, e não dentro da página. Isso é um problema. Se você esquecer do seu “Carregando…”, o usuário pensará que a página travou, parou de funcionar, deu tilt, já era, babaus, enfim. Uma imagem que se mexe ajuda a dar a impressão que algo vai acontecer.

Outro costume dos usuários é o famoso botão voltar. Já postei aqui no blog uma solução para histórico. Não esqueça dela, torne-a melhor, se for o caso.

Várias requisições ao mesmo tempo

Nem todos sabem, mas os que já sabem se irritam bastate. Quando se clica em um link e, instantaneamente, se muda de idéia e clica em outro, a página vai para o último link clicado. Em ajax isso costuma não acontecer. Só a primeira requisição é carregada (nem sempre, claro). Já tive essa desagradável experiência. Coloque uma “fila de espera” para as requisições, para ocorrerem em ordem, ou para requisitar apenas o último clique. Cada uma das soluções se aplica a um caso em particular, não é uma receita específica para todos os tipos de bolo.

Bem, existem vários outros problemas relacionados a acessibilidade, mas já solucionamos os mais “críticos” (outras idéias podem ser encontradas aqui). Vai do bom senso de cada um tornar seu site compatível e acessível. Contribua para o verdadeiro espírito da Web 2.0!

Posts Relacionados

• Hijax: Ajax Acessível
• Ajax sem o X
• Ajax vs. Moda vs. Performance
• A Aplicação Ajax Perfeita
• Fila de Requisições em Ajax