DevSecOps

14 fev, 2017

Fadiga por JavaScript

100 visualizações
Publicidade

Já faz um ano que Eric Clemmons publicou um artigo em sua conta no Medium entitulado “JavaScript Fatigue”. Nele, Eric descreve, no original em inglês, o diálogo corriqueiro que teve com um amigo programador durante um café:

Eric: Como vai?
Amigo: Cansado.
Eric: Família?
Amigo: Não. JavaScript.

O texto acabou criando uma hype em torno da crescente dificuldade de acompanhar a evolução do ecossistema JavaScript. Não é para menos: desde o surgimento do Node.js, a linguagem criada por Brendan Eich tem evoluído numa velocidade vertiginosa. Foi subitamente alçada da categoria de simples “toy language” embarcada nos navegadores, para o panteão das linguagens “sérias”, utilizadas para os mais diversos fins: desenvolvimento mobile, desktop, computação científica e em sistemas de missão crítica.

Contudo, a velocidade com que as novidades e ferramentas surgem tem sido algo que beira o surreal. Tome, por exemplo, o caso dos task runners, responsáveis por automatizar tarefas corriqueiras como minificação e concatenação de arquivos, entre outras coisas: passamos do Grunt, para Gulp, Brunch, Broccoli, até chegar finalmente ao Webpack. Porém, não seria de se estranhar caso o leitor sinta falta de algum outro projeto, alongando ainda mais essa lista – Rollup ou Browserify podem ser apenas alguns desses. Tenha em mente que o primeiro commit no código do Grunt data de 21 de setembro de 2011 e você terá uma ideia do ritmo alucinante com que essas mudanças se deram.

No campo dos frameworks client-side, a situação não é diferente. Até um ano e meio atrás, o Angular parecia ser a “bola da vez”. Desde então o React¹ tem tomado de assalto o mundo do desenvolvimento frontend. Contudo, Backbone, Ember e Polymer também estão nesse páreo, seguidos logo atrás por Knockout, Aurelia, Vue.js e uma infinidade de projetos menores, cada um deles com suas particularidades.

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.

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.

1: Ahhh, React não é um framework, mas uma lib de UI, mimimi, etc… Ok, ok, eu sei disso…

***

Texto publicado originalmente na coluna “Post do Kemel” na Revista Locaweb #65