Rich Harris, editor gráfico del New York Times y participante en el desarrollo de Ractive.js, creó Svelte con una motivación clara: los sitios de noticias no necesitan frameworks superinteractivos, necesitan velocidad extrema y código optimizado. Esta premisa cambió por completo la forma en que pensamos sobre los frameworks de JavaScript y su relación con el DOM.
¿Cómo nació Svelte a partir de Ractive.js?
Antes de Svelte existió Ractive.js, una librería creada por The Guardian para desarrollar interfaces con componentes [0:01]. Ractive contaba con un parser que transformaba estilos, lógica en JavaScript y templates escritos en HTML con sintaxis similar a Handlebars. Todo se convertía en blueprints que luego se renderizaban en el DOM mediante dos estrategias: el virtual DOM para el render general de la aplicación y un parallel DOM que permitía a cada fragmento del DOM hacerse responsable de sí mismo [0:18].
Un dato curioso es que Vue también se inspiró en la sintaxis de Ractive para crear los Vue components [0:36]. Sin embargo, Harris tomó un camino diferente al fundar Svelte, orientándolo a sitios donde el contenido manda por encima de la interactividad.
¿Por qué Svelte no usa el virtual DOM?
La principal característica de Svelte es que no crea intermediarios entre tu código y el DOM [1:05]. A diferencia de React, Angular o Vue, Svelte aprovecha el tiempo de compilación durante la etapa de desarrollo para generar directamente el código ideal que el DOM necesita para renderizarse y actualizarse [1:16].
Esto significa que Svelte funciona como un compilador, no como un runtime framework. El resultado es código altamente optimizado que no arrastra la carga de un virtual DOM en producción. Harris ha sido bastante enfático al señalar que el virtual DOM no es necesariamente la mejor solución, y los argumentos que presenta tienen fundamento técnico sólido [1:30].
¿Para qué tipo de proyectos es ideal Svelte?
Svelte brilla en sitios web donde lo importante es el contenido y donde se busca aprovechar al máximo la etapa de desarrollo para producir código bien optimizado [2:07]. Los periódicos digitales son un ejemplo perfecto: aplicaciones gigantes, extremadamente complejas, que deben cargar a la velocidad de la luz.
Sin embargo, donde Svelte no es tan fuerte es en aplicaciones web con interacción intensiva con los usuarios [2:18]. Ese nunca fue su objetivo principal. Algunos detalles que en herramientas como React funcionan de manera fluida pueden no tener el mismo comportamiento en Svelte. Además, al no estar respaldado por una gran empresa, su ritmo de desarrollo y las novedades que ofrece no son tan frecuentes como los de React [2:36].
¿Cómo funciona la arquitectura interna de Svelte?
No existe un recurso oficial que explique a fondo la arquitectura de Svelte, pero gracias al issue 1011 en el repositorio de GitHub, donde Dustin Duess hizo la pregunta y el propio Rich Harris respondió, tenemos información valiosa [2:56].
Como compilador, Svelte necesita generar un AST (abstract syntax tree), una representación en forma de árbol de todo el código de los componentes [3:30]. Para lograrlo utiliza tres parsers distintos:
- Uno para el HTML.
- Otro para el código JavaScript.
- Otro para el CSS.
Svelte combina estos tres árboles y obtiene toda la información necesaria sobre los componentes: sus propiedades, métodos y ciclo de vida [3:43].
En la parte de renderizado, Svelte envuelve el código de cada componente en fragments [3:58]. Un fragment es una interfaz del API del navegador que sirve para encapsular nodos y pequeños fragmentos del DOM sin afectar la interfaz visible de la página. A diferencia de un div o un section, el fragment actúa como un nodo invisible para los usuarios, pero conserva todas las características de un nodo real [4:09]. Esto permite que Svelte pueda crear, actualizar o eliminar elementos del DOM de forma eficiente.
Si te interesa profundizar en cómo los compiladores transforman el desarrollo frontend, comparte en los comentarios qué aspecto de Svelte te parece más innovador.
