Es ist der richtige Zeitpunkt, eine DOM-Templating-API einzuführen

• Die Webplattform hat sich als Laufzeitumgebung für dynamische Anwendungen etabliert, aber dem Standard-DOM fehlt eine deklarative Templating-API, die Daten, Events, Properties, XSS-Schutz und effiziente Aktualisierung zusammen behandelt
• Moderne Frameworks wie React, Vue, Angular, Lit, Svelte und SolidJS machen ein Templating-System, das Markup und Daten kombiniert, zum Kernbestandteil; das beeinflusst Lesbarkeit, Sicherheit, Performance, statische Analyse und Server-Side Rendering
• Frühere Ansätze wie E4X, E4H und eingebaute html-Template-Literal-Tags halfen bei der DOM-Erzeugung, lösten aber DOM-Aktualisierung nicht; heute liefern tagged template literals und Framework-Erfahrungen eine Grundlage für Standardisierung
• Eine JavaScript-basierte API ist im Umfang kleiner als die Standardisierung von JSX oder HTML-basierten Templates und kann zum Kompilierungsziel für JSX-Transformationen werden, bevor daraus später HTML-Templates und deklarative Custom Elements folgen
• Der vorgeschlagene Weg greift mit zugrunde liegenden Mechanismen wie DOM Parts, template identity, Signals und einem DOM-Scheduler ineinander und könnte Vanilla-Entwicklern, Web-Components-Nutzern und Framework-Implementierern eine gemeinsame Basis bieten

---

Eine deklarative Template-Schicht, die dem Standard-DOM fehlt

• Die Webplattform ist die erfolgreichste Laufzeitumgebung für Anwendungen der Geschichte, und die DOM-API ist die Grundlage, die einen statischen Dokumentbetrachter in eine dynamische und ausdrucksstarke Laufzeit verwandelt
• Selbst komplexe Apps wie Photoshop werden als Web-Apps angeboten, und das DOM ist leistungsfähig genug, dass ganze UIs mit Web Components gebaut werden
• Allerdings gibt es in der aktuellen Standard-DOM-API keine bequeme Möglichkeit, die folgenden Aufgaben zugleich abzudecken
  • DOM-Knotenfragmente aus Daten erzeugen
  • Event-Listener hinzufügen
  • Element-Properties setzen
  • Sicherheit gegen XSS-Angriffe gewährleisten
  • diese DOM-Fragmente mit neuen Daten effizient aktualisieren

Frameworks haben den Wert von Templates bereits bewiesen

• Moderne Web-Frameworks und Rendering-Bibliotheken nutzen Templates, die Markup und Daten deklarativ verbinden, als Kernfunktion
  • Dazu zählen React, Vue, Angular, Preact, Lit, Svelte, SolidJS, Stencil, Quik, Ember, FAST, Polymer und Marko
• Deklarative Templates lassen sich besser schreiben und lesen als imperative DOM-APIs
  • Interpolation, Event-Listener und das Setzen von Properties liegen nah am Template, wodurch sich Lokalität des Verhaltens leichter bewahren lässt
• Template-Systeme können Interpolationswerte automatisch escapen und sind dadurch beim XSS-Schutz im Vorteil
• Gute Template-Systeme aktualisieren nur das DOM, das sich ändern muss, und können dadurch schneller sein als der meiste handgeschriebene Code
• Viele Template-Systeme unterstützen statische Analyse wie Typprüfung und Autovervollständigung
• Deklarative Template-Definitionen lassen sich auch außerhalb der vollständigen Browserumgebung interpretieren, was effizientes Server-Side Rendering ermöglicht

Die Kosten des fehlenden Templatings

• Die Plattform erfüllt eine Kernanforderung fast aller Webanwendungen bislang nicht direkt
  • Wie Internationalisierungs-APIs, Temporal, Scheduler und Sanitizer sollten auch Templates als Standardfunktion der Plattform behandelt werden
• Nutzer tragen die Folgen in Form von App-Downloadzeit, Rendering-Overhead und schwächer abgesicherten Apps
  • Code für Templating-Bibliotheken kann im besten Fall einige kB, im schlechtesten Fall über 100 kB ausmachen
  • Selbst einige kB können beim Budget für das erste interaktive Rendering stark ins Gewicht fallen
