Minha visão do estado atual do Front end – Parte 1 – jQuery

Queria fazer uma regressão e pensar no desenvolvimento client-side sob a minha perspectiva. Talvez seja uma série quebrada em algumas partes, porque tem bastante assunto. Gostaria de compartilhar o que aprendi durante o crescimento da comunidade e sobre como eu vejo hoje.

Mas para olhar o hoje, é necessário aprender com o ontem, assim você consegue identificar padrões e entende quando algo está indo para uma direção boa ou não tão boa assim. Você tem o histórico e os contextos.

Mas não queria olhar o tempo de forma muito detalhista, porque o post ficaria super cansativo até pra escrever. Então vou falar de forma bem resumida o que vi acontecer e as consequências boas e ruins que percebi durante o crescimento da comunidade front-end.

Vivemos em outra época, fato. No meu começo no desenvolvimento web, nós não tínhamos nem 1 milésimo das alternativas que temos hoje, das bibliotecas que temos agora e nem sequer frameworks tínhamos. Nós precisávamos lidar com o nosso principal pesadelo na época, que era o Internet Explorer, ou melhor, a diferença entre os browsers.

Nessa época você era obrigado à aprender a linguagem, aprender bem a api do browser, saber como as coisas funcionavam por debaixo dos panos. Era muito comum, o programador Javascript dessa época inventar suas próprias soluções.

Em diversas vezes tive de criar ferramentas, bibliotecas e coisas do gênero para resolver um problema. Não havia github, então, mesmo se alguém já tivesse resolvido esse problema, tinha que ser bom também em divulgar essa solução, ter um site, com documentação etc.

A primeira grande revolução, jQuery

Esta pra mim foi a mais revolucionária das bibliotecas, é basicamente a mais genial que eu já vi. Por 2 motivos muito interessantes ao meu ver:

  1. Ele reusava todos os conceitos que você já conhecia, como os seletores css, manipulação do DOM, e aproveitava estes seus conhecimentos para que a curva de aprendizado fosse muito baixa.
  2. Poderoso e simples. Você fazia MUITA COISA mesmo, com pouquíssimo código, e código já otimizado, compatível com a maioria se não todos os browsers usados da época.

O John Resig foi brilhante na minha opinião na concepção desta biblioteca, introduzindo conceitos que para o front-end ainda eram muito pouco usados como os plugins. A biblioteca além de ser super simples de aprender e poderosa, era uma implementação genial de muitos conceitos importantíssimos da Ciência da Computação, mais especificamente falando da matéria de Engenharia de Sofware.

Para quem não estudou ou usou tempo suficiente, hoje pode cometer o engano de achar que ela é simples, defasada, fora de moda… mas pra mim possui uma genialidade disfarçada que de forma muito generosa possibilitou que todos pudessem usá-la sem precisar conhecer conceitos complexos. Gravem bem isso que destaquei, porque vou retomar esta parte quando for falar dos Frameworks atuais, como React e Angular.

Esta foi o Santo Graal das bibliotecas pra mim. Com ela eu aprendi conceitos como: Information Hidding, Encapsulation, Builder Pattern, Chainability, Futures/Promises, event delegation e assim por diante. Foi ao tentar entender como ela funciona, que muitos blogs foram destrinchando e falando sobre diversas técnicas que o John havia usado que estava escondidos em forma de Código Fonte.

Não me leve a mal, não é que outras bibliotecas também não usem diversos conceitos interessantes da programação, mas muitas delas acabam se tornando muito complexas, o que é o diferencial desta é que ela é genialmente simples mesmo se utilizando de várias destas técnicas.

O que é comum acontecer é o desenvolvedor ficar emocionado com as técnicas e esquecer de quem irá utilizar, e assim criar uma biblioteca ou framework com uma curva de aprendizado desproporcionalmente maior do que o valor que ele traz.

Nem tudo são flores, Questionamentos iniciais

Nesta época estávamos progredindo bastante o desenvolvimento no front-end. Arrisco a dizer que o jQuery junto com outras bibliotecas similares contribuíram para o avanço das aplicações Web, o que era muito difícil e custoso fazer, que necessitava de um programador muito talentoso, agora todos nós, meros mortais, podíamos fazer sem muita dificuldade.

Os Plugins foram o popularizaram a idéia de colaboração e reutilização de código no front-end. Sabíamos que eram acoplados à biblioteca, mas meio que era um consenso que todo projeto nasceria com jQuery embarcado, por questões de produtividade. Portanto esse acoplamento não causava tantos malefícios, não haviam concorrentes à altura que valesse a pena se preocupar com esse detalhe, porém nesta época já começávamos a nos questionar, se deveríamos ao desenvolver uma lib, fazer de forma desacoplada ao jQuery ou não.

