2016 acabou há pouco tempo, mas, ufa! Finalmente! Foi um ano louco tanto para o mundo como para o JavaScript. Inúmeras novas bibliotecas impressionantes e frameworks surgiram, o site You Might Not Need JavaScript mostrou alguns padrões que fizeram muitos questionarem o uso deles de JavaScript (um pouco) e um tweet de um slide de uma paklestra de Nolan Lawson no Fronteers causou alguma comoção e respostas de grandes nomes como Jeremy Keith e Christian Heilmann, todas resumidas em um post de Nolan. Estou começando a pensar que "louco" é um eufemismo. 2016 foi insano. O ano que passou também incluiu fadiga no JavaScript. No caso de você ter perdido isso, muitos desenvolvedores estão cansados do ecossistema de JavaScript, uma vez que muitas ferramentas e configurações são necessárias para configurar um projeto "moderno" em JavaScript. Em dado momento, tantos desenvolvedores tinham compartilhado seus pensamentos que alguns artigos mais surgiram sobre "fadiga, fadiga, JavaScript"! Para ajudar você e eu a dormirmos melhor à noite, eu compilei uma lista de 3 promissoras bibliotecas genéricas/frameworks para desenvolvimento front-end.

Vue.js

Se você ainda não estava de olho em Vue.js, você definitivamente deveria. Vue.js é um pequeno framework JavaScript. Não, não fuja! Vue.js parece concentrar-se principalmente em visualizações e oferece apenas um punhado de ferramentas para regular os dados para essas visualizações. Em vez de um framework recheado com padrões de design de programação e limitações, a abordagem mínima de Vue.js não fica no caminho, o que é bom para uma mudança. Vue.js vem em dois sabores: uma versão stand alone, que inclui o compilador de templates, e a versão de runtime. Em praticamente todos os casos, você vai querer pré-compilar os modelos usando Webpack ou Browserify e apenas carregar o pacote de runtime do lado do cliente. Veja a página de instalação do Vue.js para mais informações. Para demonstrar sua simplicidade, abaixo está um exemplo de um componente que mostra uma mensagem e acrescenta interatividade a um botão para reverter a mensagem.

<div id="app">
  <p>{{ message }}</p>
  <button v-on:click="reverseMessage">Reverse Message</button>
</div>

import Vue from 'vue'

new Vue({
  el: '#app',
  data: {
    message: 'Hello World!',
  },
  methods: {
    reverseMessage: function () {
      const reversedMessage = this.message
        .split('')
        .reverse()
        .join('');

      this.message = reversedMessage;
    },
  },
});

Você sente falta de recursos que você realmente gostava de outras bibliotecas? Muitos plugins para Vue.js estão disponíveis e vários guias estão disponíveis para usar e escrever um plugin Vue.js. Você deve definitivamente tentar este framework se quiser obter produtividade rapidamente. Ele escala bem enquanto o projeto cresce. Vale ressaltar que esta biblioteca é mantida por uma pessoa com a ajuda de colaboradores e patrocinadores generosos. Independentemente de você escolher o stand alone ou o de runtime, o Vue.js suporta navegadores compatíveis com ES5 por padrão. Embora não esteja documentado, tenho certeza que você pode aumentar o suporte adicionando manualmente um shim ES5. Para obter mais informações, visite o site Vue.js ou o repositório GitHub. Se você estiver interessado, não deixe de ler o editorial de Nilson Jacques no Vue.js e a introdução de Jack Franklin para Vue.js 2.0.

Svelte

Lançado em meados de novembro de 2016, Svelte é realmente novo. É um framework JavaScript semelhante ao Vue.js, mas deixa uma pegada menor. Frameworks "tradicionais" precisam de código de runtime para definir e executar módulos, mantêm o estado, atualizam as visualizações e fazem qualquer coisa que frameworks fazem. Svelte dissolve-se em código JavaScript limpo como se você não usasse nenhum framework. O principal benefício disso é o tamanho do arquivo. O framework é realmente uma ferramenta que compila seu código-fonte para JavaScript simples que não tem dependências. Svelte tem plugins para que você possa compilar o código-fonte usando Webpack, Browserify, Rollup ou Gulp. Confira o repositório do compilador para todas as ferramentas disponíveis. Para comparação, recriei o exemplo Vue.js com Svelte:

<p>{{ message }}</p>
<button on:click="reverseMessage()">Reverse Message</button>

<script>
export default {
  data () {
    return {
      message: 'Hello World!',
    }
  },
  methods: {
    reverseMessage () {
      const reversedMessage = this.get('message')
          .split('')
          .reverse()
          .join('');

      this.set({
        message: reversedMessage,
      });
    }
  }
};
</script>

