Es el momento adecuado para adoptar una API de plantillas DOM

• La plataforma web se ha consolidado como un runtime de aplicaciones dinámicas, pero el DOM estándar no tiene una API de plantillas declarativa que maneje en conjunto datos, eventos, propiedades, defensa contra XSS y actualizaciones eficientes
• Frameworks modernos como React, Vue, Angular, Lit, Svelte y SolidJS toman como eje central un sistema de plantillas que combina marcado y datos, y eso influye en la legibilidad, la seguridad, el rendimiento, el análisis estático y el renderizado del lado del servidor
• En el pasado, E4X, E4H y la etiqueta literal de plantilla html integrada ayudaron con la creación de DOM, pero no resolvieron la actualización del DOM; ahora, los tagged template literals y la experiencia acumulada en frameworks ofrecen una base para la estandarización
• Una API basada en JavaScript tiene un alcance menor que estandarizar JSX o que una plantilla basada en HTML, y puede convertirse en el objetivo de compilación de transformaciones de JSX para después dar paso a plantillas HTML y elementos personalizados declarativos
• La ruta propuesta se conecta con mecanismos subyacentes como DOM Parts, template identity, Signals y un scheduler del DOM, y podría ofrecer una base común para desarrolladores vanilla, usuarios de Web Components e implementadores de frameworks

---

Una capa de plantillas declarativa que falta en el DOM estándar

• La plataforma web es el runtime de aplicaciones más exitoso de la historia, y la API del DOM es la base que convirtió a un visor de documentos estáticos en un runtime dinámico y expresivo
• Incluso aplicaciones complejas como Photoshop se ofrecen como apps web, y el DOM es una API lo bastante potente como para construir interfaces completas con Web Components
• Aun así, la API estándar actual del DOM no ofrece una forma cómoda de resolver de una sola vez las siguientes tareas
  • Crear fragmentos de nodos DOM a partir de datos
  • Agregar event listeners
  • Establecer propiedades de elementos
  • Garantizar seguridad frente a ataques XSS
  • Actualizar eficientemente esos fragmentos del DOM con datos nuevos

Los frameworks ya demostraron el valor de las plantillas

• Los frameworks web modernos y las bibliotecas de renderizado usan como función central plantillas que combinan de forma declarativa el marcado y los datos
  • Esto incluye React, Vue, Angular, Preact, Lit, Svelte, SolidJS, Stencil, Quik, Ember, FAST, Polymer y Marko
• Las plantillas declarativas son más cómodas de escribir y leer que la API imperativa del DOM
  • La interpolación, los event listeners y la asignación de propiedades quedan cerca de la plantilla, por lo que es más fácil mantener la localidad del comportamiento
• Los sistemas de plantillas pueden escapar automáticamente los valores interpolados, lo que ayuda en la defensa contra XSS
• Un buen sistema de plantillas puede actualizar solo el DOM que cambió y ser más rápido que la mayoría del código escrito a mano
• Muchos sistemas de plantillas admiten análisis estático como verificación de tipos y autocompletado
• Las definiciones declarativas de plantillas pueden interpretarse fuera del entorno completo del navegador, lo que permite un renderizado del lado del servidor eficiente

El costo de no tener plantillas

• La plataforma todavía no cubre de forma directa un requisito central de casi todas las aplicaciones web
  • Igual que las APIs de internacionalización, Temporal, Scheduler o Sanitizer, las plantillas merecen tratarse como una capacidad estándar de la plataforma
• Los usuarios terminan afectados por el tiempo de descarga de la app, la sobrecarga de renderizado y las aplicaciones con seguridad débil
  • El código de una biblioteca de plantillas puede ir desde unos pocos kB en el mejor caso hasta más de 100 kB en el peor
  • Incluso unos pocos kB pueden representar una parte importante del presupuesto de renderizado interactivo inicial
• Los desarrolladores tienen que depender de bibliotecas, npm y CDNs incluso para tareas básicas
  • Se reduce la utilidad de los archivos estáticos simples y de DevTools
  • No existe un conocimiento base de plantillas portable entre stacks
  • Las APIs nativas de creación de DOM como innerHTML no son seguras por defecto
