Tenets

Artículo original ↗ Discusión en Hacker News ↗

Los recién articulados “tenets” de Svelte —priorizar “good vibes”, un diseño centrado en HTML y una experiencia de desarrollador “magical, not magic”— provocan reacciones intensas sobre qué debería optimizar un framework frontend. Quienes lo apoyan elogian Svelte (y a menudo SvelteKit) por devolver la alegría al desarrollo web, ofrecer resultados rápidos y un modelo mental accesible frente a React/Next, mientras que los críticos cuestionan objetivos vagos, no les gusta el DSL y el modelo de reactividad de Svelte, y se preocupan por los cambios de sintaxis en Svelte 5. El intercambio se amplía hacia un debate más general sobre la idoneidad de HTML como lenguaje UI fundamental, las compensaciones entre magia y explicitud, y el valor de ecosistemas fuertemente integrados frente a toolchains combinables por piezas.

Reacción general a los tenets

  • A muchos les gusta ver la filosofía del framework puesta por escrito; aclara por qué disfrutan (o no) usándolo.
  • Algunos sienten que el documento es demasiado vago o suena a marketing y que no añade una visión práctica, aunque estén de acuerdo con muchas de las decisiones subyacentes.
  • Unos pocos lo leen casi como una admisión de que el framework no intenta ser “objetivamente mejor”, sino que simplemente está alineado con su propio gusto.

“Best Vibes” y la experiencia del desarrollador

  • Quienes lo apoyan interpretan “best vibes” como: valores por defecto intuitivos, APIs mínimas, pocas optimizaciones manuales y una comunidad útil, basada en ejemplos.
  • Los críticos llaman al contenido de “good vibes” vacío de significado: podría justificar cualquier compromiso, todos los frameworks afirman tener buena DX, y corre el riesgo de desactivar críticas concretas.

HTML, plantillas y filosofía de UI

  • Un bando ve HTML como la forma natural y nativa del navegador para describir la UI; los frameworks que se mantienen cerca de HTML (plantillas, JSX, sintaxis de Svelte) se consideran más fáciles de razonar y depurar.
  • Otro bando piensa que HTML/DOM es un sustrato de UI profundamente defectuoso, especialmente para aplicaciones complejas y muy interactivas, y lo compara desfavorablemente con toolkits de escritorio, sistemas de restricciones, canvas/WebGL o UIs imperativas.
  • También aparece desacuerdo en torno a “lógica en HTML vs HTML en JS”, la separación de responsabilidades y el valor de los lenguajes de plantillas minimalistas frente a lenguajes de programación completos.

Magia vs explicitud; reactividad

  • La frase “magical, not magic” conecta con quienes quieren que las cosas se sientan fáciles pero sigan siendo comprensibles.
  • Otros se quejan de que la reactividad anterior de Svelte (por ejemplo, las etiquetas $:) ya se sentía demasiado mágica y confusa.
  • Algunos argumentan que la mayoría de los usuarios de React tampoco entiende sus internals, así que las quejas sobre la “magia” de Svelte son inconsistentes.

Svelte 5 y runes

  • El nuevo sistema de runes y la sintaxis $props polarizan:
    • Los fans lo ven como una forma de reducir el comportamiento implícito y alinear la reactividad más estrechamente con patrones estándar de JS.
    • A los detractores no les gustan los nuevos identificadores mágicos, sienten que se aleja de “solo JavaScript”, aumenta la carga cognitiva y hará que Svelte sea más difícil de enseñar; algunos dicen que quizá no adopten Svelte 5.

Comparaciones: React, Vue, Next.js, otros

  • Muchos comentan que Svelte (y a menudo SvelteKit) se siente más ligero, más productivo y “divertido”, especialmente comparado con la complejidad percibida de React/Next.js y la expansión del ecosistema.
  • Algunos prefieren el ecosistema más unificado y la documentación de Vue; otros encuentran Svelte superior a Vue.
  • Hay críticas duras a las direcciones recientes de Next.js (App Router, RSC, comportamiento de cache).
  • Se mencionan alternativas como Astro+Svelte, HTMX más HTML renderizado en servidor y los sistemas clásicos de plantillas como caminos agradables y de menor complejidad.

SvelteKit, tooling y aspectos prácticos

  • SvelteKit recibe opiniones mixtas: a algunos les gusta profesionalmente; otros no soportan sus convenciones de routing (+page files), las limitaciones del backend y la acoplamiento a la estructura de archivos.
  • Aparecen preocupaciones sobre el boilerplate para proyectos simples y sobre el hecho de que el sitio oficial no funcione en versiones antiguas de Safari.
  • Lighthouse se discute como una métrica útil pero imperfecta, que puede manipularse y no debe tratarse como una medida definitiva de rendimiento o accesibilidad.