O mesmo módulo criado com o Vue.js produz um pacote de 7kb. O Svelte produz um arquivo de 2 kb. A implementação Svelte de TodoMVC pesa 3.6kb zippada. Para comparação, React mais ReactDOM sem qualquer código de app pesa cerca de 45kb zippada. Um benchmark de frameworks JS prova que Svelte compete com Inferno em termos de desempenho. Você deve definitivamente dar a ele uma chance se você se importa com as pegadas do seu aplicativo. Se você está pensando em usar isso na produção, eu aconselho você a esperar um pouco mais. O framework é realmente novo e não há planos futuros anunciados, exceto para o to-do na documentação que parece se referir à documentação em si e plugins. Apesar de ser super novo e não testado em produção, espero que isso ganhe alguma tração no próximo ano e possa influenciar bibliotecas e/ou frameworks ainda por vir. Quando escrevi este artigo, Svelte ou não tinha seu sistema de plugin documentado ou não tinha nenhum. O to-do indica que o Svelte irá suportar plugins e pode ter uma API para conectar-se ao framework. A compatibilidade do código compilado depende de sua pilha de fluxo de trabalho de compilação, por isso é difícil dizer qual é a compatibilidade padrão. Tecnicamente, você deve ser capaz de alcançar o apoio pré-ES5, incluindo ES5 shims. Para obter mais informações, visite o site do Svelte ou o repositório GitHub.

Conditioner.js

Por último, mas não menos importante, Conditioner.js. Com Conditioner.js, você pode condicionalmente carregar e invocar módulos. A diferença de outros carregadores de módulo é que Conditioner.js te permite definir condições sob as quais carregar e/ou mostrar um módulo. Isso te permite reduzir o tempo de carregamento e economizar largura de banda. Construído com o Aprimoramento Progressivo em mente, Conditioner.js sugere que você já deve ter componentes funcionais no local que são aprimorados com um determinado módulo JavaScript. O modo como esses módulos são definidos depende inteiramente de você. Você poderia até mesmo fazê-lo carregar módulos de seu framework favorito. A biblioteca não expõe uma variável global e recomenda usar um carregador AMD como RequireJS. Ele é compatível com Browserify, Webpack, Rollup e outros bundlers da AMD, mas você vai querer criar pequenos bundles para que o Conditioner.js só possa carregar os módulos que a página precisa. Para começar, você pode instalá-lo via npm: npm install conditioner-js. Mais informações podem ser encontradas na homepage do projeto. Esta demonstração é diferente das anteriores para melhor ilustrar as características do Conditioner.js. Imagine que desejamos mostrar o tempo restante para um evento. Um módulo para isso poderia ser assim:

import moment from 'moment';

export default class RelativeTime {
  /**
   * Enhance given element to show relative time.
   * @param {HTMLElement} element - The element to enhance.
   */
  constructor(element) {
    this.startTime = moment(element.datetime);

    // Update every second
    setInterval(() => this.update(), 1000);
    this.update();
  }

  /**
   * Update displayed relative time.
   */
  update() {
    element.innerHTML = this.startDate.toNow();
  }
}

Inicializar este módulo é tão simples como:

<time datetime="2017-01-01" data-module="ui/RelativeTime">2017</time>

O Conditioner carregará então o módulo ui/RelativeTime neste local no DOM. Observe que o conteúdo já está presente e em um formato aceitável e o módulo só melhora isso. Se você deseja que um módulo seja inicializado somente quando ele estiver visível para um usuário, você pode fazê-lo com as condições:

<!-- Show RelativeTime only if it is visible to the user -->
<time datetime="2017-01-01" data-module="ui/RelativeTime" data-conditions="element:{visible}">2017</time>
<!-- Keep showing RelativeTime after it was visible to the user -->
<time datetime="2017-01-01" data-module="ui/RelativeTime" data-conditions="element:{was visible}">2017</time>

Conditioner.js tem uma extensa lista de monitores, que você usa para definir condições. Não se preocupe! Você só tem que incluir aqueles que você precisa, impedindo a inclusão de código desnecessário. Você também pode passar opções como uma sequência JSON ou uma variante JSON ligeiramente mais legível.

<!-- JSON variant -->
<div data-module="ui/RelativeTime" data-options='unit:"seconds"'>...</div>
<!-- Or good old JSON -->
<div data-module="ui/RelativeTime" data-options='{"unit":"seconds"}'>...</div>

As razões para usar ou evitar o Conditioner.js são semelhantes às do Svelte: se você se preocupa com as pegadas do seu aplicativo, você deve definitivamente considerar usar esta biblioteca. Por outro lado, o futuro da biblioteca não está claro, já que nenhum plano futuro foi anunciado. O Conditioner.js permite que você defina monitores personalizados, permitindo que você o faça funcionar para todo o carregamento de módulos complexos. Por padrão, Conditioner.js é compatível com navegadores que suportam ES5. Muito parecido com Vue.js e Svelte, melhor compatibilidade pode ser alcançada usando ES5 shims específicos. Para obter mais informações, consulte o site do Conditioner.js ou o repositório GitHub.

Conclusão

Eu acho que esses frameworks e a biblioteca vão ser ótimos em 2017. Embora não seja um fã de frameworks, acredito que o Vue.js e o Svelte estão tomando medidas na direção certa para resolver problemas que existem nos frameworks atuais, possivelmente fazendo com que a indústria mude para novas formas de construir ou de definir as coisas. Qualquer melhoria é uma mudança que eu espero ansiosamente. Estou com a impressão de que a construção de aplicativos de um modo baseado em componentes é considerada o caminho a percorrer. Embora eu não espere uma grande mudança a ser causada por Conditioner.js, ele certamente resolve problemas que eu acredito que sejam bastante comuns em aplicativos baseados em componentes, tornando-se uma grande adição para o carregamento mais complexo. Quais bibliotecas você espera que sejam ótimas em 2017? Fale nos comentários! *** Tim Severien faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela Redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: https://www.sitepoint.com/3-javascript-libraries-2017/