• Entwickler müssen sich selbst für grundlegende Aufgaben auf Bibliotheken, npm und CDNs verlassen
  • Der Nutzen einfacher statischer Dateien und der DevTools nimmt ab
  • Es gibt kein grundlegendes Template-Wissen, das zwischen Stacks portierbar wäre
  • Native DOM-Erzeugungs-APIs wie innerHTML sind standardmäßig nicht sicher
• Frameworks und Templating-Bibliotheken müssen schwierige Kompromisse zwischen Schreibbarkeit, Rendering-Geschwindigkeit, Aktualisierungsgeschwindigkeit, Sicherheit und Codegröße eingehen
• Die Webplattform konkurriert mit nativen Plattformen wie Flutter, SwiftUI und Jetpack Compose
  • Diese Plattformen haben template-ähnliche Systeme eingebaut, nutzen App-Installation und kompilierte Sprachen und sind gegenüber einigen kB Bundle-Größe weniger empfindlich

Warum ein neuer Versuch jetzt möglich ist

• Auch früher gab es bereits plattformnahe Vorschläge für Templates
  • E4X war tatsächlich in Firefox und Flash enthalten
  • E4H war eine von Ian Hixie vereinfachte Idee
  • Um 2012 herum gab es auch einen Prototyp für eingebaute html-Template-Literal-Tags
• Frühere Versuche halfen bei der DOM-Erzeugung, waren aber keine ausreichende Lösung, weil sie Aktualisierung nicht abdeckten
• Inzwischen haben Frameworks genügend Anwendungsfälle geschaffen, und Templating-Lösungen im Userland ähneln sich mit der Zeit immer stärker
• Auch bei Entwicklern ohne Framework und in der Web-Components-Community gibt es Nachfrage nach komfortabler DOM-Manipulation und reaktiven APIs
• Vorschläge für Low-Level-Primitiven zur DOM-Aktualisierung wie DOM Parts sind in Arbeit
  • Eine deklarative Templating-API auf höherer Ebene könnte den Implementierungsaufwand für Frameworks senken und Low-Level-API-Vorschläge validieren und ergänzen

Gemeinsame Schnittmenge bei Syntax und Semantik

• Die meisten populären clientseitigen Templating-Systeme teilen eine Struktur, die Markup und Bindings kombiniert
  • Ausdrucksbegrenzer, Kontrollfluss und Kennzeichnungen für Binding-Typen unterscheiden sich etwas, aber die Gemeinsamkeiten sind größer
  • Es gibt Ähnlichkeiten sowohl zwischen HTML-basierten Systemen wie Vue, Angular und Svelte als auch zwischen JavaScript-basierten Systemen wie React, Lit und Solid
• In JavaScript-basierten APIs sind Templates gewöhnlich Ausdrücke, Komposition erfolgt durch Verschachtelung oder Referenzierung von Template-Ausdrücken, und den Kontrollfluss übernimmt JavaScript
• Viele Systeme auf Basis von JavaScript-APIs geben aus einem Template-Ausdruck eine DOM-Beschreibung zurück und wenden sie anschließend mit einem separaten Aufruf von render an
  • Die meisten aktualisieren das DOM über denselben render-Aufruf
  • Manche vermeiden dieses Muster durch fein granulare Reaktivität
• E4X und E4H fügten wie JSX neue Syntax hinzu, um Markup in JavaScript einzubetten, gaben aber statt einer DOM-Beschreibung direkt DOM-Fragmente zurück
  • Für die anfängliche DOM-Erzeugung war das gut, Aktualisierung blieb jedoch weiterhin imperativ

Eine API, die sich im heutigen JavaScript ausdrücken lässt

• JavaScript hat mit tagged template literals bereits ein eingebettetes DSL für HTML-ähnliche Syntax
• Templates lassen sich in der DOM-API ausdrücken, ohne neue JavaScript-Syntax hinzuzufügen
• Populäre Bibliotheken zeigen, dass dieser Ansatz gut funktioniert
• Dass sich der Vorschlag ohne neue Syntax voranbringen lässt, ist wichtig für seine Realisierbarkeit in der Standardisierung

Das Verhältnis von JSX und einer nativen Template-API

• Tagged template literals sind eine starke Funktion aus ES2015, bringen in Userland-Komponentensystemen aber mehr Syntax-Overhead mit sich als JSX
• JSX ist populär, hat aber nur Syntax und keine Laufzeitsemantik
  • Für eine Standardisierung müsste man mehr tun, als nur neue Syntax hinzuzufügen; die Semantik müsste definiert werden
  • Der Ansatz, es als Aufrufe eines im Umfeld definierten createElement() zu behandeln, scheidet aus
  • Ein Ansatz, der Objektbäume erzeugt, könnte statische und dynamische Teile vermischen und dadurch effizientere Aktualisierungsmuster blockieren
