Auf dem Weg zu einer Konvergenz von JavaScript-Frameworks

Reaktivitätsprobleme, Vervielfachung von Frameworks: zwei große Herausforderungen für das Ökosystem

Im Kontext von JavaScript stellt „ein Signal einen reaktiven Zustand dar – einen Wert, der sich im Laufe der Zeit ändern kann und abhängig von diesen Änderungen automatisch Berechnungen und Effekte beeinflusst“, erklärt Rakesh Purohit, React-Entwickler bei DhiWise, in einem Blogbeitrag Entwicklungsframework, mit dem Figma-artige Designs in Code umgewandelt werden können, der von Entwicklern verwendet werden kann.

Für Rakesh Purohit ist „dies der Eckpfeiler der ereignisgesteuerten Programmierung, die einen deklarativeren Codierungsstil ermöglicht, bei dem der Datenfluss und nicht eine Reihe zwingender Schritte die Logik vorgibt.“

Konkret: Wofür werden Signale im JavaScript-Ökosystem verwendet? „Eine Menge Dinge“, antwortet Ben Lesh, Leiter des RxJS-Projekts und leitender Softwareentwickler bei Bridgewater Associates (ehemals Google und Netflix), während seiner Rede im Folies Bergères.

„Erstens ermöglicht es Ihnen, die Berechnung teurer Aufgaben so lange zu verzögern, bis sie tatsächlich benötigt werden. Wenn Sie etwas sehr schnell asynchron aktualisieren, können Sie die Berechnung verschieben, um die Leistung zu optimieren. Darüber hinaus ermöglicht dieser fortschrittliche Ansatz, klare Abhängigkeiten zwischen Berechnungen und Signalen zu definieren“, fährt er fort.

„Zum Beispiel kann eine Berechnung von den Signalen a und b abhängen, während ein Effekt von den Signalen c abhängen kann, die ihrerseits von a und b abhängen. Dadurch entsteht eine Abhängigkeitskette, die effizient und reaktionsschnell verwaltet wird.“

Diese Abhängigkeitskette wird formal durch ein Diagramm dargestellt, das Werte und Logiken für Benachrichtigung, Ungültigmachung, Berechnung und Speicherung (die Optimierung von Vorgängen durch deren Zwischenspeicherung) verknüpft.

„Signale verfolgen spezifische Datenänderungen in einer Benutzeroberfläche.“

„Mit Signalen können Sie bestimmte Datenänderungen in einer Benutzeroberfläche verfolgen“, fasst Minko Gechev, Leiter der Produkt- und Entwicklerbeziehungen für Angular bei Google, zusammen. Wenn ein Benutzer beispielsweise auf einer E-Commerce-Website die Menge eines Artikels in seinem Warenkorb ändert, werden nur die Komponenten aktualisiert, die diese Menge anzeigen, ohne alle Komponenten auf der Seite zu überprüfen. „Dadurch werden UI-Updates effizienter und schneller“, sagt er. Je komplexer die Webanwendung ist, desto wichtiger erscheint dieser Mechanismus.

Das Konzept ist nicht spezifisch für das JavaScript-Ökosystem. Ein ähnliches System existiert in der QT-Frontend-Bibliothek, die auf C++ basiert.

Auch im JavaScript-Ökosystem gibt es Signale „schon seit sehr langer Zeit“, sagt Ben Lesh, rund zehn Jahre. „Sie werden in Emberjs auch als berechnete Eigenschaften bezeichnet, sie sind Observables in Knockoutjs, in MobX, Signale in Angular und Solidjs, Spelled Runes, Vuejs Refs“, listet er auf.

Ein Vorschlag für Framework-Designer

Enthüllt am 1^Ist April 2024 (aber seit etwa einem Jahr in Arbeit), zielt der Vorschlag TC39 zu Signalen darauf ab, „die genaue Grundsemantik des Signaldiagramms zu definieren“. Die in diesem Aufruf zur Standardisierung vorgeschlagene API ist Frameworks gewidmet, von denen sich Designer inspirieren lassen können, „um die Interoperabilität dank eines gemeinsamen Signalgraphen und eines automatischen Tracking-Mechanismus sicherzustellen“.

Die Hauptmitwirkenden der Projekte Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelter, Vue und Wiz beteiligen sich seit etwa einem Jahr an dieser Standardisierungsbemühung.

Tatsächlich unterscheiden sich die Mechanismen zur automatischen Verfolgung von Änderungen an Werten und Logik, die sich auf die Benutzeroberfläche auswirken, häufig zwischen den JavaScript-Frameworks.

„Dies erschwert die gemeinsame Nutzung von Modellen, Komponenten und Bibliotheken zwischen verschiedenen Frameworks, die dazu neigen, fälschlicherweise an ihre Visualisierungs-Engine gekoppelt zu werden (da Signale normalerweise als Teil von JS-Frameworks implementiert werden)“, stellen die Autoren des Vorschlags fest.

Und eine Liste von Voraussetzungen vorzuschlagen, um das Signalmanagement so einheitlich wie möglich zu gestalten.

Es gibt daher zwei Arten von Signalen. Das Grundsignal stellt einen Wert dar. Das berechnete Signal kann das Ergebnis der Anwendung einer Formel auf zwei oder mehr Signale sein. Beide werden im Allgemeinen von den zugehörigen Frameworks „umhüllt“.

