Fatiga por JavaScript

fevereiro 14, 2017 12:00 pm Publicado por Deixe um comentário

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

Source: IMasters

Categorizados em:

Este artigo foi escrito pormajor

Deixe uma resposta

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