• Wäre der Vorschlag Records and Tuples weitergekommen, hätte JSX vielleicht boxed Records erzeugen können, aber dieser Vorschlag steckt insbesondere bei record identity und dem Box-Konzept fest
• Um zu prüfen, ob Syntax und Semantik im Stil von JSX für vollständiges DOM-Templating geeignet sind, braucht es ein Ziel-Templating-System
  • Das Templating von React bindet nicht explizit an Properties und Events von DOM-Elementen und wendet auch keine Direktiven auf Elemente an
• Da heutiges nicht standardisiertes JSX reine Syntax ohne Laufzeitsemantik ist, kann ein Compiler JSX in tagged template literals umwandeln
  • Beispiele wie JSX-to-Lit gibt es bereits
  • Eine native Templating-API kann zum Kompilierungsziel werden, während Entwickler weiterhin die gewünschte Syntax wählen

Warum zuerst eine JavaScript-API statt HTML-basierten Templates

• Viele Webentwickler wünschen sich ein vollwertiges HTML-basiertes Templating-System
  • In den Communities rund um Web Components, Frameworks und Vanilla-JavaScript besteht Nachfrage
  • Manche Entwickler hatten erwartet, dass <template>, declarative shadow DOM und Web Components so etwas liefern würden
• HTML-basierte Templates sind eine deutlich größere Aufgabe als eine JavaScript-basierte API
  • Binding-Syntax
  • Ausdruckssprache
  • Kontrollfluss-Syntax
  • Mechanismus zur Template-Aktualisierung
• Es gibt auch keine native Möglichkeit, HTML-basierte Template-Definitionen zu laden
  • HTML Imports aus Web Components v0 sind verschwunden, und HTML Modules gibt es noch nicht
  • Wenn HTML-Templates ohnehin in JavaScript-Module eingebettet werden müssten, erscheint es sinnvoller, JavaScript-Ausdrücke im selben lexikalischen Scope wie die Daten zu verwenden
• Polymer 3 hat die HTML-Templates von Polymer 2 nach JavaScript verlagert, was direkt zu Lit führte
  • Es war kompakter und das Nutzungserlebnis besser, JavaScript die script-artigen Aufgaben übernehmen zu lassen
• Eine JavaScript-API kann sowohl Teilmenge als auch Sprungbrett für eine HTML-basierte API sein
  • Sobald eine JavaScript-API eingeführt und validiert ist, bleibt bei einer HTML-API vor allem die Aufgabe, Bindings, Ausdrücke, Kontrollfluss und das Modulsystem zu definieren

Optionen für Reaktivitätsmodelle

• Frühere Vorschläge für DOM-Templates umfassten keine Aktualisierung, aber Userland-Systeme haben Reaktivitätsmodelle und Implementierungsansätze inzwischen umfassend erkundet
• Die wichtigsten Reaktivitätsansätze lassen sich in drei Gruppen zusammenfassen
  • VDOM und Diffing wie bei React
  • template identity wie bei Lit
  • Signals und fein granulare Reaktivität wie bei Solid, Svelte, Vue und Angular
• Diffing ist leicht zu verstehen und funktioniert mit beliebigen Daten, ist aber langsamer als andere Ansätze
  • Unterschiede zwischen Diffing-Algorithmen können beobachtbares Verhalten erzeugen
  • Es ist schwer, einen einzelnen Diffing-Algorithmus zu standardisieren und Plattformingenieure zu überzeugen, den Overhead zu akzeptieren
• Template identity bedeutet: Wenn das DOM mit dem aktuellen Template gerendert wurde, wird es aktualisiert, andernfalls ersetzt
  • Das ist schnell und liefert in vielen Anwendungsfällen Ergebnisse, die Diffing sehr ähnlich sind
  • Es passt gut zu tagged template literals, JSX-Transformationen und HTML-basierten Templates
  • Die Semantik ist einfach und dadurch gut spezifizierbar
• Signals sind ein Modell, das in neue reaktive DOM-APIs und Template-APIs aufgenommen werden könnte
  • Es gibt den Vorschlag JavaScript Signals, aber er ist noch keine native Plattformfunktion und seine Annahme ist nicht garantiert
  • Signal-basierte Systeme funktionieren am besten, wenn alle Daten in Signals gekapselt sind
  • Da es viele nicht-signalbasierte Daten und Plattform-APIs gibt, die keine Signals erzeugen, ist Re-Rendering ein einfacher Weg, solche Änderungen abzubilden