• Los frameworks y bibliotecas de plantillas tienen que hacer concesiones difíciles entre facilidad de escritura, velocidad de renderizado, velocidad de actualización, seguridad y tamaño del código
• La plataforma web compite con plataformas nativas como Flutter, SwiftUI y Jetpack Compose
  • Esas plataformas integran sistemas parecidos a plantillas, usan instalación de apps y lenguajes compilados, y son menos sensibles a bundles de unos pocos kB

Por qué ahora sí vale la pena intentarlo de nuevo

• Antes ya hubo propuestas de plataforma cercanas a las plantillas
  • E4X estuvo incluido de verdad en Firefox y Flash
  • E4H fue una idea simplificada por Ian Hixie
  • Hacia 2012 también hubo prototipos de una etiqueta literal de plantilla html integrada
• Los intentos anteriores ayudaban con la creación de DOM, pero no con la actualización, así que era difícil que fueran una solución suficiente
• Hoy los frameworks ya generaron suficientes casos de uso, y las soluciones de plantillas en espacio de usuario se parecen cada vez más entre sí
• También existe demanda de manipulación cómoda del DOM y APIs reactivas entre desarrolladores que no usan frameworks y dentro de la comunidad de Web Components
• Están avanzando propuestas de primitivas de bajo nivel para actualizar el DOM, como DOM Parts
  • Una API de plantillas declarativa de más alto nivel podría reducir la carga de implementación de los frameworks y validar o complementar las propuestas de APIs de bajo nivel

El mínimo común en sintaxis y semántica

• La mayoría de los sistemas populares de plantillas del lado del cliente comparten una estructura que combina marcado y bindings
  • Los delimitadores de expresiones, el control de flujo y los indicadores del tipo de binding varían un poco, pero las similitudes son mayores
  • Hay parecidos incluso entre Vue, Angular y Svelte basados en HTML, y React, Lit y Solid basados en JavaScript
• En una API basada en JavaScript, la plantilla suele ser una expresión; la composición se logra anidando o referenciando expresiones de plantilla, y el control de flujo queda en manos de JavaScript
• Muchos sistemas basados en APIs de JavaScript devuelven una descripción del DOM desde una expresión de plantilla y luego la aplican con una llamada separada a render
  • La mayoría actualiza el DOM con la misma llamada a render
  • Algunos evitan ese enfoque con reactividad de grano fino
• E4X y E4H agregaban nueva sintaxis para poner marcado dentro de JavaScript, como JSX, pero devolvían fragmentos de DOM reales en lugar de una descripción del DOM
  • Eran buenos para la creación inicial del DOM, pero la actualización seguía siendo imperativa

Una API que puede expresarse con el JavaScript de hoy

• JavaScript ya tiene tagged template literals para DSL embebidos como HTML
• Es posible expresar plantillas en una API del DOM sin agregar nueva sintaxis a JavaScript
• Las bibliotecas populares demuestran que este enfoque funciona bien
• Poder avanzar la propuesta sin nueva sintaxis es importante para la viabilidad de la estandarización

La relación entre JSX y una API de plantillas nativa

• Los tagged template literals son una función poderosa de ES2015, pero en sistemas de componentes de espacio de usuario tienen más sobrecarga sintáctica que JSX
• JSX es popular, pero solo tiene sintaxis y no semántica de runtime
  • Para estandarizarlo, no basta con agregar nueva sintaxis; también habría que definir su semántica
  • Queda descartado tratarlo como llamadas a createElement() definidas alrededor
  • Construir árboles de objetos puede mezclar partes estáticas y dinámicas, impidiendo patrones de actualización más eficientes
• Si la propuesta de Records and Tuples hubiera avanzado, JSX podría haber terminado creando Records boxed, pero esa propuesta está estancada, sobre todo en identity de records y la parte de boxes
• Para comprobar si una sintaxis y semántica tipo JSX sirven para plantillas DOM completas, hace falta un sistema de plantillas objetivo
  • La plantilla de React no ofrece una forma explícita de hacer binding a propiedades y eventos de elementos ni de aplicar directivas a elementos
• Como el JSX no estándar actual es sintaxis pura sin semántica de runtime, es posible crear compiladores que lo transformen a tagged template literals
  • Ya existen casos como JSX-to-Lit
  • Una API de plantillas nativa puede convertirse en el objetivo de compilación para que los desarrolladores elijan la sintaxis que prefieran

