Cada vez que o JavaScript passa por uma grande atualização, parece que repetimos o mesmo ciclo. No início, os desenvolvedores ficam maravilhados com os novos recursos. Eles voltam para a codificação diretamente em JavaScript, e os frameworks se tornam menos populares. Então, nos períodos relativamente longos entre os lançamentos, os frameworks começam a oferecer novos recursos e a atrair os desenvolvedores de volta. Repetir.

Com o lançamento do ES6 – sem dúvida a atualização mais esperada para o JavaScript desde 2009 – muitos esperam que o mesmo ciclo se repita. Já estamos vendo o uso de alguns frameworks populares diminuir . No entanto, eu quero defender uma previsão mais radical: ES6 finalmente quebrará este ciclo. Os desenvolvedores de JavaScript do futuro não usarão estruturas. Em absoluto.

Eu sei que essa vai ser uma conclusão impopular, mas me escute. Não estou dizendo que o JavaScript terá seu uso limitado – na verdade, muitas empresas estão contratando desenvolvedores de JavaScript agora . Em vez disso, acho que dois dos principais recursos do ES6 (módulos e classes, especificamente) tornarão muitos dos frameworks mais populares obsoletos. Em outras palavras, os frameworks JavaScript morrerão da mesma maneira, e pelos mesmos motivos, que o Flash morreu – porque simplesmente não havia mais necessidade dele e as vulnerabilidades de segurança inerentes tornavam seu uso perigoso.

Portanto, antes de ficar na defensiva sobre sua estrutura favorita, deixe-me explicar por que acho que essa mudança ocorrerá.

O problema com frameworks JavaScript

As estruturas JavaScript existem como uma ferramenta para os desenvolvedores aproveitarem para desenvolver aplicativos front-end. E embora os frameworks tenham sido inegavelmente ferramentas muito úteis, os avanços nas especificações dos componentes da Web do JavaScript tornaram o desenvolvimento de novos aplicativos front-end (como aplicativos de página única) sem os frameworks existentes muito mais fácil. Isso levantou a questão de saber se as estruturas ainda são mesmo necessárias.

Vamos dar uma olhada nas estruturas JavaScript mais populares hoje e examinar onde elas caem. Você não precisa ir muito longe para isso, porque a maioria dos frameworks em uso hoje sofre de uma série de falhas fundamentais.

A maioria de nós que trabalhamos com frameworks JavaScript (e sim, estou nesse grupo) não percebe essas falhas, é claro, porque estamos acostumados com elas. Mas o simples fato é que a maioria dos frameworks que usamos violam alguns dos princípios básicos do HTML ou usam convenções de codificação altamente obscuras que os tornam quase impossíveis de aprender para iniciantes.

Além desses problemas, há outro problema mais importante: na verdade, não há uma boa definição do que constitui uma estrutura JavaScript em primeiro lugar. Isso levou a uma situação um tanto absurda em que um dos mais populares “frameworks” de JavaScript – Reat – não é realmente um framework. Na melhor das hipóteses, é uma biblioteca que os desenvolvedores usam para aprender a construir seus próprios frameworks JavaScript altamente especializados.

Todos esses problemas são manifestos nas estruturas mais populares em uso hoje. Mas também há uma série de questões específicas que afetam estruturas individuais. Então, vamos dar uma olhada rápida em cada um.

Angular e Angular 2

O fato de o Angular ter de aparecer nesta lista é indicativo de um dos problemas com estruturas JavaScript – que, embora se tornem obsoletas, as pessoas não vão necessariamente parar de usá-las. Muitos desenvolvedores, na verdade, dirão que o Angular ainda é “a melhor” maneira de codificar JavaScript , embora o framework esteja (a) obsoleto e (b) impossível de entender para quem não passou anos usando-o.

Essa segunda questão – de código que é quase impossível de entender – foi realmente transportada para o Angular 2. E embora alguns vejam isso como uma razão pela qual os desenvolvedores de back-end podem ganhar mais , na realidade, isso pode tornar a vida dos desenvolvedores miserável. Tome, como exemplo, o fato de que Angular 2 contém instâncias de HTML com distinção entre maiúsculas e minúsculas, o que não apenas viola os princípios do próprio HTML, mas também força muitos a implementar um analisador intersticial apenas para limpar o HTML que o Angular 2 produz.

React

A outra grande estrutura JavaScript – React – sofre de um conjunto diferente de problemas. Na verdade, em retrospecto, é possível ver o desenvolvimento do React como uma espécie de reação (trocadilho intencional) à obscuridade do Angular. O React promete aos usuários que é fácil de usar e não precisa ser mais complicado do que você.

Isso é verdade, até certo ponto. O problema é que o React não é realmente uma estrutura integrada, mas um conjunto de módulos e componentes que muitas vezes não funcionam bem juntos. Fazer qualquer coisa meio complicada com o React, como implementar a impressão digital do navegador , significa construir uma pilha complexa de componentes que você precisa manter e gerenciar constantemente.

Alguns argumentarão comigo aqui, apontando que sistemas como Redux e Flux permitem que pilhas complexas de React sejam usadas até mesmo por iniciantes. Eu rebateria que se você precisa usar uma estrutura para trabalhar com sua estrutura para trabalhar com JavaScript, então você está realmente em apuros.

Ember e Vue e Aurelia

Finalmente, uma nota rápida sobre alguns frameworks menos conhecidos e menos usados. A maioria dos desenvolvedores não tem muita exposição a nenhuma dessas três estruturas, pela simples razão de que elas não são amplamente utilizadas fora de seus próprios aplicativos de nicho.

Cada uma dessas três estruturas tem suas próprias idiossincrasias, mas o principal problema com elas está diretamente relacionado aos seus casos de uso de nicho. Nenhuma dessas estruturas atingiu a fatia de mercado necessária para construir um relacionamento verdadeiro com a comunidade JavaScript mais ampla. Como resultado, os desenvolvedores que amam essas estruturas muitas vezes estão lutando uma batalha difícil quando se trata de argumentar sobre seu uso.

Também vale a pena uma observação rápida aqui sobre por que nenhum desses frameworks ganhou popularidade, especialmente porque em muitos aspectos eles são os mais “completos” dos sistemas nesta lista. Ember, por exemplo, é provavelmente o mais “framework” dos frameworks nesta lista, mas é muito pouco usado porque sofre de problemas de desempenho, o maior tamanho de download, a maior pegada de API e a curva de aprendizado mais íngreme de qualquer um dos as estruturas nesta lista.

Pense nisso por um momento e você pode chegar a uma conclusão estranha – q