/Desenvolvimento

voltar
/Desenvolvimento

Esclarecendo algumas falsas verdades que andam contando sobre JavaScript, front-end e React

PorGuilherme Oderdenge em

Há pouco li aqui um artigo intitulado “Fadiga por JavaScript“, do Kemel Zaidan. A proposta, ao meu ver, foi trazer para os brasileiros um pouco do que foi o Javascript Fatigue, um artigo em inglês que mostra o “caos” que reside no ecossistema da linguagem.

Sobre a “versão brasileira”, do Kemel, eu diria que é um pouco equivocada, superficial e mal desenvolvida, com argumentos e perspectivas vagas. Vou defender a minha espontânea réplica relembrando um pouco da evolução.

Eu acompanhei três épocas memoráveis no JavaScript:

  • A primeira foi quando carregávamos jQuery.min.js no index.html, seja por CDN ou não, e sequencialmente demais arquivos .js que orgulhosamente chamávamos de “a arquitetura” do nosso projeto. Lá habitavam vários tipos de códigos, nada criterioso e responsável, apenas o necessário para entregar valor. E entregávamos. Ô tempo bom, hein? Tomara que não precisássemos dar manutenção, porque se não…
  • A segunda foi ali pelo final de 2008 e talvez até o final de 2013, com a ascensão das frameworks, chegada do node e o aclamado require(‘module’). Nesse tempo, passamos a conversar sobre outras coisas senão jQuery. Falávamos sobre JavaScript “server-side” e em como o LinkedIn reduziu custos com o mesmo; sobre como RequireJS era incrível e a palavra “módulo” virou um buzz; e argumentávamos sobre qual era melhor: Angular ou Backbone. Sobretudo, ainda, sentíamos dificuldades para dar manutenção no nosso código. Principalmente porque isso tudo era muito novo. Deixou de ser o <script src=”jquery.min.js” /> que estávamos acostumados.
  • A terceira época é agora e…

Sim, o JavaScript mudou. Ele não só mudou, como evoluiu – e muito rápido. Bem como falado no artigo, deixamos de ser uma “toy language” e conquistamos o mérito de ser uma linguagem séria, madura e onipresente. Passamos a usar Grunt apenas para fazer deploy – e olhe lá! – e para buildarmos os nossos projetos, Webpack. Backbone e Knockout desapareceram de repente, apesar de terem deixado seus legados, levando consigo o underscore e o two-way data binding.

E por falar nisso, eu hei de citar: “Até um ano e meio atrás, o Angular parecia ser a ‘bola da vez’”.

O Angular realmente brilhou, mas “a bola da vez”? Quais seriam os critérios de quem especulou que ele “parecia” ser a bola da vez? Se for por uma boa quantidade de stars no GitHub e o carregar de logo do Google por detrás do criador, é inteligente salientar que ser popular não significa ser bom. Não que Angular não seja bom e não resolva diversos problemas de diversas empresas, mas é fácil notar, aliás, que toda a euforia se foi e a herança foi este repositório, com pouco mais de 20 mil stars. Se trata de evolução e adaptação. Em dado momento da história, Angular era uma solução que resolvia problemas, e de repente, pode ser que tenha chegado alguma outra coisa que o fazia igual ou melhor – e por que não?

[…] Contudo, Backbone, Ember e Polymer também estão nesse páreo, seguidos logo atrás por Knockout, Aurelia, Vue.js […]

Vue.js não está atrás de nenhuma destas tecnologias. Nem a frente. Ele é o produto da necessidade de resolver certos problemas com o menor esforço possível. Sobre Backbone, ele já não está mais nos holofotes. Está sendo sobreposto por filhos mais maduros e inteligentes—não está mais nesse “páreo”. Knockout? Às demais, não faço ideia de como andam.

Não costumo usar minha bola de cristal com muita frequência, mas meu palpite até agora é de que o React ainda não parece ser a solução definitiva para o desenvolvimento de aplicações SPA (single page applications). Apesar dos avanços que o projeto conquistou no campo da performance, seus pontos fortes ficam por conta do controle do fluxo de renderização e da possibilidade de modularização.

