Vue frente a Svelte: ambos usan un compilador, y eso cambia la comparación

  • vuetelemetry
  • Stacks
  • 6 min de lectura

El planteamiento habitual enfrenta el compilador de Svelte con el virtual DOM de Vue. La propia documentación de Vue llama a su enfoque Compiler-Informed Virtual DOM. Que hace realmente cada compilador, y que decide de verdad la elección.

Vue y Svelte suelen presentarse a través de una única oposición: Svelte compila, Vue usa un virtual DOM. Es un resumen cómodo y es engañoso, porque ambos frameworks se apoyan mucho en un compilador. Lo que cambia es lo que produce cada compilador y lo que queda por hacer en el runtime.

Svelte se describe como un framework que usa un compilador para convertir componentes declarativos escritos en HTML, CSS y JavaScript en JavaScript depurado y fuertemente optimizado. El paso de build es el centro del diseño: el trabajo de averiguar qué debe cambiar se empuja lo más lejos posible hacia la compilación.

Vue también compila, y lo dice de forma explicita. Su documentación afirma que el framework controla tanto el compilador como el runtime, lo que le permite implementar optimizaciones en tiempo de compilación que solo un renderer fuertemente acoplado puede aprovechar. Vue llama a este enfoque híbrido el Compiler-Informed Virtual DOM. El virtual DOM sigue ahí, pero el compilador le dice al runtime donde no necesita mirar.

Tres de esas optimizaciones merecen conocerse por su nombre, porque explican por qué comparar 'virtual DOM' con 'sin virtual DOM' no da en el blanco. Static hoisting: el renderer crea los vnodes de las partes inmutables durante el render inicial, los cachea y reutiliza los mismos vnodes en cada re-render posterior. No se vuelve a diferenciar nada que no pueda cambiar.

Patch flags: Vue codifica el tipo de actualización directamente al crear el vnode, de modo que el runtime usa operaciones bitwise para decidir si tiene que hacer un trabajo determinado. No hace preguntas amplias sobre el árbol, comprueba un flag.

Tree flattening: cada bloque hace seguimiento de los nodos descendientes que llevan patch flags, no solo de los hijos directos. Cuando el componente vuelve a renderizarse, el runtime recorre el árbol aplanado en lugar del completo, lo que según la documentación reduce en gran medida el número de nodos recorridos durante la reconciliación.

Leídas en conjunto, esas tres significan que el virtual DOM de Vue no es el diff ingenuo que sugiere la comparación abreviada. El compilador ya ha estrechado el espacio de búsqueda antes de que el runtime empiece a mirar. Es un diseño distinto del de Svelte, pero no es la ausencia de un compilador.

Entonces, donde esta la elección real? Menos en la teoría pura del renderizado que en lo que la rodea. Vue viene con más decisiones ya tomadas, con bibliotecas oficiales de routing y de estado y una estructura recomendada, lo que tiende a acortar el camino hacia la productividad en equipos pequeños. El diseño de Svelte pone más énfasis en que el paso de build produzca una salida mínima, algo atractivo cuando el tamaño del payload y el trabajo de arranque son las restricciones que de verdad notas.

La madurez del ecosistema es el otro factor honesto. Vue lleva más tiempo desplegado de forma amplia, y eso se nota en el volumen de bibliotecas, herramientas y perfiles disponibles para contratar. El ecosistema de Svelte es más pequeño, lo que importa más en una aplicación grande y de larga vida que en una acotada.

El consejo práctico no es lucido: ninguna de las dos elecciones será lo que haga tu interfaz rápida o lenta. La estructura de los componentes, la obtención de datos, el tratamiento de imágenes y cuánto JavaScript envías van a dominar. Elige aquel con el que tu equipo se sienta cómodo manteniendo, y dedica la discusión ahorrada a medir lo que realmente se carga.

Stack relacionado