Conheça seu inimigo

Pra quem desenvolve para web um pesadelo constante está ligado à inconsistência entre navegadores. Se eu for comparar a época em que comecei a desenvolver com o cenário atual, vivemos em uma era bem mais convidativa para o desenvolvimento de forma consistente; à época de guerra entre Netscape e Internet Explorer a coisa era bem mais difícil.

Essa guerra fez com que muita gente tomasse a decisão mais simples, de suportar apenas um navegador, originando a famigerada expressão: “Melhor visualizado em Internet Explorer 6.0 e resolução 800x600”. Eu mesmo já fui obrigado a adotar essa expressão em projetos passados (arrrghh!).

Mas as coisas mudam, a web evolui a uma velocidade impressionante e hoje a guerra está ligada à entregar navegadores cada vez mais aderentes aos padrões e com alto desempenho. Ótimo para quem precisava fazer malabarismos para dar ao usuário uma experiência consistente entre navegadores, mas isso não elimina a necessidade de empregar algum esforço para atingir este objetivo.

Uma das coisas que aprendi ao longo dos anos e que ajudava muito quando o IE6 ainda era um big player, foi “conhecer meu inimigo”.

Conhecer o seu inimigo está relacionado a estudar as limitações do ambiente para o qual se está desenvolvendo, de modo que você não ocupe seu tempo tentando reinventar a roda ou “nadar contra a corrente”. Quando se entende os pontos fracos e fortes de cada navegador, muita coisa pode ser simplificada. Com o Internet Explorer, a idéia era de não usar hacks CSS em hipótese alguma; e há quem duvide que isso seja possível.

Mesmo com um bom suporte de padrões pela maioria dos navegadores modernos, essa idéia de conhecer seu inimigo não é desperdiçada. Ainda existem inconsistências, principalmente se usarmos uma ótica de desenvolvimento para web móvel;  há uma infinidade de aparelhos, navegadores e especificações de suporte a CSS, HTML e JavaScript - e isso não quer dizer que você precisa de um CSS para cada navegador, como também era comum aplicar ao IE6.

Hoje, aplico esse conceito não somente voltado aos navegadores, mas em todo o ambiente em que trabalho. Entendendo as limitações que a HTML, CSS, JavaScript ou qualquer outra tecnologia impõe e abraçá-las como parte do dia a dia, sem tentar subverter seus conceitos para contornar tais limitações. Um exemplo é a maneira como vejo o sistema de herança do JavaScript em relação à alguns anos atrás. Quando se entende o sistema de cadeia de protótipos, é possível usá-lo a seu favor, ao invés de tentar refazer um sistema de herança para que fique mais próximo de linguagens orientadas a classes, tal como Java. Prototype faz isso, e logo que conheci a biblioteca achei interessante poder construir “classes” em JavaScript, mas hoje não tenho o mesmo entusiasmo com este tópico - protótipos funcionam, closures e módulos são padrões bem estabelecidos na comunidade JavaScript e programação funcional é parte da natureza da linguagem. Desta forma, fica a questão: será que é preciso escrever camadas e camadas sobre a linguagem, ou aprender a usar seus recursos e limitações de maneira correta?

Conhecendo seus inimigos!

Algumas referências para ajudar a identificar problemas que podem ser evitados, diminuindo a quantidade de tempo que você passa fazendo hacks ou reinventando a roda.

JavaScript Garden - http://bonsaiden.github.com/JavaScript-Garden/ 
Alguns pontos problemáticos do JavaScript, bugs e explicações dos motivos de cada tópico. Também tem muitas dicas sobre o qeu não fazer em JS.

WTFJS  - http://wtfjs.com
Mostra de maneira humorada as coisas bizarras que existem no JavaScript, porém com toda a explicação sobre os problemas e como evitá-los. Você pode ainda contribuir, caso encontre alguma coisa bizarra ainda não relatada.

Explorer Exposed -  http://www.positioniseverything.net/explorer.html
Lista inúmeros bugs (a maioria sobre CSS) do Internet Explorer, explica os motivos e mostra como resolvê-los. Também há neste site uma seção (bem menor) voltada a bugs de outros navegadores.

