Por que escolhemos Vue.js

Uma das decisões mais difíceis no processo de desenvolvimento da nossa nova plataforma foi a escolha de um framework front-end. Essa decisão envolveu toda nossa equipe, a equipe de produto e até alguns stakeholders, pois impactaria todo o nosso processo de desenvolvimento, a performance do site para os usuários finais e até mesmo influenciaria na contratação de novos desenvolvedores.

Hoje, após quase 6 meses, acreditamos que nossa decisão foi a correta. Tentaremos explicar neste texto tanto os motivos que nos levaram a adoção do Vue.js quanto os motivos que nos mostram que tomamos a melhor decisão.

Precisamos falar sobre o Frontend

A nossa aplicação começou a ser desenvolvida no final de 2016, utilizando Bootstrap e jQuery, o mesmo stack utilizado na nossa plataforma atual. Nossa equipe já estava bastante familiarizada com essas tecnologias. Graças a isso, tivemos uma ótima produtividade no período inicial de desenvolvimento. Funcionalidades mais complexas eram implementadas utilizando plugins de jQuery: jQuery-UI, Selectize, Fullcalendar e jQuery Mask, entre outros.

O problema é que apesar da familiaridade da equipe, esse stack já mostrava sua idade. Um código centrado em eventos do jQuery é um desafio para manutenção e para a produtividade. Precisávamos de uma solução que nos permitisse escrever Javascript de forma mais simples. A necessidade de utilizar para um framework JavaScript mais moderno e baseado em componentes começou a ser discutida.

Após o redesign da aplicação, isso ficou ainda mais evidente. Toda a interface foi redesenhada com base em Material Design, com animações e novas interações mais complexas. Era o momento perfeito para fazer a migração!

Escolha

Nossa escolha foi feita de forma democrática. As opções iniciais eram React e Vue.js, mas o Angular.js também recebeu alguns votos.

As duas primeiras pareciam maduras o suficiente, com comunidades bastante ativas, e muito apoio interno. No fim das contas o Vue.js venceu essa disputa.

Uma das principais críticas técnicas ao React era a utilização de JSX, a complexidade do stack e o fato de que este stack era um alvo em movimento, sempre com novidades aparecendo. Um stack Vue.js parecia mais estável aos nossos olhos, com boas práticas estabelecidas e amplamente aceitas dentro da comunidade.

Um dos pontos positivos que mais pesou a favor do React foi a possibilidade de migração para uma aplicação nativa com o React Native.

Porém, após estudos, foi verificado que o investimento teria que ser muito grande: seria necessário abstrair todos os componentes da aplicação, de forma que pudessem ser utilizados tanto dentro de páginas web quanto de aplicações. Algo como o react-native-webajudaria, mas também traria algumas limitações.

Escalabilidade out-of-the-box

Um dos grandes atrativos do Vue foi a possibilidade de começar com poucos componentes e sem utilizar nenhuma ferramenta adicional. Utilizar um novo framework de frontend por si só já era um desafio grande. E o desafio de usar um framework unido a uma ferramenta de compilação seria ainda maior!

O Vue.js dispensava essa cerimônia, pois não necessita de uma etapa de compilação, ou uma linguagem especial como JSX.

A própria documentação do Vue.js nos dava um caminho bem simples para começar, ao encorajar a importação da biblioteca diretamente de uma CDN, com apenas uma linha de HTML:

<script src="https://cdn.jsdelivr.net/npm/vue"></script>

Isso nos deu a possibilidade de começar a trabalhar na arquitetura dos componentes e determinar a viabilidade de uso do Vue.js na plataforma inteira. Nossos primeiros componentes foram um sistema de comentários e um pequeno tookit de componentes, incluindo um modal e alguns campos de formulário.

Em um segundo momento, quando já estávamos comprometidos com o Vue, instalamos a gem webpacker, oficial do Ruby on Rails, que permitia compilação de código JavaScript e era bem integrada com nosso backend.