Não vejo pontos fortes em “controle de fluxo de renderização” e tampouco em “possibilidade de modularização”. Inclusive, acho a menção “possibilidade de modularização” curiosa e controversa, uma vez que esta – que é a principal característica do JavaScript atualmente – é o estopim da crítica à complexidade do React – que na verdade, nada tem a ver com ele:

Entretanto, a complexidade do setup e a necessidade do uso de ferramentas acessórias (Redux, Flux, boilerplates, transpilers etc.) abrem espaço para que soluções com uma menor barreira de entrada e facilidade de uso venham a surgir e eventualmente conquistem o espaço que o React tem ganhado. Não seria de se estranhar, afinal, no universo do JavaScript, uma volta completa em torno do sol dura bem menos que 365 dias.

Sim, o setup é um problema. Na verdade, era. Ou talvez nunca tenha sido.

Fazer o setup do ambiente para transpilar ES6 e JSX pode não ser amigável, intuitivo e simples, mesmo para o pessoal mais experiente. É uma tarefa chata e repetitiva, mas que vem se resolvendo com a melhoria da API do Webpack – o Webpack 2 ajuda muito, por exemplo -, e também porque muitos projetos podem ser começados utilizando o Create React App do Facebook, que nos livra de ter que pensar em building e permite focar em escrever código.

Sobretudo, você não precisa deste setup. Parafraseando a documentação oficial do React:

“While React can be used without a build pipeline, we recommend setting it up so you can be more productive”.

De acordo com a sentença acima, você pode ser mais produtivo com um ambiente em ES6 e JSX. React pode ser usado sem um ambiente de building. Sejamos pragmáticos: o setup está difícil? Precisamos realmente o fazê-lo? Se não, então, afinal, por que o fazer?

Mas o problema continua com a “necessidade” do uso de “ferramentas acessórias”. O articulista mencionou quatro:

  • Redux. Não é necessário e não tem nada a ver com React – inclusive, existem bindings para Angular. Ele é uma solução simples que gerencia o estado da aplicação – coisa que o React, por ser uma biblioteca que exclusivamente se propõe a resolver problemas de interface, não possui por si só. Neste ponto, Dan Abramov, uma das personalidades por trás de vários recursos e componentes do React – incluindo o próprio -, certa vez escreveu um artigo com bastante propriedade mostrando como nem sempre ele se faz necessário para resolver alguns problemas e inclusive tweetou:

  • Flux. Sequer uma ferramenta é. Se trata de uma arquitetura unidirecional de fluxo de dados para, novamente, gerenciar o estado da aplicação. É uma ideia de implementação e Redux foi a sua evolução. Não é obrigatório.
  • Boilerplates. Essa aqui eu realmente não entendi. Quais boilerplates? E ainda, boilerplates não são ferramentas – eles são fragmentos de código que ao invés de você ter que fazer por você, algo pronto está ali esperando para ser usado.
  • Transpilers. São ferramentas sim, mas houve uma redundância, porque este especificamente faz parte do setup e não tem nada a ver com React (novamente). Indo além: ressaltando o Babel, que converte ES6 para JavaScript legível para os browsers, é uma resposta à vários defeitos que a linguagem tinha – defeitos estes que somavam aos argumentos que diziam que a linguagem era “coisa de criança”.

Mesmo que você programe em Rails ou PHP, módulos terceirizados estarão lá. Com React não é diferente, tampouco JavaScript. Para sermos mais produtivos, para entregarmos mais código com qualidade, todas estas ferramentas estão à nossa serventia – mas nenhuma é um axioma; uma bala de prata.

Se alguma tecnologia mais atrapalha que ajuda, então ela não está devidamente resolvendo o problema do seu produto. Neste caso, é sábio sermos astutos, admitirmos isso para nós mesmos, e tomarmos uma atitude que mude esta realidade: utilizemos jQuery a moda antiga, se assim funciona, ou Angular, ou Vue, ou Backbone, ou qualquer ferramenta que seja.