E claro, uma das melhores (senão a melhor) referência sobre JavaScript está na MDN. Porém muita coisa boa pode ser extraída da MSDN - principalmente para identificar problemas e soluções para Internet Explorer. 

Update:

Se você é adepto de árvores mortas - eu ainda sou - boas fontes para entender como se livrar de alguns problemas em JavaScript são os livros: High Performance JavaScript do Nicholas C. Zakas e Test Driver JavaScript Development, de Christian Johansen 

JavaScript ainda não é “linguagem de verdade”?

Há tempos atrás, eu li um excelente texto no blog Quirks Mode que falava sobre a negligência da maioria dos desenvolvedores web em relação ao uso e principalmente ao aprendizado de JavaScript. O texto é antigo mas ainda se aplica aos dias atuais. Me lembrei disso e resolvi escrever, pois durante esta semana ouvi:

”- Você tem um livro de TDD com JavaScript? Nunca vi, nem imaginei isso!” 

Sim, tenho. Não só um livro sobre TDD em JavaScript mas também alguns outros que falam de tópicos como design patterns aplicados ao contexto da linguagem, entre outras coisas. Investir conhecimento e dinheiro em entender melhor como programar e estruturar aplicações JavaScript me fez sempre parecer um alienígena pois, para os outros, meu dinheiro poderia ter sido melhor investido em livros sobre Java, ASP.NET, Ruby ou quaisquer outras linguagens “de verdade”.

Mas afinal, JavaScript não é linguagem de verdade?

Ao longo dos anos em que tive a oportunidade de trabalhar com as mais diversas equipes e projetos das mais variadas plataformas de desenvolvimento, JavaScript é a única em que ninguém se preocupa poucos se preocupam em dedicar tempo (e dinheiro) em melhorar seus conhecimentos para entregar a seus clientes produtos com maior qualidade. A linguagem não é vista como “linguagem de verdade” e sim como “alguma coisa para fazer gambiarras” e que não vale sequer o esforço de se empenhar em estudá-la, assim como fazem os experts em Java e todos os seus design patterns e filosofias sobre robustez, multiplataforma e etc. Este é um grande erro, pois JavaScript é sim uma linguagem poderosa e me espanta ver que pouca coisa mudou no pensamento dos “programadores de verdade” desde que li o artigo.

Com a grande variedade de bibliotecas, como jQuery, essa impressão que tenho se mostra intensificada de tal maneira que vejo situações em que o programador espera soluções completas e mirabolantes da biblioteca, quando estas são inerentes do conhecimento da linguagem em que a mesma foi escrita (JavaScript). Vejo esse comportamento se repetir também em muitos desenvolvedores que aprendem frameworks de outras linguagens e simplesmente se “esquecem” de entender alguns “porquês” da plataforma em que trabalham. Não sou contra o uso de bibliotecas (JavaScript ou não) no desenvolvimento de aplicações web, mas as vejo apenas como ferramentas que ajudam a eliminar o velho problema de reinventar a roda.

Muita coisa tem sido criada justamente por acreditar no potencial da linguagem, não somente voltadas a programação de aplicações em um navegador web:

  • CommonJS: iniciativa para fomentar o desenvolvimento JavaScript em outras plataformas além do navegador web
  • V8 JavaScript: motor JavaScript de código aberto do Google
  • node.js: biblioteca para manipulação de E/S orientada a eventos, sob o motor V8 JavaScript
  • Cappuccino: framework para aplicações com aspectos desktop, desenvolvido em Objective-J, linguagem que possui compilador e implementação em JavaScript;
  • SproutCore: framework para desenvolvimento de aplicações com aspectos de desktop que usa tecnologias web existentes: JavaScript, HTML e CSS
  • Handlebars: templates ultra leves para JavaScript (integra o projeto SproutCore)
  • JavaScriptMVC: framework MVC para aplicações JavaScript

Desenvolver para web não é simplesmente aprender uma tecnologia server-side ou jQuery. Entender as tecnologias envolvidas em todos os processos é um passo básico para quem se propõe a entregar soluções que realmente tenham qualidade, não somente limitado ao aprendizado de JavaScript, mas também HTML, CSS, XSLT e tecnologias relacionadas.

Top