Es el momento adecuado para introducir una API de plantillas del DOM

 (justinfagnani.com)
1 puntos por GN⁺ 2025-06-28 | 1 comentarios | Compartir por WhatsApp
  • A la plataforma web actualmente le falta una API de plantillas declarativas que los desarrolladores realmente necesitan
  • Aunque la creación de plantillas es una tecnología central en la mayoría de los frameworks web modernos, la API estándar del DOM no ofrece una forma segura y eficiente de crear y actualizar plantillas
  • Como resultado, se generan incomodidades y problemas de rendimiento para usuarios, desarrolladores, frameworks e incluso la plataforma misma
  • Ya es momento de introducir una API de plantillas, porque la experiencia reciente de los frameworks y las capacidades de JavaScript se han acumulado lo suficiente como para que su implementación y estandarización sean más prácticas
  • Al integrar diversos modelos como la identidad de plantillas y la reactividad basada en señales, se propone una dirección para la próxima generación de APIs de plantillas

Resumen de la propuesta

  • Este artículo explica el contexto y la necesidad de agregar una API de plantillas declarativas a la plataforma web
  • La API del DOM es poderosa, pero en el DOM estándar no existe una API de plantillas para crear y actualizar múltiples nodos de forma segura y eficiente a partir de datos
  • Frameworks principales como React, Vue y Angular tienen la creación declarativa de plantillas como tecnología central, y ofrecen múltiples ventajas en productividad de desarrollo, seguridad, rendimiento, análisis estático y renderizado del lado del servidor
  • Debido a la ausencia de una API de plantillas, usuarios, desarrolladores, frameworks y la propia plataforma enfrentan complejidad innecesaria, amenazas de seguridad, degradación de rendimiento y barreras de entrada
  • Se argumenta que ahora es el momento adecuado para introducir esta API, y se propone una estandarización gradual aprovechando la experiencia acumulada en frameworks existentes y las capacidades modernas de JavaScript

Necesidad de las plantillas y problemas actuales

  • La API del DOM es la base que impulsa las capacidades dinámicas de la plataforma web
  • Sin embargo, en el DOM estándar no existe una forma declarativa de definir de manera segura un árbol DOM a partir de datos y actualizarlo eficientemente
  • Todos los frameworks web modernos (React, Vue, Angular, Svelte, etc.) ofrecen creación declarativa de plantillas
  • Las razones por las que la creación declarativa de plantillas es popular incluyen:
    • Ofrece mejor usabilidad y legibilidad frente a APIs imperativas
    • Refuerza la seguridad contra XSS. Los datos dentro de las plantillas se escapan automáticamente
    • Rendimiento de renderizado eficiente y rápido
    • Aumenta la productividad con análisis estático, verificación de tipos, IntelliSense, etc.
    • Soporte para renderizado del lado del servidor

Problemas de la situación actual

  • Usuarios: la carga inicial se vuelve más lenta por la descarga de librerías y el retraso en el renderizado. El aumento del tamaño del código cliente empeora la UX
  • Desarrolladores: necesitan una librería aparte (npm, CDN, etc.) para usar plantillas. Hay barreras de entrada y dependencia de soluciones no estándar
  • Frameworks: necesitan implementar por su cuenta el motor de plantillas. Existen fuertes compensaciones entre rendimiento, funcionalidades y tamaño del código
  • Plataforma: queda en desventaja al competir con apps nativas. Flutter y SwiftUI, por ejemplo, ofrecen sistemas de plantillas integrados

Por qué ahora es el momento adecuado

  • Intentos pasados relacionados con plantillas (E4X, E4H, literales de plantilla HTML, etc.) fracasaron, pero en ese momento tenían debilidades en la actualización del DOM
  • En los frameworks recientes y en la comunidad ya se han acumulado suficientes mejores prácticas para APIs de plantillas
  • Es posible proponer una API basada en JavaScript. En el estándar actual de JS ya existen los tagged template literals
  • Entre los desarrolladores de JavaScript vanilla y la comunidad de Web Components sigue creciendo la demanda de manipulación conveniente del DOM
  • También avanzan propuestas primitivas de bajo nivel como DOM Parts, pero una API declarativa de alto nivel puede ofrecer mayor utilidad y una dirección de evolución más clara