Complexidade é uma questão de perspectiva. A linguagem Go, por exemplo, não tem uma solução nativa para dar um reverse em um array, diferente de JavaScript ou Haskell. Mas isso não torna JavaScript e Haskell melhor ou pior que Go. Eles resolvem problemas diferentes, e se um não satisfaz as minhas necessidades, por que o escolher afinal?

Todas essas mudanças que ocorreram no JavaScript e em seu ecossistema ao longo dos anos foram naturais. Problemas foram enfrentados e, então, resolvidos – como foi o React para o Facebook -, e tudo evoluiu dentro do fluxo natural das coisas. Ser rápido significa que a comunidade reage bem aos problemas que ela enfrenta. E que bom! Haskell, uma linguagem funcional que mencionei anteriormente, por exemplo, enfrentou – e ainda enfrenta – problemas com dependências que geraram o “dependency hell”, e de tão complexo que era o processo para resolver, criaram um guia de “sobrevivência”.

Para concluir, depois dessa grande e acelerada evolução, a impressão de que um “hello world” em JavaScript se tornou uma tarefa complexa vem à tona. Mas a verdade é que o hello world continua o mesmo. O que temos hoje, entretanto, é muito mais presença de JavaScript para resolver problemas de diferentes formas. A dica que posso deixar para nos livrarmos dos impasses que aparecem é: reflita mais. Pense mais sobre o seu problema. Quando este estiver muito bem esclarecido, corra atrás das ferramentas, mas pesquise bastante sobre elas. Leia diferentes opiniões, de diferentes lugares e de diferentes pessoas.

Por fim, tenha em mente que nenhuma tecnologia é uma bala de prata. Utilize as que estão em alta somente se realmente forem eficientes; se lhe ajudarem de fato. Dessa forma você não vai fadigar.

Deixe um comentário! 4

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Comentando como Anônimo

  1. Clap clap. Não é toda vez que vemos alguém escrevendo com propriedade e bom senso. Compartilho da maior parte do teu ponto de vista. Estamos mal acostumados, e desconhecemos até as próprias ferramentas que utilizamos.

  2. Parabéns Guilherme! Muito claro e maduro seu artigo. Sou muito a favor de quanto mais simples a solução de um problema melhor para o processo de criação e digo isto, pois sou adepto muitas vezes de escrever código javascript nativo para minhas necessidades. Pode ser considerado arcaico esta abordagem, mas para mim isto muitas vezes resolve rapidamente o problema que estou vivendo, já que utilizar um framework costuma aumentar consideravelmente a complexidade dos projetos (minha visão) e não deveria ser utilizado para pequenas necessidades. A escolha de utilizar um ou mais frameworks em um projeto deve ser criteriosamente avaliada, mas quando necessário não dispenso o uso de um framework javascript, principalmente no que tange ao front-end. Atualmente é muito difícil analisar todas as opções de frameworks que estão disponíveis no mercado e é impossível uma escolha rápida. Minha opinião, se realmente decidir utilizar um framework, sempre utilizar o que já esta consolidado no mercado, o que diminui a incidência de utilizar soluções que rapidamente desaparecem deixando os projetos reféns dos mesmos e gosto de considerar sempre para o “mesmo problema” mais de uma opção de framework, decidindo sempre pela solução mais simples de utilizar e implementar. Sobre a evolução do javascript, acrescentaria o momento que o ajax passou a ser largamente utilizado (2004 com o Gmail, 2005 com o Google Maps e 2006 com o lançamento oficial pelo W3C do Web Standard como padrão mundial), mesmo que esta funcionalidade ou técnica já estivesse presente na linguagem a muito mais tempo que o real inicio de seu uso pela comunidade (1999), mas visualizo que este foi realmente o momento que deu o BUM dos frameworks.

leia mais