Coletânea Front-end: Uma antologia da comunidade front-end brasileira

Capítulo 1:

Uma coletânea com o melhor da comunidade front-end brasileira

A comunidade brasileira de programadores front-end e Web Designers é fantástica. Possui uma força imensa de elevar a qualidade da Web brasileira. Os milhares de representantes dessa comunidade produzem conteúdos ótimos em seus blogs, listas de discussão, Facebook e conversas de boteco. Nós nos encontramos em eventos memoráveis em todo o Brasil. Fazemos a diferença.

Esse livro quer ser uma pequena celebração desse sucesso.

Inspirados em projetos internacionais semelhantes – como o recomendadíssimo Smashing Book – trazemos essa Coletânea de Front-end. Um grupo de 11 autores de renome nacional na comunidade se juntou para escrever artigos que julgamos relevantes para a Web.

E mais importante até que o pequeno grupo de desbravadores desse projeto, queremos abrir o caminho para mais um canal da comunidade front-end. Queremos feedback, queremos que briguem conosco pra que lancemos novas edições, com mais autores e mais temas.

1.1 Os capítulos e os autores

O livro está organizado em capítulos independentes, cada um com seu autor. Conversamos entre nós, mas cada tópico é expressão do próprio criador.

A única regra era: escrever algo memorável, que fizesse a diferença na Web brasileira. Nesse nosso meio que muda rápido, não queríamos falar da moda do mês. Focamos em temas atuais mas duradouros.

Começamos tentando rediscutir o papel da Web redescobrindo o Progressive Enhancement com Luiz Real. É impressionante como uma técnica com anos de idade é cada vez mais atual. E como há muita gente ainda ignorando essa prática essencial.

Na sequência, Diego Eis aborda Responsive, Adaptive e Fault Tolerance com muitas buzzwords e polêmicas. O autor mostra como a Web é genialmente imprevisível, adaptativa e flexível e discute o mindset correto pra lidar com isso.

Entra então Bernard De Luna falando sobre Como criar frameworks CSS. Mais que uma abordagem puramente técnica, é um tratado sobre a necessidade de padrões nos projetos e uma discussão interessante sobre o papel dos frameworks nas equipes Web.

Em seguida temos Giovanni Keppelen, que apresenta uma introdução detalhada ao AngularJS, um dos principais expoentes atuais do grupo de frameworks JavaScript MVC. Ele demonstra códigos práticos dos principais módulos do Angular e os motivos pelos quais você deve considerar essa ferramenta em suas aplicações.

A discussão sobre acessibilidade é bastante profunda com dois nomes de peso. Primeiro, Reinaldo Ferraz discute o coração da acessibilidade vista pelo W3C, mostrando as práticas fundamentais das WCAG que muitas vezes ainda são ignoradas no mercado.

Depois, Deivid Marques expande o tema abordando WAI-ARIA e as novas marcações de acessibilidade pensando em interações ricas na Web. Com exemplos excelentes, ele mostra como os novos atributos podem ser incorporados sem esforço nas suas aplicações.

Com a Web evoluindo a passos largos e browsers cada vez mais espertos, o que não faltam são novas APIs para explorar todo esse potencial. Jaydson Gomes mostra várias APIs modernas que você já pode usar hoje, como WebStorage, PostMessage, WebNotifications e History.

Como o tema é longo, Almir Filho mostra ainda mais APIs, agora com foco em acesso a recursos de dispositivos modernos. Aborda aspectos sobre câmera, acelerômetro, aúdio, GPS, vibração e mais. É o que você precisa saber pra dominar a Web em suas novas fronteiras.

Na sequência, Caio Gondim mostra como dominar todo esse mundo do front-end e facilitar o desenvolvimento com Debug no browser e Dev Tools. É um capítulo bastante aprofundado em como incorporar o uso das ferramentas de desenvolvimento no seu dia a dia com bastante produtividade e recursos úteis.

No último capítulo, Eduardo Shiota fala de testes com JavaScript. Um assunto de vital importância para garantir a qualidade de qualquer projeto que envolva front-end.