Por qué mirar primero una API de JavaScript antes que plantillas basadas en HTML

• Muchos desarrolladores web quieren un sistema de plantillas basado en HTML con todas las funciones
  • Hay demanda en la comunidad de usuarios de Web Components, usuarios de frameworks y desarrolladores vanilla
  • También hay quienes esperaban que <template>, declarative shadow DOM y Web Components ofrecieran esa capacidad
• Las plantillas basadas en HTML son un trabajo mucho más grande que una API basada en JavaScript
  • Sintaxis de binding
  • Lenguaje de expresiones
  • Sintaxis de control de flujo
  • Mecanismo de actualización de plantillas
• Tampoco existe una forma nativa de cargar definiciones de plantillas basadas en HTML
  • HTML Imports de Web Components v0 desapareció y HTML Modules aún no existe
  • Si de todos modos hubiera que poner plantillas HTML dentro de módulos JavaScript, entonces tiene más sentido usar expresiones de JavaScript en el mismo alcance léxico que los datos
• Polymer 3 movió las plantillas HTML de Polymer 2 a JavaScript, y eso llevó directamente a Lit
  • Dejar que JavaScript se encargara de ese trabajo “de script” redujo el código y mejoró la experiencia
• Una API de JavaScript puede ser un subconjunto y a la vez una base para una API basada en HTML
  • Si la API de JavaScript se adopta y valida, la API HTML quedaría como la tarea de definir bindings, expresiones, control de flujo y sistema de módulos

Opciones para el modelo de reactividad

• Las primeras propuestas de plantillas DOM no incluían actualización, pero los sistemas en espacio de usuario ya exploraron bastante los modelos de reactividad y sus enfoques de implementación
• Las aproximaciones reactivas más representativas pueden agruparse en tres
  • VDOM y diffing de React
  • template identity de Lit
  • Signals y reactividad de grano fino, usados en Solid, Svelte, Vue, Angular y otros
• El diffing es fácil de entender y funciona con cualquier dato, pero es más lento que otros enfoques
  • Las diferencias entre algoritmos de diffing pueden ser observables
  • Es difícil estandarizar un único algoritmo de diffing y además pedir a los ingenieros de plataforma que acepten esa sobrecarga
• Template identity actualiza si el DOM actual fue renderizado por la misma plantilla; si no, lo reemplaza
  • Es rápido y en muchos casos de uso produce resultados muy parecidos al diffing
  • Encaja bien con tagged template literals, transformaciones de JSX y plantillas basadas en HTML
  • Su semántica es simple y fácil de especificar
• Signals es un modelo que podría incluirse en nuevas APIs reactivas del DOM y de plantillas
  • Existe una propuesta de JavaScript Signals, pero todavía no es una capacidad nativa de la plataforma ni está garantizada su adopción
  • Los sistemas basados en Signals funcionan mejor cuando todos los datos se envuelven en signals
  • Como también hay datos que no son signal y APIs de plataforma que no crean signals, volver a renderizar es una forma sencilla de reflejar esos cambios
• Template identity y Signals pueden coexistir
  • Una plantilla a la que solo se le pasen signals en sus bindings puede actualizarse únicamente con signals, sin rerender
  • Una plantilla que pueda referenciar datos que no son signal sí necesita rerenderizarse
  • Normalmente ese rerender lo hace automáticamente una capa de componente o framework, por ejemplo con propiedades reactivas de componentes

Discusión de estandarización y tareas pendientes

• La discusión sobre una API nativa de plantillas declarativas en JavaScript comenzó en WICG webcomponents#1069
• Esta API podría ser el siguiente paso lógico de las APIs de creación de DOM
  • Sería una primitiva de creación de DOM segura y fácil de escribir para desarrolladores web vanilla
  • Sería útil de inmediato para bibliotecas existentes de Web Components como Lit, FAST y HyperElement
  • Sería útil para usuarios de la API cruda de Web Components y serviría de base hacia una API más completa de definición de componentes reactivos
  • Podrían construirse nuevos frameworks sobre esta API
  • Los frameworks existentes podrían usarla como objetivo de compilación, backend de runtime o soporte directo
  • Sería útil tanto para técnicas de rerender como para Signals
  • Serviría de base para plantillas HTML declarativas y elementos personalizados declarativos
  • La superficie de API que habría que consensuar y especificar es relativamente pequeña
  • Ayudaría a definir la semántica de las plantillas