Essa era uma decisão difícil de tomar, porque a princípio você não sabia o quão difícil seria desenvolver essa ferramenta sem a ajuda do jQuery, e quando começava, em alguns casos, percebia o quanto de código a mais tinha de escrever pra considerar todas as diferenças entre browsers.

Será que valia a pena desenvolver uma solução de forma desacoplada, mas gastar caro no desenvolvimento dessa solução?

Além desses questionamentos, começávamos a ter outros tipos de problemas. Começaram a aparecer os primeiros programadores que diferentemente dos mais antigos, já entravam no mercado de trabalho usando o jQuery como um atalho, o Javascript e outras técnicas de programação se tornariam secundários, já que muitos dos problemas que precisávamos resolver, eram resolvidos de forma muito simples com a biblioteca.

A famosa e recorrente discussão da Bala de Prata

Porém com o passar do tempo as aplicações começaram a ficar cada vez mais complexas. Agora não estávamos mais fazendo páginas estáticas com animações, agora estávamos na transição para se desenvolver Sistemas.

Com isso, o jQuery não resolvia um problema que se tornava muito recorrente: A organização do código. O jQuery para mim era uma solução com 1 camada de abstração acima do DOM. Ela não era um framework, ela não te ajudava na arquitetura do sistema. Não tínhamos o conceito de módulos, não era possível importar as coisas, a nossa forma de separar os trechos de códigos era uma sequência de chamadas de script no nosso html, o que acarretava muitas vezes na performance do carregamento do site.

Era muito comum algumas soluções no lado do back-end, como um serviço que concatenava de forma dinâmica os javascripts que você requisitava:

<script src="my/service/assets.php?js=js/main,js/home,js/vendor"></script>

Na agência que eu trabalhava, resolvíamos dessa forma, mandávamos pro servidor uma lista por parâmetros dos arquivos que gostaríamos de concatenar, e assim tínhamos um “arquivo” só para fazer o download que era nada mais do que um serviço server-side que lia estes arquivos hospedados no servidor através de chamadas I/O, concatenava-os ( pois eram apenas arquivos de texto ) e devolvia como resposta um texto como contentType text/javascript.

Não tínhamos node para fazer isso em tempo de build local. Haviam soluções em outras linguagens para isso, mas eram poucas empresas que usavam e eram pouco conhecidas.

Voltando ao problema descrito como Organização de Código, aconteceu o que é normal, o perfil que não estava acostumado ou não gostava muito da parte de técnicas de programação, tinha cada vez menos conhecimento do Javascript e menos incentivo pra isso, porque a biblioteca já resolvia muita coisa, eram chamados de Programadores jQuery.

Qualquer semelhança com algo que você presencia hoje, não é mera coincidência.

Mas aí você me pergunta: “Era realmente necessário aprender Javascript, já que o jQuery resolvia muito bem problemas de manipulação de DOM?”.

A resposta curta e grossa é não. Você não precisava, porque no final das contas, um plugin resolvia coisas muito complexas de UI, e a parte de manipulação de DOM estava bem próxima ao que aprendemos nativamente, graças ao John. Você não perdia tanto assim ao não estudar a api nativa do DOM.

Porém o Js possui areas de interesse diferentes. Se o seu objetivo era simplesmente adicionar classes ou remover coisas, ou tarefas de manipulação, você estava muito safe. Porém as aplicações começaram a ficar mais complexas, isso acarretou em lógicas mais complexas, em sistemas mais complexos.

Os Programadores jQuery tinham um defeito que particularmente acho o mais prejudicial para sua carreira, que era desconsiderar ou negligenciar a parte sistêmica, das técnicas de programação/organização/arquitetura ou uma preocupação com a sua qualidade de código, tanto quanto a qualidade visual.

Quando víamos as aplicações ficarem mais complexas com o tempo, na mesma proporção víamos o desastre em forma de código. Nunca me esqueço daquela dor de ter que resolver um problema em produção, porém você não consegue entender absolutamente nada do código que foi escrito, e não por falta de conhecimento da linguagem ou de arquiteturas ou de patterns, nada disso, simplesmente porque o código tem 600 linhas todas em uma funcão só, onde você mexe em algo, quebra outro e assim por diante.

O problema não era o jQuery, ele não resolve todos os problemas, ele não é defasado, ele tem um objetivo muito particular, acredito profundamente que ele é suficiente para muitas coisas que desenvolvemos hoje. O problema era achar que ele era o substituto do Javascript, que ele resolveria todos os problemas.

Acho que escrevi demais, na segunda parte vou tentar amarrar tudo, fazendo uma análise crítica do que eu vejo acontecer hoje que acredito de verdade ser coisas muito interessantes e outras que são extremamente prejudiciais para programadores mais novos, tentarei também dar a minha sugestão de “escada” de interesses que funcionou para mim e acredito ser um exemplo bom de como progredir como programador independente da época, da ferramenta, do framework ou de qualquer que seja o que está na moda no momento.

Um abraço!