E, por fim, eu, Sérgio Lopes, idealizador da coletânea, escrevi esse prefácio e fiz o papel de editor, revisor técnico, cobrador de prazos e distribuidor de pitacos no texto alheio.

Em nome de todos os autores, espero que goste dos temas que escolhemos e aproveite o livro. Vamos mudar a Web juntos!

Sobre o editor

Sérgio Lopes é instrutor e desenvolvedor na Caelum, onde dá aulas de front-end e outras coisas. Escreve bastante conteúdo sobre front em seu blog (sergiolopes.org), twitter (@sergio_caelum) e outros lugares. Participa de muitos eventos no Brasil todo e publicou o livro A Web Mobile também pela editora Casa do Código.

Fig. 1.1

Capítulo 2:

Progressive Enhancement: construindo um site melhor para todos

Com navegadores cada vez mais modernos, cheios de recursos, a tendência é que nossos sites também fiquem cada vez mais sofisticados. Porém, não podemos esquecer: nem todo mundo que acessa nossos sites está usando um navegador com os últimos recursos.

O primeiro pensamento que aparece na cabeça de muitos quando ouvem algo parecido é: mas eu posso obrigar meus usuários a atualizarem seus navegadores. Ou então: usuário com navegador desatualizado não merece acessar meu site! Mas será que sempre podemos exigir navegadores atualizados dos nossos usuários? E será que navegadores desatualizados são o único problema?

Quando fazemos um site, normalmente o fazemos para um público imenso de pessoas. Não podemos esquecer que, nesse público imenso, temos pessoas que não gostam de JavaScript sendo executado em suas máquinas, pessoas que não podem atualizar seus navegadores, pessoas acessando a internet a partir de dispositivos limitados e pessoas com dificuldades motoras, visuais e auditivas que nem sempre conseguem utilizar o mouse para navegar ou dependem de leitores de tela para terem acesso ao nosso conteúdo. Mais ainda: temos um tipo de usuário muito importante para considerar, que não tem JavaScript nem CSS habilitados: as ferramentas de busca.

Isso significa, então, que não podemos fazer um site moderno e acessível ao mesmo tempo? Seria absurdo se a tecnologia evoluísse dessa forma. É por isso que os grupos que controlam o desenvolvimento das tecnologias que usamos na internet, como o W3C, têm sempre em mente a preocupação com esses casos citados. Mas como podemos desenvolver sites levando em conta esses cenários?

Graceful degradation

Uma primeira forma de pensar é desenvolver seu site primeiro para o público geral, que tem acesso aos navegadores mais modernos e não tem restrições de acessibilidade para, em um segundo momento, procurar atender aos usuários com mais limitações. Essa forma de pensar está presente há muitos anos no desenvolvimento de sistemas e a ideia de criar sistemas tolerantes a falhas; no mundo de desenvolvimento front-end, essa prática ficou mais conhecida como graceful degradation.

No entanto, pensar dessa forma pode nos levar a alguns problemas. Vamos pegar um exemplo para analisar: um botão de comprar em uma loja virtual. Você implementou a compra usando AJAX, para dar mais dinamicidade à navegação do usuário. Assim, no seu HTML, você provavelmente tem:

1 type=hidden name=produto value=123456> 2 type=number name=quantidade> 3 href=# id=comprar>src=icone-comprar.png>

E, no seu JavaScript (usando jQuery, para encurtar um pouco):

