VanJS – Un framework sin JSX basado en JavaScript puro
Una nueva biblioteca de UI para JavaScript, VanJS, promete interfaces reactivas en menos de 1 KB usando funciones puras en lugar de JSX o un paso de compilación, lo que provoca comparaciones con React, Preact, Solid, Mithril y otros frameworks “mínimos”. Los comentaristas debaten si la optimización extrema del tamaño del bundle sigue teniendo sentido dado el estado de las redes modernas, pero muchos sostienen que menos herramientas, una ejecución más rápida en dispositivos de gama baja y modelos mentales más simples son ventajas reales. El hilo también refleja un cansancio más amplio con la reinvención constante de los stacks front-end, junto con un interés genuino por la reactividad basada en signals, la interoperabilidad y los enfoques que se alejan del DOM virtual y de las canalizaciones de compilación pesadas.
Recepción general y propósito
- Muchos ven VanJS como otra entrada en una larga línea de bibliotecas mínimas de “JavaScript puro reactivo”, al estilo de Xeact, Hyperapp, Arrow, Mithril, etc.
- Algunos son cínicos ante otro framework más, pero otros sostienen que experimentar es valioso y así es como surgieron los principales frameworks de hoy.
- A varios les gusta que sea pequeño, conceptualmente simple y fácil de bifurcar o extender.
Tamaño, rendimiento y costes de red
- Hay un fuerte énfasis en el tamaño inferior a 1 KB; algunos argumentan que el tamaño del framework es insignificante comparado con imágenes/fuentes y que además quedará en caché.
- Otros responden que el tamaño del JS sigue importando, especialmente en dispositivos de gama baja y planes de datos limitados, y que el coste de ejecución, no solo los bytes, afecta a la UX.
- Se citan los propios benchmarks de VanJS para afirmar que supera a React al actualizar localmente sin un DOM virtual.
- Un subhilo señala que incluso añadir pequeñas comodidades (p. ej., constantes de SVG/MathML) se evita deliberadamente para mantener bajos los bytes; algunos elogian esto, otros lo ven como una sobreoptimización.
Sin JSX, sintaxis de vista basada en funciones
- Un tema importante es la ausencia de JSX:
- A quienes les gusta JSX ven su ausencia como un inconveniente; prefieren etiquetas anidadas, al estilo HTML, por legibilidad y claridad estructural.
- Sus detractores consideran JSX una muleta histórica, una sintaxis mal encajada que requiere un paso de compilación, y sostienen que las llamadas a funciones en JS puro son más limpias y evitan herramientas extra.
- Algunos señalan que React puede usarse sin JSX y que la sintaxis de VanJS termina siendo similar a React sin JSX.
- Hay debates extensos que comparan la legibilidad de llamadas a funciones anidadas frente a árboles XML/HTML, sin un consenso claro.
Reactividad, estado y ciclo de vida
- VanJS usa objetos simples “state.val” (similares a signals). Algunos lo encuentran intuitivo y conciso; otros consideran confusa, al principio, la formulación “val debería ser inmutable, pero se establece mediante un setter”.
- Surgen preguntas sobre funciones ausentes: hooks de ciclo de vida (onMount/onCleanup), stores y constructos de control de nivel superior como For/Index/Show.
- Se habla de la obtención asíncrona de datos; VanJS admite una abstracción estilo Await y actualizaciones de estado, pero los patrones idiomáticos no son evidentes de inmediato a partir de los ejemplos de la página principal.
Reflexiones más amplias y alternativas
- Algunos prefieren seguir con herramientas existentes (React, Preact, Solid, Svelte) o pasarse a htmx/LiveView y a lenguajes no JS mediante WASM o compilación a JS.
- Un tema recurrente es el “círculo de frameworks”: las herramientas mínimas van acumulando funciones, se vuelven complejas e inspiran una nueva oleada de reemplazos diminutos como VanJS.