• Template identity und Signals können nebeneinander bestehen
  • Templates, an deren Bindings nur Signals übergeben werden, können ausschließlich über Signals aktualisiert werden, ohne Re-Rendering
  • Templates, die auf nicht-signalbasierte Daten zugreifen können, brauchen Re-Rendering
  • Üblicherweise wird Re-Rendering automatisch von einer Komponenten- oder Framework-Schicht übernommen, etwa durch reaktive Komponenten-Properties

Standardisierungsdiskussion und offene Aufgaben

• Die Diskussion über eine native deklarative JavaScript-Templating-API begann in WICG webcomponents#1069
• Diese API könnte der logische nächste Schritt nach DOM-Erzeugungs-APIs sein
  • Sie wäre ein gut schreibbares und sicheres Primitiv zur DOM-Erzeugung für Vanilla-Webentwickler
  • Sie wäre sofort nützlich für bestehende Web-Components-Bibliotheken wie Lit, FAST und HyperElement
  • Sie wäre nützlich für Nutzer roher Web-Components-APIs und ein Sprungbrett zu einer vollständigeren API zur Definition reaktiver Komponenten
  • Neue Frameworks könnten auf dieser API aufbauen
  • Bestehende Frameworks könnten sie als Kompilierungsziel, Laufzeit-Backend oder direkt unterstütztes Ziel nutzen
  • Sie wäre sowohl für Re-Rendering-Techniken als auch für Signals nützlich
  • Sie wäre ein Sprungbrett zu deklarativen HTML-Templates und deklarativen Custom Elements
  • Die API-Oberfläche, über die Einigkeit erzielt und die spezifiziert werden muss, ist vergleichsweise klein
  • Sie hilft dabei, Template-Semantik zu definieren
• Diese Arbeit hängt auch mit der Fertigstellung des Vorschlags DOM Parts zusammen
  • Sie trägt ebenfalls dazu bei, DOM Parts zu definieren und ihre Nützlichkeit zu belegen
• Die sichtbare API und Syntax sind zwar nicht groß, aber der Verhaltensraum und die zugrunde liegende DOM-Parts-API sind es
• Für fein granulare Reaktivität wird auch irgendeine Form von DOM-Scheduler benötigt
• Es gibt viele Punkte, die entschieden, abgestimmt, spezifiziert und getestet werden müssen, daher ist Zusammenarbeit nötig
• Interessierte Entwickler können in webcomponents#1069 kommentieren oder über Bluesky Kontakt aufnehmen

[GN⁺]

Hacker-News-Kommentare