Com o Webpack era possível utilizar Single File Components, que nada mais são que arquivos com extensão .vue, contendo o código HTML, Javascript e CSS de um componente, com a seguinte estrutura:

<template>
  <div class="hello">Hello, {{ name }}</div>
</template>
<script>
  export default {
    props: {
      name: String
    }
  };
</script>
<style>
  .hello {
    color: blue;
  }
</style>

Tais arquivos foram um grande potencializador de produtividade e organização de código, pois permitem que um desenvolvedor consiga utilizar apenas um arquivo para trabalhar em um componente, necessitando de menos mudanças de contexto. Esse tipo de organização nos permite manter a filosofia Single Responsibility Principle também no nosso frontend.

Familiaridade e Velocidade de Treinamento

O uso de templates HTML no Vue.js foi um dos pontos mais importantes na nossa decisão de utilizá-lo. O markup é bem simples e com poucas palavras-chave necessárias para 99% da aplicação.

Em 99,9% do nosso código, utilizamos apenas v-if, v-for, além das formas reduzidas do v-on (@) e v-bind (:). É uma interface relativamente simples, comparada, por exemplo, com o Angular.

A comparação com o JSX é inevitável. Apesar do JSX do React não ser exatamente difícil de utilizar, a mistura de Javascript e HTML necessita de um cuidado adicional para que o código não se torne complexo e intrincado demais. A possibilidade de usar qualquer feature do Javascript no JSX o torna flexível demais e seria necessário muito tempo, dedicação e documentação para manter o código homogêneo em uma equipe de desenvolvimento numerosa.

A API do Vue.js é bastante simples, e também possui uma forma declarativa. No lugar de classes ou prototypes Javascript, o Vue.js utiliza um objeto Javascript com propriedades indicando cada tipo de elemento, o que deixa o código homogêneo.

export default {
  name: "",
  props: {
    myValue: {
      type: String,
      default: "default value",
    },
  },
  data() {
    return {
      mutableValue: "default",
    };
  },
  mounted() {
    //...
  },
  methods: {
    someMethod() {
      // ...
    }
  }
};

A API Javascript dos componentes também é mais simples do que parece. Um exemplo é a : apesar da flexibilidade, o único lifecycle-hook de componente que realmente necessita ser utilizado acaba sendo o mounted.

Os outros hooks são úteis para diretivas e outros recursos mais avançados, mas não são necessários para o uso no dia a dia.

Comunidade

A qualidade do código criado pela comunidade Vue.js também merece destaque! Ao começarmos o desenvolvimento já adotamos um componente feito por terceiros, o vue-at, que já chegou solucionando um problema complicadíssimo em uma timeline apertada: um popup de lista de usuários com função auto-completar. A integração com nosso código foi rápida e sem bugs, o que foi uma surpresa bastante agradável na primeira semana com Vue.js.

Essa experiência positiva se repetiu em outros pontos do desenvolvimento, e praticamente todos os plugins jQuery que usamos, possuíam um correspondente em Vue.js de alta qualidade. Devido a simplicidade da API do Vue, wrappers de componentes escritos em Javascript puro geralmente tem uma ótima qualidade. A migração foi rápida, e tivemos uma substancial melhoria no código.

As soluções oficiais do Vue para os problemas comuns de frontend também são de alta qualidade: o vue-router, vue-resource e vuex são bibliotecas ótimas e com APIs intuitivas e produtivas. Já estamos utilizando os dois primeiros em nosso código e não tivemos nenhum problema ou dificuldade que não fosse solucionada com uma visão rápida na documentação.

E já que mencionamos documentação, a que é mantida pela comunidade, é detalhada, abrangente e muito bem escrita. É sem dúvida uma das melhores documentações que já utilizamos!

No geral, nossa experiência com Vue.js foi ótima. Não temos nada a reclamar do framework em si.

