O Que Há de Errado com a "Cultura jQuery"

Este não é um artigo sobre jQuery. Este é um artigo sobre ferramentas, sim, mas é, principalmente, um artigo sobre análise e o protagonismo do desenvolvedor front-end nesse processo.

Resumo

Aplicações variam. Aprenda a definir a arquitetura da sua aplicação. Aprenda a reconhecer a necessidade de uma SPA (Single Page Application).

A “cultura jQuery” te afasta de tudo isso, e, portanto, distancia você do seu papel enquanto desenvolvedor front-end.


Introdução

Se existe uma cultura nas agências digitais do Brasil que é unânime, é a cultura do jQuery. Não a cultura de utilizar todo o poder da biblioteca, no entanto, mas o hábito intrínseco de importar o jqueryX.X.X.min.js em todo projeto.

(Sim, em 2015.)

Sobre o que há de errado, serei sucinta, pois, para esse artigo, espero um público-alvo preguiçoso e acomodado.

O que há de errado

…em usar jQuery em 2015? O que há de errado em importar jQuery ao iniciar o meu projeto?

Analisando superficialmente, nada.

Mas isso tem dado brecha a uma zona de conforto profunda e, na minha experiência, com raízes difíceis de arrancar. Essa cultura se expande e transcende aquilo que lhe deu origem. Portanto, perceba:

Este não é um artigo sobre jQuery.

A comunidade de AngularJS é um exemplo de que isso não é sobre jQuery. Muitos migraram dele ao Angular sem abandonar a cultura. O resultado? Bem, muito tem sido dito sobre código Angular legado, que ninguém quer dar manutenção. A escolha errada já foi feita, e isso é demasiadamente penoso para a manutenção de uma aplicação complexa.

O fato é que a cultura não mudou. Ainda se adota biblioteca ou framework em escala sem pensar duas vezes.

Aprendendo a evitar

Deve-se saber quando abranger uma visão holística do projeto, e quando separar responsabilidades.

A separação de responsabilidades se daria pela análise dos requisitos da aplicação e dos desafios gerados, que trazem consigo o que chamo de “subproblemas” (necessidades que surgem durante a análise do desafio), que devem ser solucionados separadamente. A visão holística ajudaria a estruturar os componentes de forma consistente em um sistema, definindo uma arquitetura.

Falando de desenvolvimento front-end moderno (e, portanto, falando de front-end modular e de unidades encapsuladas e independentes, os componentes), essa separação de responsabilidades torna-se ainda mais fácil! Vejamos, abaixo, alguns subproblemas que surgem durante a análise de requisitos, apenas para exemplificar o que quero dizer quando trato a decisão de ferramentas como uma solução para um subproblema.

Os exemplos a seguir não explicam o front-end modular na prática. Adianto, no entanto, ferramentas como Browserify ou Webpack, que fazem parte do tooling necessário.

1. Resiquições Ajax

Subproblema: escrever Ajax em JavaScript é pouco intuitivo, difícil de ler e escrever.

Solução possível: encapsular, no componente um módulo como Reqwest e httpinvoke. Você pode, inclusive, utilizar apenas o Ajax do jQuery (e não o jQuery inteiro!).

2. Manipulação excessiva do DOM

Subproblemas: manipular DOM com JavaScript pode ser bastante exaustivo. Também, manipular em um nível excessivo é extremamente custoso para a performance da aplicação.

Solução possível: Virtual DOM, que está embutido em bibliotecas como React e Mithril. Ou, se precisar mesmo do DOM, considere pacotes como qwery ou Dominus, junto com domready.

E se precisássemos de Ajax no React, por exemplo? Este mau exemplo na documentação do React importa o jQuery inteiro. Como você faria? 😉

Sobre arquitetura

Esse tópico deve ser tratado durante a visão holística do projeto, isso é, da aplicação enquanto sistema de componentes. O subproblema seria a necessidade de estrutura que uma aplicação requere.

Para isso, você não precisa usar aquilo que é tradicional (diretamente: você não precisa usar MVC). Existem outras implementações de arquiteturas que não a implementação feita pelo seu framework amado. Existem outras arquiteturas que não Model-View-Controller.

Basicamente? Tenha um conhecimento decente de arquiteturas front-end (sugiro abrir a mente com Flux, que já possui bastante materiais e implementações da arquitetura disponíveís), e não um conhecimento aprofundado de MVC.

Conclusão

Conheça o projeto e saiba como analisar seus requisitos. O resultado deve ser uma descrição explícita da sua aplicação, com subproblemas já reconhecidos e, então, soluções possíveis, todas envolvidas por uma solução possível maior, que é a da arquitetura (definida durante a análise holística). Parece chato, mas vira hábito e acaba funcionando muito bem.

Lembre-se de que existem habilidades que a documentação de uma ferramenta nunca te ajudará a desenvolver.

Com o tempo, você vai saber quando adotar um framework específico em escala, quando optar por bibliotecas monolíticas, e terá, inclusive, seus preferidos a ponto de não ter sempre que definir soluções possíveis para subproblemas que aplicações têm em comum.

(Em alguns projetos, você enxergará padrões, por exemplo: qwery, domready e lodash são usados juntos frequentemente.)

Um dia, no entanto, suas ferramentas falharão, outras ferramentas se adaptão melhor à realidade de seus projetos, e, então, o ciclo de análise recomeça. E você já sabe como proceder.

Seja curioso

No mais, seja curioso sobre arquiteturas de software, padrões de projeto, tooling — basta ser leitor(a). Seja curioso também sobre opiniões, principalmente quando elas tratam de desafios que ainda não tivemos. A visão crítica é ideal para abandonar a cultura jQuery.

O estudo permite que as soluções possíveis surjam mais intuitivamente.

A prática virá com os desafios, e nesses desafios é que deve entrar o seu protagonismo de apresentar soluções possíveis.

Notas

Esse é um rascunho de pensamentos que venho acumulando há algum tempo em razão de experiências de trabalho que tive, e confesso que eles podem ter sido apresentados de forma confusa, embora eu tenha me esforçado. Mas isso aqui não era para ser receita de bolo, de verdade! Até mesmo os exemplos citados não devem passar de exemplos.

A minha abordagem possui falhas, e uma deles é que exige de quem desenvolve um conhecimento vasto de ferramentas, quando se usava apenas uma para tudo. (Para isso, recomendo um recurso disponível no npm e mecanismos de busca: a busca.)

Mas perceba que o conhecimento vasto é apenas de ferramentas. O conhecimento exigido pelas ferramentas em si acaba sendo menor do que o exigido por aquelas all-in-one como jQuery e AngularJS. O fato de encapsularmos dependências considerando a necessidade de cada componente no front-end é um modo de mantermos a curva de aprendizagem fragmentada.

De acordo com o que venho experimentando, desenvolver essa mentalidade tem retornado experiências maravilhosas e, inclusive, gerado menos código legado. Basta apenas aplicá-la à Engenharia de Software com bom senso.

Conteúdo sugerido

Os complementos abaixo são apenas para despertar a curiosidade em relação aos conceitos apresentados neste artigo, e não devem substituir o estudo necessário para deixar de lado, na prática, a “cultura jQuery”.


Se você entendeu a razão pela qual a “cultura jQuery” distancia você do seu papel, a mensagem foi entregue com sucesso.