• Die Aussage, man wisse, „wie eine gute Syntax für Templates aussieht“, ist fast schon zum Lachen. Ich glaube, das wissen wir noch überhaupt nicht. Gute Templates sind ziemlich sicher weniger eine symbolische Syntax als vielmehr ein visuelles Werkzeug; deshalb waren Tools wie früher Dreamweaver erfolgreich, und deshalb lernen Designer mit Werkzeugen wie Photoshop. Außerdem wirkt es leider wie ein Versuch, XSLT neu zu erfinden. Irgendjemand wird am Ende zwangsläufig Fragmente templatieren wollen, die für sich genommen nicht well-formed sind, aber zusammengesetzt etwas Well-formed ergeben. Dasselbe gilt für Entitäten, die innerhalb einer Seite miteinander verbunden sind, aber nicht im selben Baum liegen. Das gewöhnliche Markup mit label und for ist ein einfaches Beispiel. Wenn möglich, würde ich mir wünschen, dass es weniger Versuche gibt, alle Templates in die Rube-Goldberg-Maschine eines Standard-Dokumentlayouts für Markup zu zwängen. Leute gehen absurd komplizierte Wege, um Dinge nachzubilden, die mit vorsichtig eingesetzter absoluter Positionierung ziemlich gut funktionieren. Zum Anpassen braucht es vielleicht Berechnungen, aber ich verstehe nicht, warum man Maschinen zwingen sollte, diese Berechnungen für dieselben Daten immer wieder zu wiederholen.

  • Ich war nie ein Fan von XML, aber XSLT war – und ist meiner Meinung nach immer noch – das Killer-Feature, das dieses Ökosystem hätte retten können. Es wird sogar in Browsern weiterhin breit unterstützt. Schade ist, dass XML zwar an unpassenden Stellen wie Konfiguration und Interprozesskommunikation populär wurde, aber dort verkümmerte, wo es als Markup-Sprache mit der hervorragenden Transformationsfähigkeit von XSLT hätte glänzen können. Der Punkt, an dem XSLT scheiterte, war meiner Ansicht nach, dass es ein echtes DSL ist – und zwar ein deklaratives, reines, funktionales DSL. Leute reden DSLs gern groß, aber in der Praxis sind sie oft nur simple Syntaxspielereien, die die prozedurale Semantik einer populären Host-Sprache nicht abstrahieren können. Wenn sie auf ein gut entworfenes DSL treffen, das schwierige Dinge trivial macht, wollen sie es nicht lernen.
  • Ich weiß nicht, wie du zu diesem Schluss kommst. Was du beschreibst, klingt eher nach Unzufriedenheit mit HTML+CSS insgesamt als nach der Art und Weise, wie Templates erzeugt werden. Und ich frage mich auch, warum hier absolute Positionierung ins Spiel kommt. Ich sehe solche Aussagen auf HN immer wieder; natürlich hat absolute Positionierung ihre Einsatzbereiche und ist in vielen Fällen nötig. Aber wenn man sie für Seiten- oder App-Layouts verwendet, war es meiner Erfahrung nach meistens ein Albtraum, der schon bei kleinen Änderungen am Inhalt oder an der Bildschirmgröße auseinanderfiel. Selbst Layouts gedruckter Zeitungen funktionieren so nicht, weil dort Typografie mit hineinspielt. Als ich viel mit CSS gearbeitet habe und ein Layout übernehmen musste, das jemand mit absoluter Positionierung „fast fertig“ gebaut hatte, hat das Reparieren enorm viel Zeit gekostet; es war immer schneller, es mit flex, normalem Flow oder ähnlichen Ansätzen neu zu bauen. Denn wenn absolute Positionierung als primäres Layout-Werkzeug verwendet wurde, waren die Probleme praktisch nicht mehr sinnvoll zu beheben. Mit calc() und Viewport-Einheiten mag es sinnvolle Techniken geben, aber meiner Erfahrung nach ist absolute Positionierung für Layouts ungeeignet, wenn es sich nicht um vollständig statische Inhalte und Viewport-Größen handelt.
  • Im Web gibt es die Anforderung, dass ein Dokument auf jeder Gerätegröße, in jedem Seitenverhältnis, jeder Ausrichtung und mit unterschiedlichsten Fähigkeiten gut aussehen muss. Normale Apps, etwa Windows-Apps, haben diese Anforderung nicht, und mobile Apps haben einige standardisierte Größen. Nur das Web hat beides.
  • Zwischen React und Svelte sehe ich nur oberflächliche Ähnlichkeiten. Beide verwenden eine stark an HTML angelehnte Syntax, funktionieren aber sehr unterschiedlich. React ist im Großen und Ganzen das einzige große Framework, das so arbeitet, dass normale JavaScript-Funktionen eine verzögerte Darstellung von Markup in Form von JSX zurückgeben. React hat keine Konzepte für Schleifen oder Conditional Rendering auf Template-Ebene; das wird mit normalem JavaScript erledigt.
  • Jemanden auszulachen, der für Fortschritt auf der Web-Plattform eintritt, ist keine besonders gute Haltung. Dieser Fortschritt nützt allen. Und ich glaube, inzwischen wissen wir, was eine gute Template-Syntax ist. Im Grunde ist es JSX. Das kann ich sagen, obwohl ich React nicht besonders mag. JSX hat das gesamte Web erfasst und wurde für verschiedene Frameworks angepasst; schwer zu bestreiten ist auch, dass JavaScript-Template-Systeme auf gemeinsame Eigenschaften konvergiert sind: Templates als Expressions zu behandeln, sie durch Verschachtelung zu komponieren und Control Flow mit JavaScript selbst statt mit einer spezifischen Template-Syntax abzubilden.

