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

Também não estou chamando ninguém aqui de estúpido, não me entendam mal. Estava programando exaustivamente há horas, e resolvi dar uma passeada pela Internet. Lá pelas tantas, cheguei a um blog através das tags do WordPress, e encontrei esse acrônimo. O significado lá era o mesmo que dei aqui, mas vou dar umas dicas para KISS.

Comente seu Código

Por mais simples que seja seu código, comente-o. Acredite, na maioria das vezes vale a pena.

Há muito tempo você escreveu uma função, digamos, para ler XML e mostra-lo na tela (você anda bem experiente mesmo, neh?). Ou qualquer outra função. Aí você deixa ela paradinha lá na sua pasta de códigos por um bom tempo. Por acaso do destino, você volta a precisar daquela função, que não tem nenhum único comentário. E você também não lembra que tipo de técnica utilizou, e acabou adquirindo mais conhecimento para fazer diferente, e esqueceu de erros que cometia.

Isso seria um desastre. Você perderia vários minutos (ou horas, dependendo do tamanho e complexidade do código) tentando entender o código, para depois começar a trabalhar nele (ou com ele).

A coisa piora quando não é você que mexerá nesse código, o pesadelo duplica, triplica, quatriplica de tamanho. Imagine só.

Comentar um código não o simplifica, mas ajuda no processo. Sabe quando você vai comentar uma parte um tanto confusa? Resumindo: comentários, além de ajudar na compreensão de um código, são detectores de tolices, complexidade extra, excesso de código ou de pura e simples falta de simplicidade.

É claro que em funções simples isso não é necessário. É totalmente contraproducente.

Elimine Linhas de Código

Como tudo na Internet, e em qualquer computador, um caractere ocupa seu espaço. Uma linha também. Uma linha com caracteres então…

Linhas em branco e tabulações são importantes, mas há lugares em que são desnecessários. Não pule muitas linhas entre um bloco de código e outro, duas ou três é o suficiente.

Mas não é exatamente sobre essas linhas que falo. Vamos tomar como exemplo o nosso querido JavaScript. Podemos resumir blocos de código, como IF ELSE:

// "Errado"
if( condition ) { umaUnicaLinha(); }
else { outraLinha(); }
// Certo
if( condition ) umaUnicaLinha();
else outraLinha();
// Mais Certo Ainda - Expressão ternária
condition ? umaUnicaLinha() : outraLinha();

Entendeu? Viu quantos caracteres economizamos? Esses blocos podem ser resumidos se tiverem apenas uma linha, dispensado as chaves. E condições ternárias podem ser mais resumidas ainda.

Outra maneira de economizar código é diminuir tarefas repetitivas. Se você já fez um curso mais avançado de MS Word ou Excel, sabe disso (macros). Por exemplo, várias condições devem ser testadas várias vezes da mesma maneira. Em vez de colocar o teste por inteiro, criamos funções! Lógico, não? Isso deve vir desde o planejamento do script.

Em suma, aproveite todos os recursos da linguagem em que você programa para torna-la mais rápida, compacta e simples. Estude bem o que você programa.

Use Indentações

Com o código que economizamos ali acima, podemos usa-lo para tornar o código mais legível.

As indentações servem para identificar em que nível alguma instrução se encontra. Não precisam ser indentações muito grandes, dois espaços são o suficiente. Um só dificulta a compreensão de muitos níveis, e tabulações (tecla TAB), em caso de muitos níveis, tornam difícil de ler, pois tiram o código mais indentado do campo de visão do editor.

Indentar é extremamente simples, mas se torna chato às vezes. Por isso, um bom editor ajuda, mantendo as indentações no lugar depois de um Enter.

Se você já viu o código padrão do Invision PB, deve saber do que falo. Aquilo é incompreensível. Tudo fica na mesma linha, no mesmo nível. Faça o possível para tornar seu código, acima de tudo, legível para você, depois para os outros, e depois para as máquinas. Acredite, facilita bastante.

Nomeie Corretamente

Essa parte foge um pouco do tema principal, mas já que estou dando umas dicas…

Procure dar nomes intuitivos às suas funções, atributos, blocos de código, enfim… O Diego Eis, do Tableless, escreveu um artigo muito interessante sobre nomear classes corretamente. Esse artigo pode também ser aplicado a qualquer coisa, que já citei a pouco.

Dê nomes intuitivos para tudo que criar. Esses nomes devem ter algo a ver com o que você criou, e não onde está posicionada ou o que faz apenas, e somente apenas no que resulta em uma única condição (por exemplo: uma função Ajax complexa que retorna XML e texto, ser chamada de AjaxText, isso é errado).

Poderiam ser citados vários outros pontos, mas eles fugiriam um pouco mais do que quero aqui. Em resumo, o que vale é a simplicidade, legibilidade e total e completa compreensão por humanos, pessoas, gente, nós, enfim…

Posts Relacionados

• Pense Mais e Codifique Menos
• Controle de Erros em JS
• Hijax: Ajax Acessível
• Pra quem você escreve?
• PC formatado, e agora?