Análisis de ejemplos de buena sintaxis de plantillas

  • Los sistemas de plantillas dominantes (React-JSX, Vue, Svelte, Angular, etc.) se basan en última instancia en una sintaxis muy similar de marcado + bindings
  • En el caso de APIs de plantillas basadas en JS, lo habitual es que la expresión de plantilla devuelva una descripción del DOM y que una función de render separado la refleje en el DOM real
  • Intentos antiguos como E4X devolvían el propio DOM, por lo que su modelo de actualización era deficiente

Posibilidad de una API de plantillas basada en JavaScript

  • Mediante tagged template literals, es posible diseñar una API de plantillas sin introducir nuevas funciones al lenguaje JS
  • Ya existen varios casos de prueba, como JSX-to-Lit

Discusión sobre la integración con JSX

  • La estandarización de JSX requiere definir semántica compleja y semántica de ejecución. JSX en sí mismo es solo sintaxis
  • El JSX no estándar actual es una transformación puramente sintáctica, por lo que si en el futuro se introduce una API de plantillas estándar, podrá vincularse con compiladores que transformen JSX a template literals
  • Si más adelante se estandariza un JSX real, será fácil migrar hacia una estructura que acepte tipos de datos alineados con la API de plantillas

Relación con una API de plantillas basada en HTML

  • Muchos desarrolladores y comunidades piden un sistema de plantillas basado en HTML
  • Sin embargo, un sistema basado en HTML exige diseñar nueva sintaxis y expresiones para bindings, lenguaje de expresiones, estructuras de control, etc., por lo que es un trabajo mucho mayor
  • La razón por la que frameworks recientes (como Lit) también se movieron de plantillas HTML a una API en JS es la misma
  • Por lo tanto, es más probable que primero se introduzca una API de plantillas basada en JS y que luego pueda ampliarse gradualmente hacia una API HTML

Madurez de la experiencia en implementación de reactividad

  • Ya se han validado diversos modelos de reactividad, como el diffing con VDOM (React), la identidad de plantillas (Lit) y las señales (fine-grained signals, Solid/Svelte/Vue, etc.)
  • El enfoque basado en VDOM es lento, mientras que la combinación de identidad de plantillas + modelo de señales es rápida, eficiente y también más fácil de explicar
  • El enfoque basado en señales requiere envolver todos los datos como señales, aunque también puede mezclarse con datos generales

Ruta de evolución y efectos esperados

  • La API declarativa de plantillas JS propuesta ofrece beneficios directos para JavaScript vanilla, Web Components y nuevos frameworks
  • También puede usarse en frameworks existentes como objetivo de compilación, backend de runtime o API con soporte directo
  • Soporta tanto el enfoque de "rerender" como la reactividad basada en señales
  • Además, sienta las bases para extenderse después a plantillas declarativas basadas en HTML y a custom elements declarativos
    • El alcance del API es acotado y claro, y también facilita la integración con APIs existentes (por ejemplo, DOM Parts)
  • Aun así, aunque la API y la sintaxis en superficie sean simples, el área de implementación subyacente —como DOM Parts y el scheduler— es amplia, y se necesita colaboración para estandarización, pruebas, etc.