1 $(#comprar).click(function() { 2     var dadosCompra = { 3         produto: $([name=produto]).val(), 4         quantidade: $([name=quantidade]).val() 5     }; 6 7     // enviamos os dados no formato JSON para o 8     // servidor. 9     // atualizaPagina é uma função que vai ser 10     // executada depois que o servidor confirmar 11     // a compra. 12     $.post(/compra, dadosCompra, atualizaPagina, json); 13 });

Isso resolve nosso problema para a maior parte dos usuários. Agora paramos para pensar: a quais casos não atendemos? Uma primeira possibilidade é pensar na acessibilidade da página: será que usuários com deficiência visual conseguirão comprar na nossa loja? Dificilmente. Afinal, nosso botão de comprar é uma imagem! O leitor de tela não vai conseguir ler o texto comprar a partir dela. Além disso, esse botão, por ser um link, pode gerar confusão nesses usuários. Podemos melhorar esta situação com um HTML mais semântico:

1

Repare no uso da tag form para indicar que estes controles, juntos, representam informações que serão enviadas para um servidor. Temos também a tag button com o tipo submit declarado, para indicar que essa imagem é um botão e que, ao ser clicado, enviará o formulário.

Agora, fica mais fácil de um leitor de tela descrever o que esse pedaço da tela faz, e nem precisamos alterar nosso JavaScript! Mas será que há algum outro caso que precisamos tratar? Sim, usuários sem JavaScript: como está a experiência atual para eles? Eles conseguem comprar no nosso site? O que acontece quando eles clicam no botão de compra? Absolutamente nada!

Repare que, tendo a preocupação com graceful degradation, precisamos lembrar de todos os cenários que deixamos de lado ao desenvolver nosso site com as últimas tecnologias. E, se precisamos lembrar desses cenários, qual a chance de esquecermos algum? Mais ainda: agora precisamos implementar uma solução sem JavaScript. Será que é possível? Nosso servidor nos devolve um JSON como resultado, não uma página. Para mostrar algo útil para o usuário, precisamos de JavaScript, agora. Ou seja, por termos desenvolvido uma solução sem pensar nos casos mais limitados, acabamos caindo em um beco sem saída. Precisaremos refazer boa parte da nossa solução, inclusive do lado do servidor.

Como fazer, então, para não corrermos o risco de esquecermos esses cenários mais limitados? Começando por eles; essa é a ideia do progressive enhancement.

Progressive Enhancement

Para entender a diferença entre os dois, vamos usar o mesmo cenário: precisamos implementar o botão para comprar um produto em uma loja virtual. Porém, vamos começar por um cenário bem limitado: um navegador baseado em texto (o navegador Lynx, por exemplo, http://lynx.browser.org/). Nesse tipo de navegador, a única ferramenta que temos disponível é o HTML. Como implementar um botão de compra usando apenas HTML? Com algo próximo do que já tínhamos:

1 action=/comprar id=comprar> 2     type=hidden name=produto value=123456> 3     type=number name=quantidade> 4     type=submit>Comprar 5

Repare em uma diferença importante: o atributo action no formulário. Com ele, o navegador sabe para qual endereço no servidor os dados deste formulário devem ser enviados; não precisamos de JavaScript nenhum para ensinar isso para o navegador. Repare, também, em uma outra diferença: colocamos o texto Comprar dentro do botão em vez da imagem. Até poderíamos deixar a imagem mas, por ser uma questão estética, podemos deixar para um segundo momento, quando estivermos pensando no CSS dessa página. Por fim, vale observar que essa decisão de começar pelo cenário mais limitado influencia também o lado servidor da aplicação: ao comprar, vamos enviar nossos dados no formato padrão do navegador e não no formato JSON.

Agora podemos passar para um cenário um pouco mais complexo: usuários com deficiência visual. Com eles, já podemos usar JavaScript. Para implementar a compra com AJAX, como queríamos inicialmente, não teremos quase nenhum código agora:

1 $(#comprar).submit(function() { 2     $.post(this.action, $(this).serialize()); 3 });

Veja que, agora, não precisamos mais nos preocupar com os dados do formulário individualmente nem com a URI da compra. Por estarmos usando um formulário semântico, podemos simplesmente pedir para o jQuery pegar os dados desse formulário e enviá-lo como o navegador faria, porém de forma assíncrona.

Nesse mesmo cenário, também poderíamos começar a pensar no design da página, usando elementos grandes e/ou com bom contraste. E, ao testar esse cenário com um leitor de tela, provavelmente lembraremos de colocar marcações da especificação WAI-ARIA, para melhorar a usabilidade da página.

Quando começamos por um cenário mais limitado, é natural querermos solucioná-lo adequadamente. Isso nos força a pensar e desenvolver de uma forma que favorece um HTML mais semântico e desacoplado de CSS e JavaScript. Ganhamos não apenas um site que funciona bem para todos; ganhamos também um código mais limpo e fácil de manter.

No entanto, aplicar o progressive enhancement não é tão fácil como pode parecer à primeira vista. Diversas questões aparecem: qual vai ser meu cenário mais limitado? Por onde começar? Como acrescentar funcionalidade sem quebrar o que eu já tinha? Nas próximas seções, vamos analisar essas questões e como elas se aplicam a cada uma das tecnologias que usamos para desenvolver nossas páginas.

2.1 Por onde começar?

Quando começamos a pensar seguindo a linha do progressive enhancement, vemos que ele influencia os mais diversos aspectos do nosso projeto.

Por exemplo, se formos desenvolver um site para divulgar um produto, podemos pensar, antes de mais nada: qual o nosso público-alvo? Será que precisamos nos preocupar com navegadores antigos? Qual parcela de visitantes do meu site virá de dispositivos móveis? Quão importante é a integração com redes sociais? O que posso oferecer para meus visitantes com configurações mais limitadas?

Repare que essas questões são muito mais relacionadas ao seu negócio do que a questões técnicas. Saber respondê-las é muito importante para aplicarmos os conceitos de progressive enhancement corretamente, desde o começo do projeto.

Uma vez que se tenha claro o público-alvo, normalmente começam duas frentes de trabalho: o desenvolvimento da lógica do site (back-end) e o projeto da interface. No desenvolvimento do back-end, saber qual o público-alvo vai influenciar em quais funcionalidades serão implementadas e como. No desenvolvimento da interface, o paradigma do progressive enhancement influenciará o fluxo desse desenvolvimento, como veremos mais adiante.

Ou seja, o progressive enhancement não é apenas uma forma de desenvolver o código do front-end: é uma forma diferente de pensar o desenvolvimento do produto como um todo. Sendo assim, uma possível resposta para a pergunta por onde começar? é: pelo planejamento do seu produto. Uma vez que se tenham bem claros os objetivos do produto, as decisões técnicas (quais navegadores suportar, quais tecnologias usar etc.) tornam-se simples.

Infelizmente, isso dificilmente acontece em um cenário real. Normalmente temos que lidar com um público-alvo pouco conhecido, dificuldades na hora de tomar decisões de produto mais técnicas junto ao cliente e limitações no orçamento e no prazo de entrega. Ainda assim, é possível aplicar o progressive enhancement. Se não sabemos qual o cenário mais limitado a que vamos atender, podemos começar pelo mais limitado. Se não temos orçamento e/ou prazo suficientes para desenvolver todas as funcionalidades desejadas, podemos entregar as que atendem aos cenários mais limitados primeiro. Se o cliente não sabe quais tecnologias os visitantes do site vão usar para acessar o conteúdo, começamos com o mínimo possível de tecnologias.

Entregando com qualidade

Em todo projeto, temos três variáveis possíveis de serem controladas: orçamento, prazo e qualidade. No entanto, é impossível controlar as três ao mesmo tempo: se fixamos prazo e qualidade, o produto sai mais caro; se fixamos prazo e orçamento, a qualidade diminui; se fixamos orçamento e qualidade, o desenvolvimento demorará mais.

Contudo, sacrificar a qualidade normalmente não é uma boa alternativa. Sendo assim, se o prazo não é suficiente para entregar todas as funcionalidades, não entregue nada mal feito; entregue o que for possível. E, se você estiver seguindo o progressive enhancement, as funcionalidades que você entregar são aquelas que influenciam os cenários mais limitados, ou seja, o maior número de usuários possível.

Repare que atender ao cenário mais limitado primeiro não significa necessariamente começar a desenvolver pelos navegadores mais antigos (Internet Explorer 6, estou olhando para você) ou para navegadores baseados em texto. Novamente, é uma decisão que cabe ao cliente do projeto. O papel que cabe a nós, desenvolvedores, é informar o cliente das consequências de incluir ou excluir determinadas tecnologias do projeto.

Vale lembrar, também, que, cada vez mais, podemos fazer mais