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.

Jails – MVC + AMD, repensando a arquitetura Javascript.

E aí galera, hoje estou retornando ao blog depois de muito tempo sem postar. E hoje é por um motivo pessoal muito bom =D.

Estou lançando o beta do meu framework para aplicações Js, o Jails! Faz um tempo que postei aqui sobre a minha iniciativa em desenvolver uma solução que ajudasse no desenvolvimento em javascript.

O princípio…

Eu comecei no blog mesmo a divulgar uma tentativa bem discreta de desenvolver um framework mvc que eu chamava de Jails. O nome era só uma brincadeira com o nome Rails, não tem nenhuma outra semelhança, e embora o nome Jails em inglês seja “Prisão” ou “Cadeia” eu gostei muito da sonoridade e da forma engraçada como surgiu quando disse : Rails para Javascript? Jails!… Foi mais engraçado na hora hahahhaa.

Eu havia parado de postar porque a minha criatividade já estava ficando limitada, eu percebia que os posts mais acessados eram os que eu não gostava muito de falar, coisas bem simples mesmo e que não tinham muito desafio. Como um blog não é um fórum, não queria usar dessas informações do google para criar posts e ganhar mais visitas.. Então comecei a pensar nos projetos paralelos, coisas que poderiam ajudar outras pessoas, foi assim que comecei a trabalhar neste humilde framework

A motivação

Eu nesse tempo meio distante do blog trabalhei em um projeto enorme, num e-commerce muito conhecido e muito grande… E comecei a conhecer o mundo dos sites que precisam mais do que firula, precisam ser funcionais, precisam fazer sentido… Quando se trabalha em agência, muitas vezes cai em projeto que você mesmo não acredita, porque realmente é um projeto de bosta. Mas agora estava trabalhando em algo sério.

Conheci a Requirejs, já pensava em módulos antes, não era um conceito totalmente novo, mas a forma como ele resolvia os problemas era genial, então aquela fissura por MVC estava diminuindo. O negócio era desenvolver Módulos.

O problema dos AMD’s..

Após trabalhar 2 anos usando AMD, descobri que eu não conseguia reaproveitar muito bem os módulos, aliás, o que era um módulo? A RequireJS não era e não é um framework, ela é uma biblioteca. Não é suficiente saber o que é um AMD, você precisa desenvolver sua arquitetura com estes módulos se relacionando.

Quando você trabalha em equipe, você precisa lidar com códigos que são completamente diferente dos seus, você precisa fazer componentes reutilizáveis nos módulos de outro desenvolvedor. No meu caso, nem os meus módulos eram reaproveitáveis, nem os dos outros devs.

A gente não conseguia também desenvolver numa mesma tela, módulos diferentes que no final se conversassem. Afinal de contas, o que era módulo? Até onde um módulo deve chegar ou até quanto ele deve saber da aplicação?

O AMD resolveu muitos problemas, até para refatorar é uma maravilha. Mas ele não resolveu o principal problema. Como devem ser desenvolvidos os módulos e como devem relacionar entre si. Quando percebemos isso, já era tarde, já tinhamos muitos módulos que não se conversavam, resolviam mais problemas do que deveriam, não eram reutilizáveis e toda hora tínhamos que resolver os mesmos problemas… As novas soluções vieram, mas cada um as desenvolvia no seu jeito, e agora temos um novo problema, uma aplicação sem padrão.

Soluções do mercado

Após essa reflexão, cheguei a conclusão de que tínhamos algumas ferramentas boas que resolviam determinados problemas como a RequirejsMustacheHandlebars, etc… Mas não tínhamos um FRAMEWORK. Um framework é importante para qualquer projeto, ele deve tentar reunir um conjunto de ferramentas, criar padrões para que seja o mais reutilizável possível, e te faça resolver cada vez menos os mesmos problemas.

Os frameworks que mais me chamavam a atenção eram: Angular, Ember, Backbone, React. Todos eles são geniais, excelentes e aprendi muito com eles. Mas comecei a identificar problemas, tentei repensar no projeto usando cada um deles. O grande problema é que eles não resolveriam os nossos problemas da melhor forma possível, eles até fariam isso, se usássemos todos eles juntos. Eu percebi que precisava de um framework que fosse a intersecção das melhores coisas que eles tinham na minha concepção do que era ideal pro projeto.

E o Jails….

Então retomei um projeto antigo, um projeto bem simples e discreto que tentava abstrair uma aplicação em 3 camadas. Model, View e Controller. Com a experiência que tive nesse e-commerce comecei a desenvolver mais essa biblioteca e este conceito de divisão de camadas e responsabilidades. Era primordial saber o que estava desenvolvendo nos projetos. Era um módulo complexo? era um módulo simples? esse módulo conversava com outros? ele cuidava de coisas maiores? tarefas menores?

A abstração é o maior bem de qualquer programador, é nela que consegue fazer com que a vida da sua aplicação faça sentido e seja harmônica. Então é muito importante abstrair. A conclusão disso é, eu não sabia o que estava criando. Quando eu criava um módulo AMD , eu não sabia o que aquilo era. Faltava abstração. Mas agora eu já tinha experiência e podia olhar de forma macro e podia dizer melhor como abstrair a minha aplicação.

O jails caminhou a partir disso, determinar o que era o que, na aplicação. Definir tarefas específicas, de forma que seja de fácil aprendizado, que reutilizasse coisas que já sabemos, e apenas nos guiasse para uma aplicação mais harmônica.

Teaser…

Há muito pra falar sobre o framework, mas se utilizar um post só vai ficar enorme, maior do que já está. Em resumo, o projeto chegou à um nível que considero satisfatório para ser usado em produção. Então queria divulgar nesse post, o meu beta release do Jails. =D

Ele está hoje na versão 0.7.8 e estou bem satisfeito do resultado. E o mais importante, ele é colaborativo, o fato de todos os componentes, módulos, aplicações serem modulares, isso possibilita que outras pessoas possam desenvolver coisas para o Jails sem precisar tocar no código fonte. Basta plugar nele e ver funcionar…

Eu aceito qualquer tipo de ajuda, documentação, componentes e módulos novos, com o site, pull requests, críticas e opiniões. Qualquer um pode fazer um componente reutilizável de forma muito muito fácil, e seria muito útil para a comunidade.

Ele já está disponível e pronto, mas ainda faltam alguns screencasts para ajudar a mostrar o quão fácil é usar. Se quiser fazer um fique à vontade e eu ficaria muito feliz com essa ajuda.

Volto para falar mais desse projeto em futuros posts, abaixo segue o projeto e um screencast sobre como fazer um componente no Jails.

E o principal… é um framework brasileiro.

Githubhttps://github.com/jails-org

Screencast: Jails – Componentes