jQuery, você precisa muito mais dele do que imagina.

Ultimamente eu tenho visto uma série posts sobre o fato de que não precisamos usar mais o jQuery. Acho interessante todos os posts que nos fazem repensar no que estamos fazendo. Mas eu acho que a maioria começa a seguir uma linha de pensamento que não necessariamente pode estar de acordo com a realidade.

A impressão é de que as pessoas vão no fluxo, se parar para pensar a gente precisa muito mais do jQuery do que a gente imagina. Eu não acho que é fácil perceber onde está toda a genialidade da biblioteca, e quem não percebe o que está realmente por trás dela pode acabar subestimando-a sem perceber.

Na minha opinião apenas na minoria das vezes não precisamos do jQuery, e não o contrário. O exemplo mais batido é o document.querySelectorAll, mas o jQuery é muito mais que isso.

Quando você começa a desenvolver sem jQuery você passa a involuntariamente resolver problemas que não deveria estar resolvendo. E essa é uma das tarefas principais de qualquer biblioteca/framework. Um exemplo onde inevitavelmente você vai perder mais tempo e código que deveria é addClass, removeClass por exemplo, ou então em tarefas repetitivas.

$(‘p’).addClass(‘error’);

Esse simples e ingênuo comando serve inclusive para “n” paragrafos, não apenas para um. Desafio qualquer um a programar essa linha em javascript puro, sem que fique desnecessariamente verboso.

Já li alguns artigos gringos que falam que você não precisa mais de jQuery porque agora pode fazer as coisas com Javascript. Na verdade você sempre pode, porque jQuery é feito em Javascript.

Mas o jQuery tem uma série de propostas, um outro fator importante é o simples fato de aplicar design patterns sem que você se quer saiba quais são.

$(‘p’).get(2).addClass(‘error’).next().remove();

É como ler um texto, você faz muita coisa, com 1 linha de código e sabe rapidamente identificar o que ele faz. Existem alguns padrões de projeto ali.

Ainda hoje, existem desenvolvedores que mal sabem como usar Promises ou sequer sabem que existem. Quando você for desenvolver sem jQuery, você fatalmente vai acabar adicionando alguma biblioteca para resolver esse problema se realmente quer desenvolver aplicações ajax da forma correta.

Quando for utilizar Event Delegation para deixar sua aplicação mais performática, você provavelmente e intuitivamente faria isso:

$(‘body’).on(‘click’, ‘.mutable-view’, Function);

Não é só mais performática mas também resolve o clássico problema da  view que é dinâmica e que ao atualizar seus elementos filhos, estes perdem seus eventos.

Se for usar um approach Pub/Sub também terá de incluir na sua biblioteca do seu projeto caso não use jQuery.

$(‘p’).trigger(‘set’, { mydata:true });

$(‘p’).on(‘set’, Function( mydata ));

Caso ache que para um problema bem específico precisaria guardar uma instancia do seu objeto no seu elemento html teria de achar uma solução parecida com essa:

$(‘p’).data( new TextMessage(‘hello’) );

O que eu mais tenho lido e que também é utilizado como uma vantagem de não se usar jQuery é o fato de que em x browser tal método é mais lento, ou há problemas de memory leaks e tudo mais. É muito provável que você cometa erros piores em outros trechos do seu código.

Nenhuma biblioteca/framework do mundo é feito para ser perfeito, provavelmente ao realizar as tarefas que o jQuery realiza na mão, você provavelmente cometerá novos erros. Identificar onde o jQuery é mais fraco e substituir por um approach mais manual é muito mais vantajoso do que substituir a ferramenta inteira.

Uma coisa é certa, você estará resolvendo problemas que não deveria resolver. Você deveria pensar como um desenvolvedor e não como um codificador. Sua cabeça deve estar aberta à problemas de caráter arquitetural. Tanto em negócios, em projetos, na vida financeira ou na própria equipe que você trabalha, as pessoas tentam atacar problemas que em porcentagem significam 5% talvez 10% do nosso tempo ou esforço total para resolver um determinado problema.

Ninguém olha para as coisas nas quais perdemos 70, 80 ou 90% do nosso esforço. Quantas vezes já discutiu com alguém da sua equipe se o melhor é “_” ou camelcase, ou então vírgulas antes ou depois. Ou se deve usar ponto e vírgula no final etc etc. Não adianta também você ser um sênior master em sublime text e ao invés de usar três comandos, usar um só. Isso não vai te trazer muitos benefícios… Quando você sair de férias, a pessoa que vai dar manutenção no seu código não vai se beneficiar das suas mãos rápidas…

Realmente, o que vai te fazer perder mais tempo é a forma como organiza seu pensamento para resolver um determinado problema, como você interliga seus objetos e componentes e como abstrai realmente um ecossistema de módulos funcionando todos juntos, é isso o que importa. O resto você pode até discutir, mas deveriam ser assuntos com prioridade bem mais baixa…

Cada dia que passa  estamos desenvolvendo aplicações mais e mais complexas em js. Não faz muito sentido voltarmos nosso pensamento para trás e desenvolver em js puro. Salvo rarísssimas excessões. Pergunte para um programador Rails, se ele refaz suas aplicacões em Ruby, só porque ele pode… Talvez uma ou outra faça sentido, mas é mais provável que esta tarefa seja concebida como uma refatoração.

Em alguns posts eu li algo como “jQuery foi feito para designers”. Eu não sei de onde isso surgiu, pode até ser verdade na sua concepção lá no início, mas a biblioteca está na comunidade há um bom tempo e ela evoluiu muito. Se um designer consegue usar a biblioteca e fazer funcionar, isso é mais uma prova de que a biblioteca é muito boa, não é nenhum demérito e não significa que você como programador não tenha nada para aprender com ela. Muito pelo contrário, eu duvido que a maioria dos programadores front conhecem bem a biblioteca, e se conhecem, duvido que saibam utilizá-la da melhor maneira em diferentes ocasiões.

Na minha humilde opinião, o jQuery deveria ser um modelo para várias melhorias na linguagem, só o fato de melhorar a api do DOM como fazemos no jQuery, já seria um grande avanço. Ter Promises nativas, as chamadas ajax, os métodos e manipulação do DOM. Aquela grande merda que estão planejando para o ES6 colocando classes, adicionando keywords como let…. Quando eu penso que já inventaram as coisas mais imbecis, aparecem coisas novas.

O Javascript deveria evoluir de forma lenta e coerente, porque a linguagem já é MUITO boa… mudar a estrutura dela para tornar mais parecida com outras linguagens é a prova de que não conseguimos aprender nada do que a linguagem nos trouxe de melhor. Poderíamos ter uma chamada nativa require, define, porque a RequireJS já nos provou que é muito boa, e porque não deixá-la da mesma forma nativamente? Deveríamos dar pequenos passos, pequenas melhorias que fazem sentido, e elas fazem mais sentido pelo simples fato de terem sido TESTADAS. Já estão em produção, já se conhece os benefícios os malefícios também.

Deveríamos aprender muito com estas bibliotecas e frameworks… cada vez mais. Ao invés de andarmos para trás, tentando resolver os mesmos problemas, poderíamos ajudar mais estas ferramentas à resolverem problemas novos e estarem mais perto do que imaginamos ser o ideal para o bem do Javascript.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s