• Este trabajo está vinculado con la finalización de la propuesta DOM Parts
  • También contribuiría a definir DOM Parts y demostrar su utilidad
• Aunque la API expuesta y la sintaxis no son grandes, el espacio de comportamiento y la API subyacente de DOM Parts sí lo son
• La reactividad de grano fino también necesita alguna forma de scheduler del DOM
• Hay muchas cosas por decidir, consensuar, especificar y probar, así que hace falta colaboración
• Los desarrolladores interesados pueden dejar comentarios en webcomponents#1069 o contactar por Bluesky

[GN⁺]

Opiniones de Hacker News

• Decir “sabemos cómo es una buena sintaxis para plantillas” da risa. Creo que todavía no lo sabemos en absoluto. Una buena plantilla casi seguro se parece más a una herramienta visual que a una sintaxis simbólica; por eso tuvieron éxito herramientas como el viejo Dreamweaver y por eso los diseñadores aprenden con herramientas como Photoshop.
  Además, es una lástima porque parece un intento de volver a crear XSLT. Alguien inevitablemente va a querer crear plantillas a partir de fragmentos que no son well-formed y que, al combinarse, producen algo well-formed. Lo mismo aplica a entidades dentro de una página que están conectadas entre sí, pero no están en el mismo árbol. Un ejemplo sencillo en el marcado común son label y for.
  Si fuera posible, me gustaría que hubiera menos intentos de forzar todas las plantillas para que encajen en ese artilugio de Rube Goldberg que es el layout estándar de documentos en el marcado. La gente toma caminos absurdamente complejos para reproducir cosas que funcionan bastante bien usando posicionamiento absoluto con cuidado. Puede que haya que hacer cálculos para encajar las cosas, pero no veo por qué habría que obligar a la máquina a repetir esos cálculos una y otra vez para los mismos datos.

  • Nunca me gustó XML, pero creo que XSLT fue, y sigue siendo, la killer feature que podía salvar ese ecosistema. Todavía tiene soporte amplio en los navegadores.
    Es una lástima que XML se haya puesto de moda en lugares inadecuados, como configuración o comunicación entre procesos, pero se haya marchitado justo donde podía brillar: como lenguaje de marcado con una excelente capacidad de transformación llamada XSLT.
    Creo que el punto donde XSLT se vino abajo fue que era un DSL de verdad, y además un DSL declarativo, puro y funcional. La gente habla maravillas de los DSL, pero en la práctica muchas veces se quedan en simples juegos de sintaxis que no logran abstraer la semántica procedimental de un lenguaje anfitrión popular. Cuando se encuentran con un DSL bien diseñado que vuelve triviales tareas difíciles, la gente no quiere aprenderlo.
  • No sé cómo llegaste a esa conclusión. Lo que dices parece más una queja general sobre HTML+CSS que sobre una forma de generar plantillas.
    Y tampoco entiendo por qué aparece el posicionamiento absoluto. Veo este tema repetirse en HN; claro que el posicionamiento absoluto tiene usos y en muchos casos es necesario.
    Pero cuando se usa para el layout de una página o una app, por experiencia, casi siempre fue una pesadilla que se rompía apenas cambiaba un poco el contenido o el tamaño de la pantalla. Ni siquiera el layout de un periódico impreso puede hacerse así, porque la tipografía también está involucrada.
    Cuando trabajaba mucho con CSS, si me tocaba continuar sobre un layout “casi listo” que alguien había hecho con posicionamiento absoluto, arreglarlo llevaba muchísimo tiempo, y siempre era más rápido rehacerlo con flex o con el flujo normal. Usar posicionamiento absoluto como herramienta principal de layout hacía que el problema fuera prácticamente imposible de corregir.
    Puede que haya técnicas razonables usando calc() y unidades de viewport, pero por experiencia, salvo que el contenido y el tamaño del viewport sean completamente estáticos, el posicionamiento absoluto no es adecuado para layout.
  • En la web existe el requisito de que un documento se vea bien en cualquier tamaño, relación de aspecto, orientación y capacidad del dispositivo. Las apps normales, por ejemplo las de Windows, no tienen ese requisito, y las apps móviles tienen algunos tamaños estandarizados. Solo la web tiene ambos.
  • Creo que entre React y Svelte solo hay similitudes superficiales. Ambos usan una sintaxis muy basada en HTML, pero funcionan de formas muy distintas.
    React es, en general, el único framework importante que funciona haciendo que funciones JavaScript comunes devuelvan una representación diferida de marcado en forma de JSX. React no tiene conceptos de repetición o renderizado condicional a nivel de plantilla; eso se maneja con JavaScript común.
  • Burlarse frente a alguien que defiende el avance de la plataforma web no es una actitud muy buena. Ese avance beneficia a todos.
    Y creo que ahora sí sabemos cómo es una buena sintaxis de plantillas. Básicamente es JSX. Lo digo incluso aunque React no me guste mucho. JSX arrasó en toda la web y se adaptó a varios frameworks, y es difícil negar que los sistemas de plantillas de JavaScript convergieron en rasgos comunes: tratar las plantillas como expresiones, componerlas mediante anidación y manejar el flujo de control con el propio JavaScript en lugar de con una sintaxis específica de plantillas.

