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 - que muitos desenvolvedores acham que precisamos de um framework para trabalhar com JavaScript, mas que quando um framework completo está realmente disponível, preferimos usar soluções ad-hoc como React. Considerando isso, talvez devêssemos reavaliar se precisamos de estruturas.

A promessa do ES6

Este é o contexto, então, no qual o ES6 está sendo lançado. ES6 - também chamado de ECMAScript2015 - é a implementação mais recente de JavaScript. Ele promete mudar algumas das maneiras fundamentais como usamos a linguagem. É a primeira grande atualização desde que o ES5 foi lançado em 2009 e apresenta uma série de novos recursos que a comunidade vinha solicitando há anos.

À primeira vista, a afirmação de que o ES6 tornará os frameworks JavaScript obsoletos parece bastante absurda, porque as mudanças feitas no ES6 foram (pelo menos de acordo com alguns autores) pouco mais do que ajustes sintáticos . Ver as adições que foram feitas como sintáticas, no entanto, erra o alvo.

Isso porque a maior parte da “funcionalidade extra” que as estruturas fornecem pode ser vista da mesma maneira - um método de fornecer atalhos rápidos para recursos de JavaScript por meio de alterações sintáticas. Alguns desses atalhos sintáticos se tornaram tão familiares para nós que passamos a vê-los como recursos separados, mas eles são apenas maneiras de automatizar elementos existentes de JavaScript.

Isso não significa subestimar a utilidade da inovação sintática. Na verdade, a maioria dos novos recursos do ES6 são essencialmente atalhos sintáticos. Esses incluem:

Parâmetros padrão

Literais de modelo

Strings multilinhas

Atribuição de reestruturação

Literais de objeto aprimorados

Funções de seta

Mas a razão pela qual esses recursos ajudam a tornar os frameworks mais obsoletos é porque eles trazem funcionalidades que até agora eram limitadas a frameworks diretamente no núcleo do próprio JavaScript. Isso subsequentemente reduz a necessidade de estruturas na maioria das situações. Mais funções - incluindo promessas e construções com escopo de bloco - padronizam coisas que todos nós estávamos usando estruturas para fazer de forma ad-hoc. Os desenvolvedores que trabalhavam anteriormente em estruturas diferentes agora podem conversar uns com os outros pela primeira vez em anos. 

São dois outros novos recursos do ES6, no entanto, que realmente significarão o fim dos frameworks ou pelo menos pausarão o ciclo de vida brutal dos frameworks JavaScript . Essas são as novas maneiras pelas quais o ES6 implementa classes e funções.

Aulas 

Muitos desenvolvedores agora usam OOP como padrão e, portanto, vêm implementando classes em JavaScript há anos. Até agora, estávamos usando frameworks e nossas próprias soluções caseiras, porque trabalhar com classes no ES5 era uma dor total. Isso sempre me pareceu estranho, porque estava claro desde o início que o ES5 foi projetado para oferecer suporte a classes - na verdade, a palavra-chave `CLASS` estava reservada. 

Isso levou a discussões. Todos se voltaram para sua estrutura favorita e a usaram para criar uma interface OOP. Geralmente eram difíceis de trabalhar com qualquer pessoa que não fosse seus criadores, e eles não jogavam bem juntos. 

Agora, finalmente, com ES6, temos uma forma padronizada de trabalhar com classes. As classes ES6 usam protótipos, não a abordagem de fábrica de funções, onde se tivermos uma classe `baseModel`, podemos definir um construtor e um método` getName ().

Módulos

A situação era praticamente a mesma quando se tratava de módulos. Na verdade, alguns desenvolvedores ainda ficam surpresos ao saber que, por padrão, não havia suporte para módulos nativos no ES5. Acontece que nos acostumamos tanto com as soluções alternativas - implementadas via AMD, RequireJS, CommonJS e outros - que esquecemos que o que estávamos fazendo não era realmente uma parte do JavaScript.

Agora, com o ES6, todos nós podemos usar comandos simples - `importar` e` exportar` - para trabalhar com módulos. Ou pelo menos alguns de nós podem, algumas vezes. Porque, para minar um pouco meu próprio argumento bem aqui no final, este é talvez o primeiro lugar em que as pessoas recorrerão aos frameworks novamente. 

Isso porque a forma como os módulos foram trazidos para o ES6 é realmente muito confusa. Eles não refletem a maneira como os módulos são usados ​​no Node.js, e muitas pessoas vão aderir a esse método. Além disso, o suporte para módulos ES6 em navegadores não aparecerá tão cedo, então vamos precisar de algo como jspm para usar módulos ES6.

O resultado final

Resumindo, e como mostrei nos exemplos acima, o ES6 traz uma série de mudanças sintáticas para o JavaScript que reduzem muito a necessidade da maioria dos frameworks. Juntamente com o fato de que a maioria dos frameworks que estamos usando no momento são obsoletos ou desnecessariamente obscuros, poderíamos ver uma redução tangível e permanente no uso de frameworks nos próximos anos.

Ou talvez o ciclo simplesmente se repita e tenhamos apenas alguns anos aprendendo a escrever JavaScript melhor antes de nos refugiarmos novamente em nossas estruturas. O que está claro é que o ES6 trará grandes mudanças e os desenvolvedores precisarão estar à frente deles.