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

Há pouco li um artigo no iMasters, 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, publicada no dia 14 de fevereiro de 2017, 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:

  1. 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:
  1. 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.
  2. 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.
  3. 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:

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.