• Eine grundlegende Lektion, die man immer wieder gelernt hat, ist: API/ABI ist kein Endzustand. Die Anforderungen von Anwendungen werden nicht dauerhaft durch eine einzige stabile API erfüllt, und man kann auch nicht alle künftigen Probleme auf die App-Ebene abschieben.
  Dieser Vorschlag zeigt gut, wie gemeinsame Probleme der Plattform zunächst in höheren Schichten wie React gelöst werden und dann, sobald sie schließlich als Problem anerkannt sind, nach unten wandern. Polyfills sind ein ähnliches Beispiel.
  Wenn solche Vorschläge erfolgreich sind, bekommen sie kurz Aufmerksamkeit, doch den größten Teil ihrer nützlichen Lebensdauer werden sie zu altem Kram, den Leute zu umgehen versuchen. So war es mit DOM-APIs, ECMA-Versionen, alten Browsern und jeder nützlichen Technik, die Teil eines Systems ist und deshalb nicht angefasst werden kann.
  Könnte man Entropie, Erweiterung und Abwärtskompatibilität nicht als zentrale Use Cases betrachten?

  • Jede Funktion in Webstandards ist zusätzlicher Code, der sorgfältig gepflegt werden muss, und auch zusätzlicher Code, den jeder implementieren muss, der einen standardkonformen Browser bauen will. Ich würde mir wünschen, dass Projekte wie https://servo.org/ im Laufe der Zeit eine Chance bekommen aufzuholen, statt nur einem ständig wachsenden Umfang hinterherzulaufen.
    Ich möchte, dass die Webplattform alle möglichen Fähigkeiten nativer Plattformen bekommt. Natürlich unter Einhaltung von Datenschutz- und Sandboxing-Beschränkungen. Und ich möchte auch, dass die Developer Experience für Webentwickler großartig wird.
    Aber das muss gegen die Folgen zunehmender Komplexität abgewogen werden. In diesem Fall bin ich nicht überzeugt, dass native Templates die Developer Experience wirklich verbessern. Der Nutzen scheint die Kosten nicht zu übersteigen.
  • getElementById ist seit ungefähr 25 Jahren stabil, würde ich sagen. „So etwas wie stabile APIs gibt es nicht“ sagen Leute, die keine dauerhaften Interfaces schaffen können oder wollen. Das ist kein Gesetz des Universums, sondern eher persönliche Resignation. Gegenbeispiele gibt es massenhaft.
    Anforderungen von Anwendungen sind, wie andere Anforderungen auch, unendlich. Man erfüllt sie nicht, indem man funktionierende APIs kaputtmacht, sondern indem man neue APIs hinzufügt.
  • Im Web ist API/ABI tatsächlich ein Endzustand. Sobald etwas im Web öffentlich ist, wird irgendjemand für immer von genau dieser Form abhängen.
    Deshalb gibt es APIs, die uns wegen Entscheidungen von vor 20 Jahren noch heute in Dinge wie smooshgate hineinziehen: https://developer.chrome.com/blog/smooshgate
  • In diesem Prozess rückt die Grundfunktionalität eben wieder eine Stufe nach oben. Inkrementelle Updates werden nicht wertlos, nur weil Anforderungen im Userspace immer neue Lücken, Use Cases und blinde Flecken finden werden.
  • Deshalb versieht man Dinge doch mit Versionen, wahrt Abwärtskompatibilität zu alten Versionen und verändert „alte“ Interfaces nicht, oder?

• Das Web braucht wirklich native Templates, Reaktivität und Data Binding. Man kann sich kaum vorstellen, wie viel CPU und Bandbreite verschwendet werden, weil Milliarden Nutzer Dinge wie React herunterladen, parsen und ausführen.

  • Jetzt, wo es LLMs und Kryptowährungen gibt, wirkt diese Verschwendung ziemlich klein.
  • Mit dem TC39-Vorschlag zu Signals gibt es in Teilen Fortschritte.
  • Bidirektionales Data Binding und eine Art JSX-Klon würden den meisten eigentlich reichen.
  • React kann man doch schwer als Template bezeichnen, oder?