Nossos únicos obstáculos foram ferramentas e módulos de terceiros, que nem sempre tem a mesma qualidade do próprio framework. Quer entender mais sobre isso? Continue lendo para entender algumas das dificuldades que tivemos no nosso processo.

Excesso de componentes de terceiros

O lado ruim de ter uma comunidade vibrante é que existem soluções de terceiros para praticamente qualquer problema, por menor ou por mais simples que seja a solução. Existem alguns wrappers que não trazem nada mais do que um import e adicionam um método nos componentes.

Também existem alguns componentes que importam coisas demais. Alguns trazem até mesmo o jQuery e o jQuery-UI como dependências, adicionando algumas dezenas de kilobytes no seu JavaScript minificado.

Alguns destes módulos limitavam bastante as possibilidades de uso dos componentes, como foi o caso encontrado nos wrappers do Dropzone, do Moment e do Chartist. Em alguns, as possibilidades de uso dessas bibliotecas eram drasticamente reduzidas. Outros tinham interfaces que deixavam a utilização ainda mais complexa.

Nossa solução, nesses casos, foi abandonar os wrappers Vue feitos por terceiros e utilizar estas bibliotecas de forma direta no nosso código. Não tivemos um aumento na complexidade, e tivemos flexibilidade para utilizar as bibliotecas Javascript de forma mais idiomática e simples.

Ao adicionar um novo componente usando o npm ou o yarn é importante verificar a qualidade do código, a compatibilidade com versões mais modernas do Vue, a atividade do repositório no Github… E se utilizar o módulo realmente é uma vantagem para seu projeto!

Webpack

O Webpack é provavelmente a ferramenta mais popular de frontend, mas a nossa experiência não foi das mais agradáveis. Em parte devido aos defaults trazidos pelo rails-webpacker, uma gem oficial do Ruby on Rails.

O primeiro deploy foi traumático, devido a maneira que o Babel é configurado por padrão. Demoramos para entender o motivo do UglifyJS não conseguir minificar nosso código.

Na realidade, o Babel não estava transpilando o código para ES5 e a configuração padrão gerava código incompatível com o Uglify. Isso foi corrigido em versões posteriores da gem.

A funcionalidade de HMR (Hot module reloading) nunca funcionou como anunciado, e quebrava diversos componentes. Era possível carregar a página e ver alguns componentes, mas rapidamente encontrávamos algo quebrado ou um componente que sequer renderizava.

A saída de console do Webpack também incomodava bastante, por ser verbosa demais. Infelizmente as opções –quiet ou –silent não ajudam muito, pois a ferramenta deixa de emitir qualquer informação.

Também tivemos alguns problemas de migração para o Webpack 3, pois esta gem não possui um mecanismo de atualização. Basicamente a atualização consiste em desinstalar manualmente a versão anterior e daí instalar a nova. O que é um pouco complicado, já que a ferramenta cria vários arquivos em diversos locais.

A nossa nova aposta atualmente é a ferramenta Brunch, que possui uma configuração mais simples, tem uma integração com o Rails menos intrusiva, não necessita de um servidor rodando o tempo todo em outro processo. E já demonstrou uma performance de compilação bem melhor em nossos testes.

Conclusão

A nossa equipe aprovou o Vue.js. Apesar de ser uma equipe composta majoritariamente de desenvolvedores backend, todos os desenvolvedores já trabalharam com o framework em algum ponto do desenvolvimento.

Em certo ponto, a migração de partes antigas da aplicação para que começassem a usar o framework chegou a ser um requisito colocado pela própria equipe, devido aos ganhos de produtividade e novas possibilidade de UX que tivemos ao migrar para o Vue.js.

Hoje recomendamos o Vue para qualquer equipe que queira melhorar seu frontend e maximizar sua produtividade. Nos próximos posts trataremos de outros aspectos dessa migração, como criação de componentes, criação e uso de filtros e diretivas, como utilizamos internacionalização e como utilizamos nossas ferramentas.

Este post te ajudou, ficou com alguma dúvida? Deixe um comentário para gente!