Was genau ist eine „Hochleistungs-Web-App“ oder ein „Frontend“?

Seit dem Niedergang der Internet Explorer-Ära ist das JavaScript-Ökosystem immer leistungsfähiger geworden und der Begriff „Frontend“ ist zum Synonym für leistungsstarke, moderne Web-Clients geworden. Im Zentrum dieser „Frontend“-Welt steht React. Tatsächlich wirkt man oft wie ein Ausreißer, wenn man React in der Frontend-Entwicklung nicht verwendet.

Aber da nicht jedes Spiel AAA ist, müssen wir sorgfältig überlegen, was wir unter „hoher Leistung“ verstehen, wenn wir über Web-Apps sprechen. Diese Unterscheidung ist für das heutige Thema von entscheidender Bedeutung.

1. Der Umfang leistungsstarker Web-Apps

In den meisten Fällen bezieht sich der Begriff „Hochleistungs-Web-App“ auf einen interaktiven, dynamischen Web-Client, der mit JavaScript-basierten Frameworks wie React, Vue oder Angular erstellt wurde. Diese Apps zeichnen sich typischerweise durch schnelle Ladezeiten und clientseitiges Routing aus, und das virtuelle DOM von React spielt eine wichtige Rolle bei der Verbesserung der Rendering-Geschwindigkeit.

Es gibt jedoch Web-Apps, die alle 4 GB des Speicherlimits des WASM-Moduls nutzen, auf systematische Speicherverwaltung ausgelegt sind und eine Leistung anstreben, die mit nativen Programmen wie Blender oder 3Ds Max mithalten kann. Diese Apps entsprechen eher dem Konzept von „Programmen“, die alle Ressourcen eines Browser-Tabs nutzen, als herkömmlichen „Webseiten“, die für SEO optimiert sind.

Obwohl aktuelle Browserumgebungen aufgrund von Speicherbeschränkungen und Overhead möglicherweise immer noch Schwierigkeiten haben, eine native Leistung zu liefern, sind die Ziele solcher Apps grundlegend anders. Sie verarbeiten große Datenmengen und zielen darauf ab, die vollen 2–4 GB Speicher zu nutzen und gleichzeitig die höchsten Rendering-Geschwindigkeiten anzustreben.

Da sich die Probleme, mit denen diese Art von Web-Apps konfrontiert sind, von denen typischer „Hochleistungs“-Apps unterscheiden, unterscheiden sich auch die Richtungen, die sie verfolgen.

Die eingangs erwähnte „High-Performance-Web-App“ und die von mir hier beschriebene unterscheiden sich in ihren Wegen grundlegend. Sie unter einem einzigen Begriff zusammenzufassen, wäre problematisch. Wir benötigen eine andere Terminologie, um diese Unterschiede widerzuspiegeln.

Deshalb schlage ich vor, dass wir Letzteres nicht mehr als „Hochleistungs-Web-App“ oder „Frontend“ bezeichnen und stattdessen die folgenden Begriffe verwenden:

• Browserbasiertes High-Performance Framework Engineering (BBHPFE)
• (Browserbasiertes) High-Performance System Engineering (HPSE)

Ich glaube, dass diese Begriffe den Unterschied in den Anforderungen zwischen Frontend und HPSE klar definieren. Nicht jeder browserbasierte Client ist ein Frontend; einige sind HPSEs. Betrachten Sie das folgende Beispiel, um zu verstehen, warum diese Unterscheidung wichtig ist:

[Gespräch 1]

A: „Ich entwickle eine Frontend-App, verwende aber kein React.“
B: „Eine Frontend-App ohne React? React hat über 60 % Marktanteil im Frontend! Warum sollten Sie es nicht nutzen?“

[Gespräch 2]

A: „Ich entwickle eine HPSE-App, verwende aber kein React.“
B: „Das macht für HPSE Sinn. Spielefirmen passen ihre Engines oft umfassend an, aber die internen Funktionen und die Rendering-Pipeline von React können nicht geändert werden. Es wurde nie für diesen Zweck entwickelt.“

Lassen Sie uns nun die wesentlichen Komponenten besprechen, die ein HPSE haben muss.

2-1. Speicherverwaltung
Von Hochleistungsprogrammen kann man nicht sprechen, ohne sich mit dem Speicher zu befassen. Unabhängig davon, ob Sie einen Garbage Collector verwenden oder dynamisch zugewiesenen Speicher manuell freigeben, muss ungenutzter Speicher immer freigegeben werden.

Stellen Sie sich ein browserbasiertes Spiel vor, bei dem der Spieler zu einer neuen Karte wechselt. Das Spiel muss asynchron neue Kartendaten vom Server abrufen, neue Netze erstellen und alte entfernen. Die zur Generierung des alten Netzes verwendeten Daten müssen ebenfalls freigegeben werden.

Wenn die Verweise auf die alten Daten nicht ordnungsgemäß freigegeben werden, steigt die Speichernutzung mit jedem Kartenübergang weiter an. Sobald etwa 2 GB erreicht sind, kann es sein, dass der Fehler „Nicht genügend Speicher“ auftritt und der Browser abstürzt.