Die vorgeschlagene Implementierung sollte kaum Auswirkungen auf die Leistung haben. Daher werden die berechneten Signale zwischengespeichert und nur dann neu berechnet, wenn sich eine Signaldiagrammabhängigkeit geändert hat. Benutzerdefinierte Vergleiche helfen dabei, zu bestimmen, wann berechnete Signale aktualisiert werden sollten.

Aufgrund von Abhängigkeiten kann die Zustandsänderung eines Grundsignals zu einer Veränderung der davon abhängigen berechneten Signale führen. Feedback-Mechanismen erkennen Veränderungen und programmieren die Neuberechnung der berechneten Signale. Die Auswirkungen (die aus der Datenänderung resultierenden Operationen) werden gemäß dem durch die Reaktionen festgelegten Arbeitsplan ausgeführt.

Wenn möglich, könnten die Basis- und berechneten Signale vom Garbage Collector „wie jeder JavaScript-Wert“ behandelt werden.

Obwohl sich dieses Projekt noch in der zweiten von fünf Phasen (Stufe 1) der Integration in die Sprache befindet, implementiert Google es bereits in AngularJS und Wiz. Wiz ist wenig bekannt, da es sich um ein proprietäres Framework handelt, das intern vom Cloud-Riesen verwendet wird.

Wenn AngularJS zur Entwicklung von Google Analytics, den Serviceschnittstellen von GCP, verwendet wird, wird Wiz im Allgemeinen von den Teams hinter Gmail, YouTube und Workspace verwaltet.

„AngularJS wird häufig für hochgradig interaktive Schnittstellen verwendet, wenn Wiz eher mit allgemeinen öffentlichen Anwendungen in Verbindung gebracht wird, bei denen die Latenz sehr wichtig ist“, erklärt Minko Gechev. „Aber die Produktteams begannen, Funktionen aus beiden Frameworks zu wollen. Mir wurde dieses Konvergenzprojekt zusammen mit anderen übertragen.“

Deshalb haben die Teams hinter AngularJS und Wiz dafür gesorgt, dass Angular-Signale mit Wiz genutzt werden können.

Eine Umsetzung, die bei YouTube bereits in Produktion ist

„Derzeit nutzt der gesamte mobile YouTube-Verkehr Wiz mit Angular-Signalen“, sagt Minko Gechev. „Das Team konnte deutliche Leistungssteigerungen verzeichnen. Beispielsweise wurde bei Smart-TVs die Eingabelatenz (wenn ein Benutzer eine Taste auf seiner Fernbedienung drückt, Anmerkung des Herausgebers) um 35 % verbessert. Das Scrollen bei YouTube Shorts stieg auf 60 Bilder pro Sekunde, verglichen mit 25 Bildern pro Sekunde, die normalerweise beim virtuellen DOM üblich sind.

Daher ist der Ingenieur der Ansicht, dass die Standardisierung des Signalmanagements in der JavaScript-Sprache in vollem Gange ist.

„Von der Konvergenz verschiedener Frameworks wusste ich in der Vergangenheit nichts.“

„Die Referenzimplementierung verwendet Angular-Signale, weil sie bewiesen hat, dass sie mit mehreren Frameworks und Skalierungen auf YouTube, der zweitgrößten Website der Welt, funktionieren kann“, sagt er. „Außerdem wusste ich in der Vergangenheit nichts von der Konvergenz verschiedener Frameworks. Tatsächlich haben Framework-Designer oft versucht, in unterschiedliche Richtungen zu gehen, auch wenn einige Ideen zurückkamen und sich als bewährte Praktiken erwiesen.

Diese Konvergenz ist nicht nur intern. Nach und nach plant Google, die Funktionen von Angular und Wiz im Open-Source-Zweig von Angular zu vereinen. Minko Gechev geht davon aus, dass dies mehrere Jahre dauern wird.

Schließlich ist der Developer Relations Manager bei Google der Ansicht, dass JS-Frameworks zu „Meta-Freamworks“ werden. Laut einer von ihm geteilten Folie haben Angular, Next.js, Remix, Nuxt, SolidStart und SvelteKit gemeinsame Funktionen. Die Tools nutzen Komponenten, stellen virtuelles oder inkrementelles DOM bereit, unterstützen die statische Site-Generierung, serverseitiges Rendering, TypeScript sowie grundlegende und erweiterte Reaktionsfunktionen (wie Signale).

Andere Funktionalitäten sollten in irgendeiner Form abgeglichen werden. Minko Gechev setzt auf die Übernahme identischer, wenn nicht sogar ähnlicher Ansätze zur Ansichtsstruktur, Abhängigkeitsinjektion, Ereigniswiedergabe und selektiver Aktualisierung von UI-Komponenten (eine Funktion, die mit dem Ausdruck „partielle Bewässerung“ übersetzt werden könnte).

„Wie wählt man heutzutage ein Framework aus? Denken Sie nicht zu viel nach“, rät er. „Es wird immer die gleiche Technologie mit einem anderen Hut sein.“

Allerdings könne die Implementierung von Signalelementen je nach Designer noch unterschiedlichen Interpretationen unterliegen, weisen einige Entwickler darauf hin. Andere halten dies für einen „Fehler“.

Minko Gechev weist darauf hin, dass die Themen Stabilität und Zuverlässigkeit von Entwicklungsteams manchmal außer Acht gelassen werden. „Wir wollen sicherstellen, dass wir eine stabile Lösung nutzen, die uns langfristig unterstützt. Es ist auch sehr wichtig, ein reichhaltiges, integratives und unterstützendes Ökosystem zu haben und eine Lösung, die wir wirklich gerne nutzen“, schließt er.