Uma das primeiras decisões tecnológicas que tomamos no Stack Overflow foi a de optar por um site com bastante JavaScript. Como muitos programadores, tenho sido historicamente ambivalente em relação ao JavaScript:
No entanto, é difícil argumentar contra o sucesso demonstrado pelo JavaScript nos últimos anos. O código JavaScript deixou de ser uma peculiaridade de um site para, ouso dizer, fornecer recursos essenciais úteis em sites que visito diariamente. Paul Graham tinha o seguinte sobre a definição da Web 2.0 em 2005:
Um ingrediente de seu significado é certamente o Ajax, que eu ainda não consigo usar sem aspas. Basicamente, o que “Ajax” significa é “Javascript agora funciona”. E isso, por sua vez, significa que os aplicativos baseados na Web agora podem ser feitos para funcionar de forma muito mais parecida com os aplicativos de desktop.
Três anos depois, não posso argumentar contra o senhor: O JavaScript agora funciona. Basta olhar ao seu redor na Web.
Bem, até certo ponto. Não podemos mais nos deleitar com o – e, para ser claro, digo isso de forma irônica – idade de ouro do Internet Explorer 6. Vivemos em uma nova e corajosa era de crescente concorrência entre navegadorese isso é bom. Sim, o JavaScript agora está maduro, onipresente e rápido o suficiente para ser um runtime de programação de cliente viável. Mas essa vibrante concorrência entre navegadores também significa que há centenas de diferenças agravantes nas implementações de JavaScript entre Opera, Safari, Internet Explorer e Firefox. E esses são apenas os quatro grandes. É o excruciantemente doloroso escrever e testar seu complexo código JavaScript em (n) navegadores e (n) sistemas operacionais. Isso fará com que o senhor sinta saudades dos bons e velhos tempos de HTML 4.0 e CGI.
Mas agora está acontecendo outra coisa, algo indiscutivelmente ainda mais significativo do que “o JavaScript agora funciona”. O surgimento de estruturas JavaScript comumente disponíveis significa que o senhor pode escrever em APIs JavaScript de nível mais alto, com garantia de funcionamento em vários navegadores. Essas estruturas eliminam as diferenças de implementação do JavaScript entre os navegadores e (em sua maioria) fizeram todo o trabalho pesado de testar suas APIs e validá-las em uma série de navegadores e plataformas populares.
Os ninjas do JavaScript entregaram sua arma secreta e definitiva: APIs comuns. Elas transformam o trabalho com JavaScript de uma tarefa desagradável de escrever uma vez, depurar em todos os lugares em algo que é realmente – ouso dizer – divertido.
Francamente, é uma tolice até mesmo considerar Agora, o senhor não pode mais desenvolver seu próprio código JavaScript para fazer até mesmo as coisas mais triviais em um navegador. Em vez disso, escolha uma dessas estruturas de API JavaScript maduras e amplamente testadas. Dedique um pouco de tempo para aprendê-la. No final das contas, o senhor escreverá menos código que faz mais e (quase) nunca precisará se preocupar com a compatibilidade do navegador. É basicamente o nirvana da codificação de navegadores, como observou Rick Strahl:
A jQuery é, sem dúvida, uma daquelas ferramentas que me deixaram muito empolgado, pois mudou consideravelmente minha perspectiva em relação ao desenvolvimento web, que passou de temer o desenvolvimento de clientes para, na verdade, querer aplicar princípios de clientes mais ricos e interativos.
Há várias estruturas populares de API Javascript para escolher:
Não pretendo ser um especialista em nenhum deles. Longe disso. Mas vou repetir o que o Rick disse: usar JQuery enquanto escrevo o Stack Overflow é provavelmente a única vez em toda a minha carreira como programador que eu desfrutado escrever código JavaScript.
É muito agradável escrever código contra o bibliotecas de API JavaScript sólidas e cada vez mais padronizadas que cobrem todas essas diferenças irritantes entre os navegadores. Eu, por exemplo, gostaria de agradecer ao John Resig e todos os outros ninjas do JavaScript que compartilham seus segredos – e suas estruturas – com o restante da comunidade.