Cierre

  • El autor está discutiendo esta propuesta en un issue de GitHub y solicita la participación de la comunidad, incluyendo ingenieros de plataforma

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-06-28
Opiniones de Hacker News

  • La razón por la que me causa risa eso de “sabemos cuál es una buena sintaxis de plantillas” es que, en realidad, ni siquiera se ha llegado a un acuerdo claro sobre ese criterio. Creo que en las plantillas importa más la experiencia visual que la perspectiva simbólica. Por eso herramientas antiguas como Dreamweaver tuvieron tanto éxito. Muchos diseñadores también empiezan a aprender con herramientas como Photoshop por la misma razón. Me da pena que este intento parezca querer recrear XSLT. El problema esencial del templating es combinar una estructura mal hecha para producir un resultado bien hecho. Además, está el problema de representar entidades conectadas, como label y for, que están relacionadas pero no pertenecen al mismo árbol. Si pudiera hacer magia, preferiría que no se intentara forzar todo de manera extraña a encajar en el layout estándar de documentos. Con posicionamiento absoluto (absolute positioning) bien usado se pueden resolver de forma eficiente muchos problemas de UI, y me pregunto por qué se insiste tanto en obligar a la máquina a encargarse repetidamente incluso de todos los cálculos matemáticos

    • Coincido con lo de que parece que quieren volver a crear XSLT. No me gustaba XML en sí, pero XSLT era realmente muy potente. Sigue siendo una funcionalidad ampliamente soportada en los navegadores. XML mostró claramente sus desventajas en configuración (Configuration), IPC y otros casos, pero es una pena que no se haya aprovechado bien la combinación de un excelente lenguaje de marcado con la capacidad de transformación de XSLT. XSLT no se popularizó porque era un DSL verdaderamente declarativo y funcional. Mucha gente habla bien de los DSL, pero en la práctica muchas veces no pasan de ser una capa delgada sobre la semántica procedimental de un lenguaje popular. Con un DSL bien diseñado se pueden resolver cosas complejas de manera sencilla, pero creo que falta disposición para estudiarlo

    • Dices que la clave de una sintaxis de plantillas bien hecha es lo visual, pero me gustaría saber por qué llegaste a esa conclusión. A mí me suena más a una inconformidad con HTML+CSS en sí, es decir, con la forma de generar el resultado. También me da curiosidad por qué mencionas el posicionamiento absoluto. Sin duda es útil donde corresponde, pero para el layout completo termina siendo más difícil de mantener y se rompe fácilmente según el tamaño de pantalla o la cantidad de contenido. Incluso el layout de un periódico tiene muchos matices reales relacionados con el texto y la tipografía, así que no se resuelve solo con posicionamiento absoluto. Cuando se trabaja CSS a fondo, muchas veces me ha pasado que reconstruir después un layout basado en posicionamiento absoluto usando flex o flow resuelve el problema más rápido y más fácil. calc() y las unidades de viewport pueden tener sentido, pero en la práctica, salvo que el contenido o el viewport sean completamente fijos, el posicionamiento absoluto no suele ser adecuado

    • He visto ese argumento de que la gente da demasiadas vueltas para lograr al final el mismo efecto que podría implementarse fácil y rápido con posicionamiento absoluto, pero en la web existe el requisito de que un documento se vea bien según el tamaño, la orientación y el rendimiento de todos los dispositivos. Las apps comunes (como las de Windows) no tienen esta preocupación, y las apps móviles solo necesitan considerar tamaños de pantalla relativamente estandarizados. Solo la web tiene la característica de tener que lidiar con todo eso

    • Reaccionar con sarcasmo a la frase “buena sintaxis de plantillas” no me parece una actitud muy respetuosa hacia quien está proponiendo progreso. Y creo que hoy sí existe una buena sintaxis de plantillas: jsx es el ejemplo más representativo. No soy fan de React, pero creo que jsx revolucionó el desarrollo web, y que la mayoría de los sistemas de plantillas en js han convergido casi todos en “plantillas como expresiones”, “composición por anidación” y una estructura donde el flujo de control se maneja con JavaScript

    • React y Svelte solo se parecen en la superficie; su forma real de funcionar es bastante distinta. En React, la idea central es que una función de JavaScript (casi) normal devuelve marcado diferido (lazy) en forma de JSX. La diferencia clave es que no hay sintaxis propia de plantillas para loops o renderizado condicional: todo se resuelve con JavaScript normal

  • Aprendo una y otra vez que las API y ABI (interfaces binarias de aplicación) nunca son definitivas. Las necesidades de una app no son fijas y cambian con el tiempo, así que no existe una API perfecta que sirva para siempre. Esta propuesta es un buen ejemplo. Primero el problema lo resuelven librerías del espacio de usuario como React, y luego llega el momento en que baja al estándar. Con los polyfills pasa lo mismo. Aunque este tipo de propuestas tenga éxito, al final también envejece y la gente inventa nuevas formas de rodearlas. DOM API, ECMA, navegadores antiguos: todos corren la misma suerte. Esto me hace pensar si la entropía técnica, la extensibilidad y la retrocompatibilidad en sí mismas podrían considerarse casos de uso estándar

    • Agregar nuevas funciones a los estándares web termina generando una carga enorme de código de mantenimiento, y también hace que cada navegador que sigue el estándar tenga que implementar cada vez más código. Proyectos como Servo viven repitiendo una situación en la que, para siquiera acercarse, tienen que perseguir extensiones sin parar. Quisiera que la plataforma web pudiera tener todas las capacidades del entorno nativo, dentro de las restricciones de privacidad y sandbox. También quiero que la experiencia del desarrollador sea excelente. Pero para lograr ese sueño hay que pensar en el costo del aumento de complejidad. Tengo dudas de que el templating nativo que se está discutiendo ahora realmente vaya a mejorar claramente la experiencia del desarrollador

    • Si se mantiene la compatibilidad hacia atrás y no se cambia la interfaz, ¿no es precisamente para eso que existe el versionado?

    • El argumento es que con el tiempo siempre terminamos rodeando o parchando las cosas, pero en ese proceso también hay un efecto positivo: la funcionalidad base sube un nivel. Las actualizaciones graduales siguen valiendo mucho, incluso si las necesidades de los usuarios continúan descubriendo nuevos huecos y casos de uso

    • No estoy de acuerdo con la afirmación de que “las API y ABI nunca son estables para siempre”. Por ejemplo, getElementById se ha mantenido estable por más de 25 años. Decir que una API inmutable es imposible suena más a resignación personal, y en el mundo hay muchísimas excepciones. La demanda no se acaba, así que simplemente se pueden agregar API nuevas. No hace falta romper una API que ya funciona

    • En la web, una vez que una API se publica, siempre habrá usuarios que dependan exactamente de esa forma para toda la vida. Por eso todavía seguimos sintiendo las réplicas de decisiones tomadas hace 20 años. Se puede ver en casos como “smooshgate”

  • Se menciona la moda de la programación reactiva y se argumenta que el espacio de usuario ya ha probado suficientemente esta área, y que ahora se podría crear un sistema estándar real reuniendo lo mejor de distintos enfoques. Pero en lugares como Ryan Carniato/Solid JS todavía se están explorando nuevas posibilidades usando signals, así que no creo que la exploración haya terminado. Todavía hay bastante margen para avanzar

  • La web realmente necesita plantillas nativas, reactividad y data binding. El desperdicio de CPU y ancho de banda que implica que miles de millones de usuarios en todo el mundo descarguen, parseen y ejecuten frameworks pesados como React es difícil de imaginar

    • Comparado con el enorme desperdicio de recursos de los LLM y las operaciones criptográficas, este desperdicio parece poca cosa

    • En TC39 está saliendo una proposal relacionada con signals, y gracias a eso se está avanzando un paso más

    • En realidad, para desarrollar basta con algo como data binding bidireccional y un clon de jsx

    • React no es un sistema de plantillas

  • Al seguir esta discusión sobre introducir un sistema de plantillas de alto nivel en los estándares web, pienso que lo que primero debería ofrecerse son API de bajo nivel integradas en el navegador. Es casi imposible que todos se pongan de acuerdo sobre un sistema de plantillas estándar. En cambio, bastaría con que el navegador ofreciera una API de bajo nivel para aplicar diff al DOM. Por ejemplo, sería bueno tener de forma nativa un método como: element.applyDiff(DocumentFragment | string, { method: 'innerHTML' | 'outerHTML' }). Si se aplica el diff así, se podría actualizar de forma no destructiva conservando el foco actual del element, los valores de input, el estado de audio/video, etc. Existen librerías js como Idiomorph, pero una solución nativa probablemente sería mucho más rápida

    • En el artículo está enlazada la propuesta de DOM parts. Esta propuesta es útil como API de bajo nivel. Puede no encajar muy bien con frameworks basados en VDOM, pero en otros frameworks simplificaría la implementación y ampliaría el margen de optimización. Si además se aplica la proposal de signals, tendría mucha utilidad incluso sin framework

  • Se presenta al autor de este texto como alguien con experiencia de primer nivel en este campo. Ha contribuido enormemente a Lit, Polymer, los web components de Google y varias especificaciones clave del DOM

    • Sin embargo, existe la crítica de que muchas de las especificaciones que esa persona impulsó terminaron creando más problemas. Para una solución superficial que ni siquiera está completamente pulida, hizo falta más de una veintena de especificaciones web, y se estandarizó de una manera demasiado compleja algo que ya era posible en el espacio de usuario. Además, se menciona que Safari venía defendiendo desde hace 15 años la necesidad de un enfoque declarativo, pero fue ignorado

  • En lugar del enfoque de JSX, quiero una aproximación sintáctica como la que Kotlin logró al generalizar los DSL con receiver y builder. Ese tipo de enfoque puede ser muy útil no solo para plantillas HTML simples, sino también para distintas jerarquías de componentes, configuración (config) y muchos otros contextos. El significado real del templating y el data binding al final no es más que un conjunto estándar de funciones que aprovechan esas capacidades sintácticas, algo parecido a Jetpack Compose

    • En realidad, solo hacen falta unas pocas funciones: loop, atributos condicionales, nodos condicionales, etc. De hecho, con una estructura así hasta sería posible usarlo entre distintos lenguajes

  • No siempre me convence que el templating declarativo sea mejor que jQuery. Llevo casi 10 años usando React, pero mientras más complejo se vuelve mi SPA, más extraño el control imperativo del DOM. La abstracción del DOM tiene fugas (leaky abstraction) y al final patrones simples como “last-write-wins” resultan más claros. Se supone que las plantillas declarativas resuelven este tipo de problemas, pero en cuanto se empieza a compartir estado mutable entre componentes, sus límites aparecen demasiado rápido

    • Parte de esa sensación también viene de que la gente del lado de React trata como pecado llamar directamente a la DOM API. Está bien usar ref activamente o buscar y manipular componentes directamente por id. De hecho, librerías de formularios rápidas y con poco rerender funcionan así

    • No me gusta React, pero tampoco creo que haya una barrera para salir del DOM declarativo y usar innerHTML, ref y demás. Con control imperativo se puede, pero en términos prácticos no hay muchas cosas que el enfoque declarativo no pueda hacer. attachShadow() o showModal() también se pueden envolver fácilmente de forma declarativa con unas 10 líneas extra

  • Si la proposal de Records y Tuples hubiera avanzado, JSX podría haber aprovechado esas estructuras para adquirir una nueva semántica, pero en realidad esa proposal no solo se estancó, sino que fue retirada por completo (ver issue). En su lugar fue reemplazada por la proposal de composites

  • Creo que este tipo de discusiones sobre estandarizar funciones de alto nivel deberían detenerse. En su lugar, sería mejor expandir características de nivel inferior y enfocarse en direcciones que aporten más valor a la implementación de librerías de nivel superior. Si una proposal estándar no tiene ventajas claras frente a una librería, no tiene sentido. Pienso que solo debería empezarse a hablar de estandarización cuando algo ya haya sido ampliamente validado durante al menos 5 a 10 años como librería