• La lección básica aprendida una y otra vez es que API/ABI no son un estado final. Las necesidades de las aplicaciones no quedan satisfechas para siempre con una sola API estable, y tampoco se pueden relegar todos los problemas futuros al nivel de la app.
  Esta propuesta muestra bien el proceso en el que un problema común de la plataforma se resuelve en una capa superior como React y, cuando finalmente se reconoce como problema, baja de nivel. Los polyfills son otro ejemplo de lo mismo.
  Cuando una propuesta así tiene éxito, recibe atención por un tiempo, pero durante la mayor parte de su vida útil termina convirtiéndose en algo viejo que la gente intenta esquivar. Eso pasó con las API del DOM, las versiones de ECMA, los navegadores antiguos y toda tecnología útil que, por formar parte del sistema, ya no se puede tocar.
  ¿No podríamos pensar en entropía, expansión y compatibilidad hacia atrás como casos de uso principales?

  • Cada función de los estándares web es código adicional que hay que mantener con cuidado, y también código adicional que cualquiera que quiera crear un navegador compatible con los estándares debe implementar. Me gustaría que proyectos como https://servo.org/ tuvieran la oportunidad de ponerse al día con el tiempo, no que solo persiguieran un alcance que no deja de crecer.
    Quiero que la plataforma web tenga todas las capacidades posibles de las plataformas nativas. Por supuesto, respetando las restricciones de privacidad y sandboxing. Y también quiero que la experiencia de desarrollo de los desarrolladores web sea excelente.
    Pero eso debe equilibrarse con las consecuencias del aumento de complejidad. En este caso, no estoy seguro de que las plantillas nativas realmente mejoren la experiencia de desarrollo. No parece que el beneficio supere el costo.
  • Creo que getElementById ha sido estable por unos 25 años. Decir “no existe tal cosa como una API estable” es algo que dicen personas que no tienen la capacidad o la voluntad de crear interfaces duraderas. No es una ley del universo; se parece más a una resignación personal. Hay muchísimos contraejemplos.
    Las necesidades de las aplicaciones son infinitas, como cualquier otra necesidad. Esas necesidades se satisfacen no rompiendo API que funcionan, sino agregando nuevas API.
  • En la web, API/ABI sí son un estado final. Una vez que algo se expone en la web, alguien dependerá de esa forma exacta para siempre.
    Por eso todavía hay API que, por decisiones de hace 20 años, terminan metidas en situaciones como smooshgate: https://developer.chrome.com/blog/smooshgate
  • En ese proceso, la funcionalidad básica sube otro escalón. El hecho de que las necesidades del espacio de usuario siempre encuentren nuevos huecos, casos de uso y puntos ciegos no hace que las actualizaciones incrementales pierdan valor.
  • ¿No es por eso que se versiona, se mantiene la compatibilidad hacia atrás con versiones anteriores y no se cambian las interfaces “viejas”?