• Der Signals-Teil sagt viel aus und zeigt gut, dass die Idee hervorragend, praktisch aber schwierig ist.
  Ich verstehe, warum der Autor Signals mag. Jedes ausreichend große Projekt hat einen halb selbstgebauten DAG-Berechnungsbaum, und es ergibt Sinn, dass die Sprache einen standardisiert.
  Aber solche Abstraktionen haben hohe kognitive Kosten und Implementierungskosten.
  Wie bei den meisten Engineering-Fragen geht es um Kompromisse. Das React-Modell aktualisiert globalen State und rendert alles neu, ist also langsam, aber im Kopf leicht nachzuvollziehen. Das Signals-Modell ist schnell, erfordert aber zu viel Aufwand.
  Die meisten Apps müssen nicht irrsinnig schnell sein, und die Leute werden das einfachere React wählen.
  Aber Signals haben doch nicht viel mit Templates zu tun. Warum sollte man sich dann dafür entscheiden? Könnte man Templates und Signals nicht getrennt haben?
  Wenn man über Templates nachdenkt, braucht man irgendwann eine Möglichkeit, dem DOM mitzuteilen, wo Template-Nodes eingefügt werden sollen und wie sie bei Änderungen aktualisiert werden. Genau an dieser Stelle scheitern solche Vorschläge.
  Die API muss sich hier für eine Seite entscheiden. Technisch könnte man vielleicht beides erlauben, aber das wäre furchtbar. Entwickler werden sich niemals darauf einigen, welche Seite es sein sollte.
  Das große Problem von UIs war nie, wie man sie definiert, sondern wie man sie aktualisiert. Microsoft versuchte, viele Modelle wie MVC, MVP, MVVM und andere zu definieren, scheiterte daran, und sie waren alle schmerzhaft. Dann kam imgui und fragte: „Was, wenn die UI gar keinen State hat?“ Das ist ziemlich gut, belastet aber die CPU.
  Vielleicht ist einer der größten Gründe für den Erfolg von Web-Apps, dass das DOM nicht vorgeschrieben hat, wie Daten an Views gebunden werden. Deshalb kommen wir aus der Framework-Hölle womöglich nur schwer heraus.

  • Inzwischen gibt es mehrere Frameworks, die feinkörniges Diffing gut beherrschen, ohne auf Signals, Proxys oder andere reaktive Primitive angewiesen zu sein. Im Grunde ist es das von oben nach unten laufende React-Modell, nur viel schneller und ohne seltsame Konzepte wie Hooks oder manuelle, verschwenderische Dependency-Arrays.
    Mein persönlicher Favorit ist ivi-js: https://github.com/localvoid/ivi
    Es ist nur 8 % langsamer als das schnellste, hässlichste, imperative und nicht wartbare Vanilla-JavaScript, bei dem man am Ende landet, wenn man nur Benchmarks gewinnen will.
    https://krausest.github.io/js-framework-benchmark/2025/table...
  • Microsoft hat diese Modelle zwar zu verschiedenen Zeiten verwendet, aber selbst definiert hat es nur MVVM. MVC stammt von Xerox PARC, MVP von Taligent.
  • Auch aus Entwicklersicht würde ich bereitwillig die Seite wählen, die für Hardware, Bandbreite und den Planeten leichter ist, selbst wenn sie für den Kopf der Entwickler etwas anstrengender ist.
    Mehr als die Aussage, dass die meisten Apps nicht irrsinnig schnell sein müssen, würde ich mir wünschen, dass anerkannt wird, dass Apps leichtgewichtig sein sollten.
    Ich stimme zu, dass Leute React wählen, weil es einfacher ist, aber genau aus diesem Grund gefällt mir React nicht.

• Statt JSX zu übernehmen, wäre mir ein Ansatz lieber, der näher daran liegt, wie Kotlin mit Receivern und Buildern eine verallgemeinerte Syntax für DSLs bereitstellt und diese Syntax auch gut zur Darstellung von Komponenten-Hierarchien passt.
  Das wäre nicht nur für HTML-Templates, sondern auch zur Beschreibung von Konfigurationen und vielerlei Strukturen breit nützlich.
  Die eigentliche Semantik von Templates und Data Binding könnte, wie man es bei Jetpack Compose sieht, einfach in einem Standardsatz von Funktionen liegen, die diese Sprachfunktion nutzen.

  • Viel braucht es dafür gar nicht: Wiederholung, Bedingungen für Attribute und Bedingungen für Nodes. Eigentlich ließe sich so etwas sogar als sprachübergreifende gemeinsame Funktionalität umsetzen.

• Wichtig ist auch, dass dieser Text von einer der erfahrensten Personen in diesem Bereich stammt: einem der Hauptautoren von Lit / Polymer, jemandem, der bei Google an Web Components gearbeitet und zu zentralen DOM-Spezifikationen beigetragen hat, die Teil der Webplattform wurden.

  • Ich sehe ihn eher als einen derjenigen, die durch das waghalsige Vorantreiben halbgarer Spezifikationen weit mehr Probleme geschaffen als gelöst haben. Er hat eine „Lösung“ vorangetrieben, die mehr als 20 neue Web-Spezifikationen verlangte, nur um mühsam das nachzubauen, was der Userland-Bereich bereits tat, und hat Leute, die nicht zu 100 % zustimmten, ignoriert oder gaslighted.
    Safari argumentiert schon seit 15 Jahren, dass es dafür einen deklarativen Ansatz geben müsse.

