Vue contra Svelte: ambos usam um compilador, e isso muda a comparação

  • vuetelemetry
  • Stacks
  • 6 min de leitura

O enquadramento habitual opõe o compilador do Svelte ao virtual DOM do Vue. A própria documentação do Vue chama a esta abordagem Compiler-Informed Virtual DOM. O que faz realmente cada compilador, e o que decide de facto a escolha.

O Vue e o Svelte são quase sempre apresentados através de uma única oposição: o Svelte compila, o Vue usa um virtual DOM. É um resumo cómodo e é enganador, porque ambos os frameworks assentam fortemente num compilador. O que difere é aquilo que cada compilador produz e aquilo que resta fazer em runtime.

O Svelte descreve-se como um framework que usa um compilador para transformar componentes declarativos escritos em HTML, CSS e JavaScript em JavaScript enxuto e fortemente otimizado. O passo de build é o centro do desenho: o trabalho de descobrir o que deve mudar é empurrado o mais possível para a compilação.

O Vue também compila, e di-lo explicitamente. A sua documentação afirma que o framework controla tanto o compilador como o runtime, o que lhe permite implementar otimizações em tempo de compilação que só um renderer fortemente acoplado pode aproveitar. O Vue chama a esta abordagem híbrida o Compiler-Informed Virtual DOM. O virtual DOM continua lá, mas o compilador diz ao runtime onde não precisa de olhar.

Vale a pena conhecer três dessas otimizações pelo nome, porque explicam por que razão comparar 'virtual DOM' com 'sem virtual DOM' falha o alvo. Static hoisting: o renderer cria os vnodes das partes imutáveis durante o render inicial, coloca-os em cache e reutiliza os mesmos vnodes em cada re-render seguinte. Nada é novamente comparado se não puder mudar.

Patch flags: o Vue codifica o tipo de atualização logo na criação do vnode, pelo que o runtime usa operações bitwise para decidir se tem de fazer um determinado trabalho. Não faz perguntas amplas sobre a árvore, verifica uma flag.

Tree flattening: cada bloco segue os nós descendentes que transportam patch flags, e não apenas os filhos diretos. Quando o componente volta a renderizar, o runtime percorre a árvore achatada em vez da completa, o que, segundo a documentação, reduz fortemente o número de nós percorridos durante a reconciliação.

Lidas em conjunto, estas três significam que o virtual DOM do Vue não é o diff ingénuo que a comparação abreviada sugere. O compilador já estreitou o espaço de procura antes de o runtime começar a olhar. É um desenho diferente do do Svelte, mas não é a ausência de um compilador.

Então onde está a escolha verdadeira? Menos na teoria pura de renderização do que naquilo que a rodeia. O Vue traz mais decisões já tomadas, com bibliotecas oficiais de routing e de estado e uma estrutura recomendada, o que tende a encurtar o caminho para a produtividade em equipas pequenas. O desenho do Svelte põe mais ênfase em o passo de build produzir um output mínimo, o que atrai quando o tamanho do payload e o trabalho de arranque são as restrições que realmente se sentem.

A maturidade do ecossistema é o outro fator honesto. O Vue está amplamente implantado há mais tempo, e isso nota-se no volume de bibliotecas, ferramentas e perfis disponíveis para contratar. O ecossistema do Svelte é mais pequeno, o que pesa mais numa aplicação grande e de vida longa do que numa aplicação focada.

O conselho prático não tem glamour: nenhuma das duas escolhas será aquilo que torna a sua interface rápida ou lenta. A estrutura dos componentes, a obtenção de dados, o tratamento de imagens e a quantidade de JavaScript que envia vão dominar. Escolha aquele que a sua equipa se sentirá confortável a manter, e invista a discussão poupada a medir aquilo que realmente carrega.

Stack relacionado