• La web realmente necesita plantillas nativas, reactividad y data binding. Ni me imagino cuánto CPU y ancho de banda se desperdician cuando miles de millones de usuarios descargan, parsean y ejecutan cosas como React.

  • Ahora que tenemos LLM y criptomonedas, ese desperdicio parece muy pequeño.
  • Parte de eso está avanzando con la propuesta Signals de TC39.
  • Para la mayoría, algo como data binding bidireccional y una copia de JSX sería suficiente.
  • ¿No es difícil considerar a React como una plantilla?

• La parte de Signals dice mucho y muestra bien que la idea es excelente, pero en la práctica es difícil.
  Entiendo por qué al autor le gustan Signals. Cualquier proyecto suficientemente grande tiene un árbol de cómputo DAG a medio hacer, y tiene sentido que el lenguaje estandarice uno.
  Pero este tipo de abstracción tiene un costo cognitivo y de implementación alto.
  Como en la mayor parte de la ingeniería, el problema son los compromisos. El modelo de React actualiza el estado global y vuelve a renderizar todo, así que es lento, pero fácil de entender. El modelo de Signals es rápido, pero exige demasiado esfuerzo.
  La mayoría de las apps no necesitan ser extremadamente rápidas, y la gente elegirá el React más simple.
  Pero Signals no tiene mucho que ver con las plantillas, ¿no? Entonces, ¿por qué habría que elegir? ¿No se podrían tener plantillas y Signals por separado?
  Cuando uno piensa en plantillas, termina necesitando una forma de decirle al DOM dónde insertar los nodos de plantilla y cómo actualizarlos cuando cambien. Justo en ese punto fallan estas propuestas.
  Aquí la API tiene que elegir un lado. Técnicamente podría permitir ambos, pero sería horrible. Los desarrolladores nunca se pondrán de acuerdo sobre cuál debería ser.
  El gran problema de la UI siempre fue no cómo definirla, sino cómo actualizarla. Microsoft intentó definir muchos modelos, como MVC, MVP, MVVM, y fracasó; todos fueron dolorosos. Luego imgui dijo: “¿y si la UI no tuviera estado en absoluto?”, y eso es bastante bueno, pero carga mucho la CPU.
  Tal vez una de las mayores razones del éxito de las apps web sea que el DOM no impuso una forma de vincular los datos con la vista. Por eso quizá nos resulte difícil salir del infierno de frameworks.

  • Hoy ya hay varios frameworks que hacen bien el diffing fino sin depender de Signals, proxies u otros primitivos reactivos. Básicamente siguen el modelo de React de arriba hacia abajo, pero son mucho más rápidos y no tienen conceptos raros como hooks ni arrays de dependencias manuales y derrochadores.
    Personalmente me gusta ivi-js: https://github.com/localvoid/ivi
    Es apenas 8% más lento que el JavaScript vanilla más rápido, más feo, imperativo e imposible de mantener al que se puede llegar si el único objetivo es ganar benchmarks.
    https://krausest.github.io/js-framework-benchmark/2025/table...
  • Microsoft usó esos modelos en distintas épocas, pero el único que definió directamente fue MVVM. MVC vino de Xerox PARC y MVP de Taligent.
  • Como desarrollador, estaría dispuesto a elegir la opción que sea más fácil para el hardware, el ancho de banda y el planeta, aunque sea un poco más difícil para la cabeza de los desarrolladores.
    Más que decir que la mayoría de las apps no necesitan ser extremadamente rápidas, me gustaría que se reconociera más que las apps deben ser ligeras.
    Estoy de acuerdo en que la gente elige React porque es más simple, pero precisamente por eso React no me gusta.

• En lugar de adoptar JSX, me gustaría que se acercara más a la forma en que Kotlin ofrece una sintaxis generalizada para DSL con receptores y builders, y que esa sintaxis también encaja bien para expresar jerarquías de componentes.
  Sería ampliamente útil no solo para plantillas HTML, sino también para expresar configuración y varios tipos de estructuras.
  La semántica real de las plantillas y el data binding podría quedar en un conjunto estándar de funciones que usen esas capacidades sintácticas, como se ve en Jetpack Compose.

  • Tampoco se necesita mucho. Bastan iteración, condicionales para atributos y condicionales para nodos. De hecho, eso podría incluso ser una capacidad común entre lenguajes.