• Ich frage mich, ob noch jemand deklarative Templates eigentlich schlechter findet als jQuery. Ich nutze React seit fast zehn Jahren, aber je komplexer eine SPA wird, desto mehr möchte ich das DOM imperativ direkt steuern.
  Der Grund ist, dass das DOM eine leaky abstraction ist und sich auf einer gewissen Ebene ein „Last write wins“-Modell besser anfühlt.
  Ich verstehe, dass deklarative Templates genau damit umgehen wollen, aber sobald man beginnt, veränderlichen State zwischen Komponenten zu teilen, bricht dieser Ansatz sehr schnell zusammen.

  • Bei React-Leuten gibt es eine Tendenz, direkte Aufrufe der DOM-API als schwere Sünde zu betrachten. Manchmal ist es völlig in Ordnung, sich ein ref zu holen und – ich wage es zu sagen – eine Komponente per id zu finden und direkt zu behandeln. Genau das machen tatsächlich die „schnellen“ Bibliotheken mit wenigen Re-Renderings, zum Beispiel Form-Bibliotheken.
  • Ich mag React nicht besonders, stimme diesem Gefühl aber nicht zu. Erstens kann man sich bereits aus dem deklarativen DOM herausbewegen und mit innerHTML und ref nach Belieben arbeiten.
    Zweitens ist mir nicht klar, welche Dinge sich mit imperativer DOM-Steuerung weniger umständlich erledigen lassen als deklarativ. Mir fallen nur bestimmte Methoden wie attachShadow() oder showModal() ein, aber auch die kann man in eine 10-Zeilen-Komponente kapseln und deklarativ machen.
  • Stimme völlig zu. Ich habe noch kein einziges Beispiel gesehen, das mich davon überzeugt hätte, dass etwas wie React auch nur ein bisschen besser ist als separates HTML plus jQuery.

• Soweit ich weiß, erkunden Ryan Carniato und Solid JS noch immer, was mit Signals möglich ist. Ich sehe die Erkundung im Userland in diesem Bereich nicht als abgeschlossen an; weitere Innovation könnte durchaus möglich sein.

  • Auch außerhalb der Webentwicklungs-Blase gibt es viel interessante Forschung im Problemfeld inkrementeller Berechnung, und selbst self-adjusting computation, also Signals, ist dabei nicht einmal eine besonders interessante Achse.

• Die Richtung gefällt mir, aber davor müssten meiner Ansicht nach erst einige Low-Level-APIs in die Browser kommen.
  Es wird nahezu unmöglich sein, dass sich alle auf ein Standard-Template-System einigen. Was Browser stattdessen tun können, ist eine Low-Level-API bereitzustellen, die Diffs performant und nativ auf das DOM anwendet.
  Es wäre wirklich gut, so etwas nativ im Browser zu haben:
  element.applyDiff(DocumentFragment | string, { method: 'innerHTML' | 'outerHTML' })
  Dieser Ansatz könnte Diffs auf weniger störende Weise anwenden, etwa indem Elementfokus, Eingabewerte sowie der Zustand von Audio- und Videoplayern erhalten bleiben und Attribute geändert werden. JavaScript-Bibliotheken wie Idiomorph erledigen solche Dinge, aber eine native Lösung wäre wahrscheinlich deutlich schneller.

  • Im Artikel gibt es einen Link zum Vorschlag für DOM parts, der eine nützliche Low-Level-API sein könnte. Für VDOM-basierte Frameworks dürfte er nicht gut passen, aber in anderen Frameworks könnte er die Funktionsweise vereinfachen und mehr Spielraum für Optimierungen schaffen.
    Auch für Projekte ohne Framework wäre das nützlich, und besonders dann, wenn zusätzlich der Signals-Vorschlag angenommen würde.

• Der Vorschlag zu Records and Tuples ist nicht nur ins Stocken geraten, sondern wurde zurückgezogen. https://github.com/tc39/proposal-record-tuple/issues/394
  An seine Stelle ist https://github.com/tc39/proposal-composites getreten.