Ein auf dem JetBrains-Blog veröffentlichter Artikel untersucht die Möglichkeit, Compose HTML zum Erstellen serverseitig gerenderter Weboberflächen in einer Kotlin-Umgebung zu verwenden, während mehrere Frameworks einen Teil der UI-Verarbeitung wieder auf den Server verlagern. Die vorgeschlagene Idee besteht darin, wiederverwendbare und typsichere Compose-Komponenten bereitzustellen, anstatt vom Anwendungscode getrennte Textvorlagen zu schreiben. Der Artikel betont, dass es sich bei den vorgestellten Inhalten um eine Erkundung von Ideen handelt und nicht um eine offizielle Verpflichtung von JetBrains oder eine Ankündigung von APIs beziehungsweise einer Roadmap.
Der Ansatz geht von einem Vergleich mit Entwicklungen in anderen Ökosystemen aus: React hat Server Components eingeführt, HTMX hat das Interesse am Hypermedia-Modell erneuert, und Phoenix LiveView hat gezeigt, dass sich interaktive Aktualisierungen vom Server übertragen lassen, ohne auf ein Client-Framework angewiesen zu sein. Der Artikel stellt fest, dass das JVM-Ökosystem zahlreiche Bibliotheken für serverseitiges Rendering besitzt, diese jedoch häufig auf Vorlagensprachen beruhen und keine Komponenten anbieten, die dem den JavaScript-Entwicklern bekannten Komponentenmodell ausreichend nahekommen.
Warum Compose HTML?
Compose Multiplatform bietet eine Möglichkeit, Geschäftslogik und Benutzeroberflächen einmal zu schreiben und zwischen Android, iOS, Desktopgeräten und dem Web zu teilen. Das derzeitige Web-Targeting in Compose Multiplatform basiert jedoch auf einer direkten Darstellung innerhalb eines Canvas, was laut Artikel Kosten im Zusammenhang mit Suchmaschinenoptimierung, Ladezeiten und Barrierefreiheit verursacht.
Compose HTML, das älter ist als Compose for Web, verwendet die Compose Runtime, um Single-Page-Anwendungen in Kotlin zu erstellen und sie anschließend mit dem Kotlin/JS-Compiler in JavaScript zu übersetzen. Der Artikel schlägt vor, dafür ein JVM-Ziel hinzuzufügen, damit serverseitiges Rendering möglich wird: Der HTML-Baum würde direkt in Kotlin mithilfe echter Komponenten und Typen erstellt, ohne eine separate Vorlagensprache.
Die Quelle zeigt ein Gegenüberstellung eines Kartenkomponenten-Beispiels aus Thymeleaf und einer Compose-Komponente. Im vorlagenbasierten Modell wird die Karte in einer separaten Datei definiert, und Parameter werden als Zeichenketten übergeben, die nicht an eine Typprüfung gebunden sind. In Compose ist die Karte dagegen eine typisierte Funktion, die einen Titel vom Typ String und eine Zahl vom Typ Int entgegennimmt. Daher führt eine Änderung des Parameternamens dazu, dass die Verwendungsstellen in der Entwicklungsumgebung aktualisiert werden oder ein Kompilierungsfehler auftritt. Ebenso führt die Übergabe eines falschen Typs zu einem Compilerfehler statt zu einer Überraschung während der Laufzeit.
Eine Vorstellung vom serverseitigen Rendering
Das vorgeschlagene Konzept erfordert das Hinzufügen von Funktionen wie renderToString und renderToBytes, um den Composition-Vorgang einmal auf der JVM auszuführen und den resultierenden Baum anschließend in HTML-Text oder Byte-Daten umzuwandeln. Dem genannten Beispiel zufolge erstellt der Vorgang Komponenten wie Text und Container-Elemente, wartet auf die Stabilisierung der initialen Composition, durchläuft anschließend den resultierenden Baum und wandelt ihn ohne Browser oder DOM in HTML um.
Dieses Modell weist klare Einschränkungen auf. Wahrscheinlich würde es auf eine einzige Renderphase beschränkt bleiben, ohne erneute Composition bei Zustandsänderungen oder die Ausführung von Effekten, wodurch es dem Konzept des serverseitigen Renderings in JavaScript-Frameworks ähnelt. Ereignis-Listener können in den Komponenten zwar akzeptiert werden, blieben auf dem Server jedoch inaktiv, da es keinen Nutzen hätte, während der HTML-Erstellung dort Browserereignisse zu verknüpfen.
Der Artikel entwirft eine vollständige Aufgabenanwendung mit Spring Boot: Eine GET-Route rendert die Aufgabenseite, während POST-Anfragen eine neue Aufgabe hinzufügen oder ihren Status ändern. Die Interaktionen würden in diesem Szenario auf dem Absenden echter HTTP-Formulare und dem Neuladen der Seite beruhen, ohne JavaScript auf der Clientseite – ähnlich wie bei herkömmlichen Rendering-Anwendungen mit Thymeleaf, jedoch mit einer vollständig in Compose geschriebenen Oberfläche.
Die aktuelle Landschaft und mögliche Frameworks
Compose HTML verfügt derzeit nur über ein JS-Ziel und bietet daher kein serverseitiges Rendering. Dennoch verweist der Artikel auf ein aktives Ökosystem rund um Compose für das Web. Das Framework Kobweb basiert auf Compose HTML und unterstützt den Export statischer Websites sowie Pre-Rendering zur Verbesserung der Sichtbarkeit in Suchmaschinen, bietet jedoch kein SSR. Kilua hingegen nutzt die Compose Runtime direkt zur Ausführung von SSR und CSR und stellt Integrationen mit Ktor, Spring Boot und anderen Systemen bereit, während Summon Unterstützung für SSR und Hydration bietet.
Der Ansatz geht davon aus, dass das Hinzufügen von SSR-Funktionen zu Compose HTML Kobweb, Kilua und Summon eine gemeinsame Grundlage geben könnte, anstatt drei getrennte Wege zu verfolgen. Außerdem könnten Spring Boot und Ktor dadurch einen praktischen Grund erhalten, Compose HTML auf dem Server zu integrieren. Dieses Ergebnis ist jedoch weder garantiert noch angekündigt; der Artikel beschreibt es als eine mögliche Richtung, die Experimente und eine Festlegung der erforderlichen Integrationspunkte benötigt.
Über das initiale Rendering hinaus
Die weitere Untersuchung führt anschließend zur Frage nach Hydration und Zustandssynchronisierung: Wie setzen auf dem Server gerenderte Komponenten ihre interaktive Arbeit im Browser fort? Und müssen sich Server und Client auf einen gemeinsamen Zustand einigen? Der Artikel weist darauf hin, dass die Lösung dieser Fragen eine gemeinsame Nutzung des UI-Codes zwischen beiden Seiten ermöglichen könnte, sodass dieselbe Komponente für Browser und Server übersetzt wird und vollständig in Kotlin geschriebene, integrierte interaktive Webanwendungen unterstützt.
Dennoch schlägt das Konzept nicht vor, Compose HTML in ein vollständig ausgestattetes, sofort einsatzbereites Framework mit allen Komponenten und Funktionen umzuwandeln. Das nächstliegende Ziel besteht der Quelle zufolge darin, den Kern klein zu halten und den Aufbau von Framework-Integrationen und Ökosystembibliotheken der Community zu überlassen – ähnlich dem Ansatz von React, jedoch innerhalb einer Multiplattformbibliothek. Dies unterscheidet sich von anderen Teilen von Compose Multiplatform, die offizielle Bibliotheken für Material3, Zustandsverwaltung und weitere Bereiche bereitstellen.
Laut Artikel finden Gespräche mit den Entwicklern von Kobweb, Kilua und Summon statt, um deren Einschätzungen einzuholen. Auch das Spring-Team zeigte nach dem Hinzufügen eines JVM-Ziels zu Compose HTML Interesse an einem Experiment. Daher liegt der derzeitige Wert dieses Vorschlags in der Bestimmung einer möglichen Richtung für die Webentwicklung auf der JVM und nicht in der Bereitstellung eines verfügbaren Produkts oder einer bestätigten Funktion. Sollte sich die Idee weiterentwickeln, wird die wichtigste Herausforderung darin bestehen, die Einfachheit des Kerns, die Integration in Server-Frameworks sowie die Anforderungen an Interaktivität und die Wiederverwendung von Komponenten zwischen Client und Server auszubalancieren.