• También es importante que este artículo lo haya escrito una de las personas con más experiencia en esta área. Es uno de los principales autores de Lit / Polymer, trabajó en Web Components en Google y contribuyó a especificaciones clave del DOM que pasaron a formar parte de la plataforma web.

  • Más bien lo veo como una de las personas que creó muchos más problemas de los que resolvió al empujar imprudentemente especificaciones a medio cocinar. Impulsó una “solución” que exigía más de 20 nuevas especificaciones web apenas para intentar ponerse al día con lo que el espacio de usuario ya estaba haciendo, e ignoró o hizo gaslighting a quienes no estaban 100% de acuerdo.
    Safari viene sosteniendo desde hace 15 años que aquí debería haber un enfoque declarativo.

• Me pregunto si hay alguien más a quien las plantillas declarativas le parezcan, de hecho, peores que jQuery. He usado React durante casi 10 años, pero cuanto más compleja se vuelve una SPA, más ganas me dan de controlar el DOM directamente de forma imperativa.
  La razón es que el DOM es una abstracción con fugas y, en cierto nivel, siento que un modelo donde la última escritura gana funciona mejor.
  Entiendo que las plantillas declarativas intentan encargarse de eso, pero cuando empiezas a compartir estado mutable entre componentes, este enfoque se rompe muy rápido.

  • La gente de React tiende a ver llamar directamente a la API del DOM como un pecado capital. A veces está bien tomar un ref y, me atrevo a decirlo, encontrar un componente por id y manejarlo directamente. De hecho, las bibliotecas que son “rápidas” y rerenderizan poco, como las de formularios, hacen eso.
  • No me gusta React, pero no estoy de acuerdo con esa sensación. Para empezar, ya puedes salirte del DOM declarativo y hacer lo que quieras con innerHTML y ref.
    En segundo lugar, no sé qué cosas se pueden hacer de forma menos engorrosa controlando el DOM imperativamente que de forma declarativa. Solo se me ocurren métodos específicos como attachShadow() y showModal(), pero incluso eso se puede envolver en un componente de 10 líneas y volverlo declarativo.
  • Totalmente de acuerdo. Todavía no he visto ni un solo ejemplo que me convenza de que algo como React sea aunque sea un poco mejor que usar HTML separado y jQuery.

• Según entiendo, Ryan Carniato y Solid JS todavía están explorando lo que se puede hacer con Signals. No creo que la exploración en el espacio de usuario de esta área haya terminado por completo, y podría haber más innovación.

  • Fuera de la burbuja del desarrollo web también hay mucha investigación interesante sobre el área de problemas de cómputo incremental, y el cómputo autoajustable —es decir, incluso Signals— ni siquiera es un eje particularmente interesante.

• Me gusta la dirección, pero antes de eso creo que deberían llegar primero al navegador algunas API de más bajo nivel.
  Será casi imposible que todos se pongan de acuerdo en un sistema estándar de plantillas. En cambio, lo que el navegador sí puede hacer es ofrecer una API de bajo nivel que aplique diferencias al DOM de forma nativa y con buen rendimiento.
  Sería genial tener algo así de forma nativa en el navegador:
  element.applyDiff(DocumentFragment | string, { method: 'innerHTML' | 'outerHTML' })
  Este enfoque podría aplicar diferencias de una forma menos intrusiva, manteniendo el foco de los elementos, los valores de entrada, el estado de reproductores de audio y video, cambiando atributos, etc. Bibliotecas JavaScript como Idiomorph hacen este tipo de cosas, pero una solución nativa probablemente sería mucho más rápida.

  • En el artículo hay un enlace a la propuesta de DOM part, que podría convertirse en una API de bajo nivel útil. No encajaría bien con frameworks basados en VDOM, pero en otros frameworks podría simplificar su funcionamiento y aumentar las oportunidades de optimización.
    También sería útil para proyectos sin framework, y especialmente más si se adopta además la propuesta de Signals.

• La propuesta de Records and Tuples no solo está estancada, sino que fue retirada. https://github.com/tc39/proposal-record-tuple/issues/394
  Su lugar lo tomó https://github.com/tc39/proposal-composites.