Es ist wahr, dass JavaScript nicht für die Speichersteuerung auf niedriger Ebene konzipiert wurde – weder die Sprache noch die Philosophie seiner Entwickler geben ihm Priorität. Ich sage nicht, dass Gedächtnismanagement immer entscheidend ist, aber wie man so schön sagt: „So etwas wie ein kostenloses Mittagessen gibt es nicht.“ Wenn eine Speicherverwaltung erforderlich ist, muss sie durchgeführt werden.

2-2. Flexibilität bei der Erfüllung von Anforderungen
Ich hörte einmal jemanden sagen: „Wenn Sie vom Junior-Entwickler zum Fortgeschrittenen wechseln, sollten Sie in der Lage sein, alles zu entwickeln, was von Ihnen verlangt wird.“

JavaScript ist bereits eine beeindruckende Sprache mit wenigen inhärenten Einschränkungen (abgesehen von Speicherbeschränkungen). Wenn Sie etwas bauen möchten, ist dies wahrscheinlich machbar.

Die eigentliche Frage ist, ob Ihr aktuelles Projekt wirklich einer Vielzahl von Anforderungen gerecht werden kann.

So wie Maschinen in einer Fabrik nach Dauerbetrieb ausfallen, führt die Suche nach leistungsstarken, maßgeschneiderten Funktionen unweigerlich zu unerwarteten Herausforderungen. In diesem Fall sind Flexibilität und die Fähigkeit, individuelle Anforderungen zu erfüllen, von entscheidender Bedeutung.

Haben Sie zum Beispiel schon einmal gehört, dass Lost Ark auf der Unreal Engine 3 basiert? Die Unreal Engine 5 ist jetzt erhältlich, sie verwenden jedoch immer noch die Unreal Engine 3, die 2004 entwickelt wurde. Um das Projekt bis jetzt aufrechtzuerhalten, müssen sie umfangreiche Modifikationen an der Engine vorgenommen haben – praktisch eine komplette Überarbeitung. Aufgrund der Eigenschaften des Spiels mussten sie die Rendering-Pipeline und -Schleife ständig mit Techniken wie verzögertem Rendering, Instanzierung, Culling und Bildschirmraumreflexion anpassen, um den Anforderungen an Leistung und Ästhetik gerecht zu werden.

Die Möglichkeit, den Quellcode der Engine zu ändern, war von entscheidender Bedeutung. Wenn der Motor abgeschaltet oder zu eng gekoppelt gewesen wäre, um Modifikationen zu ermöglichen, wäre Lost Ark möglicherweise nie entwickelt worden.

HPSE ist dasselbe. Während sich die Umgebung zu einer browserbasierten Umgebung geändert hat, bleibt der Bedarf an benutzerdefinierten Funktionen und flexiblen Modifikationen derselbe. Daher müssen in HPSE verwendete Bibliotheken und externe Module modifizierbar sein, und wenn die Rendering-Pipeline des Browsers oder die interne Modulkopplung zu starr ist, um diese Änderungen zu ermöglichen, wird dies zu einem erheblichen Problem.

2-3. Der unvermeidliche objektorientierte Ansatz
Beim Umgang mit umfangreichen Programmen ist eines unumgänglich: die objektorientierte Programmierung (OOP).

JavaScript ist eine Multiparadigmensprache und funktionale Programmierung (FP) ist weit verbreitet. Obwohl FP für Web-Clients geeignet ist, wird es jedoch selten in großen Programmen verwendet, in denen mehrere Objekte auf komplexe Weise interagieren, da Instanzen in FP keine internen Zustände haben.

React kompensiert dies durch globale Statusverwaltung und useEffect, aber es ist nicht so intuitiv, als würde jede Instanz ihren eigenen Status beibehalten und Methodenaufrufe über öffentliche Methoden steuern.

Obwohl OOP nicht immer die beste Wahl ist, fällt es schwer, sich eine bessere Alternative vorzustellen, wenn man die hochgradig individuellen Entwicklungsanforderungen von HPSE berücksichtigt. Viele große Programme, darunter Betriebssysteme und Spiele, basieren auf OOP-Prinzipien. Selbst die beliebtesten Engine-Quellen sind objektorientiert, mit geringfügigen Abweichungen in der Methodik.

Entwickler, die an Großprojekten teilgenommen haben, sind wahrscheinlich mit OOP vertraut. Dies macht die OOP-basierte Entwicklung förderlich für die Zusammenarbeit.

Dennoch besteht kein Grund, die Stärken von JavaScript aufzugeben. Da JavaScript Funktionen und Const-Deklarationen unterstützt, können einfache Modulfunktionen, die keine Instanzen erfordern, mithilfe von Const oder Functions als Objektliterale definiert werden. Dies kann die Produktivität steigern und die Vielseitigkeit von JavaScript nutzen.

Zusammenfassend glaube ich, dass ein Multi-Paradigmen-Ansatz unter Einbeziehung objektorientierter Prinzipien ideal für HPSE wäre.