Svelte hat sich in den letzten Jahren als eines der innovativsten und beliebtesten Webframeworks etabliert. Seit dem Release von Svelte 3 im Jahr 2019 begeistert die Technologie Entwickler weltweit durch eine Radikalität, die den klassischen Framework-Ansatz überdenkt. Statt einer Laufzeit kümmert sich Svelte im Build-Prozess darum, den Quellcode zu optimieren und performant in reines JavaScript zu verwandeln. Doch trotz all der Vorzüge gibt es einen Bereich, in dem Svelte noch nicht vollends überzeugen kann: die Entwicklung echt nativer Anwendungen für mobile oder Desktop-Plattformen. Aufgrund seiner engen Verflechtung mit dem DOM ist es für Svelte bislang nicht möglich, native Apps zu erzeugen, die nicht auf WebViews oder Browser-Engines basieren.
Bislang greifen viele Entwickler für native oder plattformübergreifende Apps auf Frameworks wie Capacitor, Tauri oder NativeScript zurück. Diese Tools kombinieren native Features mit Webtechnologien und ermöglichen etwa den Zugriff auf Gerätesensoren oder das Verpacken einer Web-App in eine native Hülle. Gerade Capacitor punktet mit einer großen Plugin-Bibliothek, während Tauri mit Rust-Unterstützung und schlanker Architektur auf sich aufmerksam macht. NativeScript ist wohl das einzige Framework unter den genannten, das wirklich native UI-Komponenten verwendet, doch Svelte wird hier noch nicht vollständig kompensiert – vor allem fehlt die Möglichkeit, die Anwendung parallel für Web und native Plattform zu rendern. Eine spannende Entwicklung hat in diesem Kontext der Einstieg von ByteDance mit dem Projekt Lynx gebracht.
Lynx verfolgt einen neuen Ansatz, indem die App-Logik und die UI-Rendering-Prozesse in separaten Threads ausgeführt werden. Insbesondere bietet Lynx ein agnostisches Kern-Rendering-System, das theoretisch mit verschiedenen Frontend-Frameworks funktionieren kann – auch mit Svelte. Jedoch ist der aktuelle Stand so, dass Lynx momentan nur React unmittelbar unterstützt und keine offizielle Svelte-Integration bietet. Ein entscheidender Haken dabei ist die fehlende Custom Renderer API in Svelte – eine Schnittstelle, die ermöglichen würde, Svelte nicht nur für den Web-DOM, sondern für andere Rendering-Backends zu kompilieren. Custom Renderer sind keine neue Idee, sondern eine bewährte Architektur, die React Native zur Welt gebracht hat.
React trennt seine Kernfunktionalität, also die Berechnung der UI-Zustandsänderungen, von der Art, wie die UI gerendert wird. So kann React die UI nicht nur im Browser, sondern auch in nativen Komponenten rendern, in der Konsole oder sogar für Videos. Svelte hingegen ist durch seinen Compiler-Ansatz tief auf HTML und DOM spezialisiert. Bisher existiert keine saubere Schnittstelle, die es ermöglicht, die Erzeugung von UI-Elementen außerhalb des Browsers zu abstrahieren und zu variieren. Genau hier setzt die Initiative von Mainmatter an.
Das Unternehmen arbeitet intensiv daran, eine Custom Renderer API für Svelte zu entwickeln. Ziel ist es, Svelte-Komponenten so zu kompilieren, dass sie nicht nur auf dem klassischen DOM, sondern auch auf alternativen Rendering-Zielen laufen können. Dazu wurde ein Prototyp gebaut, der zeigt, dass Svelte-Komponenten für Lynx gerendert werden können, was letztendlich wirklich native Apps mit Svelte denkbar macht. Der Kern der Herausforderung liegt dabei in der komplexen Verflechtung von Sveltes Client-Runtime mit browser-spezifischen APIs. Beispielsweise nutzt das Framework intern den "template"-Tag des Browsers zur effizienten Erstellung von DOM-Knoten.
Dieser Mechanismus ist jedoch außerhalb eines echten DOM-Kontexts nicht verfügbar, etwa bei nativen UI-Elementen oder anderen Rendering-Engines. Um das zu lösen, haben die Entwickler eine Option ergänzt, die eine abstraktere Templatestruktur erzeugt. Diese beschreibt Elemente und ihre Attribute in Form von verschachtelten Objekten, die von einer Custom Renderer API interpretiert werden können. Interessanterweise liefern Vergleiche mit Frameworks wie Vue und Solid wertvolle Impulse. Vue setzt traditionell auf virtuellen DOM mit Renderer-Optionen, was ihn flexibler macht.
Solid wiederum zeigt große Ähnlichkeiten mit Sveltes Reaktivitätsansatz und verwendet eine ähnliche Template-Erzeugung. Durch das Studium dieser Frameworks konnten Ideen für den Umgang mit Custom Renderer in Svelte entwickelt werden. Im Zuge dieser Forschung ergab sich zudem, dass die existierende Svelte-Client-Runtime zu komplex und dom-spezifisch ist, sodass ein separater, vereinfachter Renderer entwickelt werden muss. Er soll ganz bewusst auf DOM-exklusive Features wie Hydration, Animation und komplexe Event-Delegation verzichten, um die Einsetzbarkeit für native Plattformen zu erhöhen. Die daraus resultierende modulare Architektur erleichtert auch zukünftige Erweiterungen und Wartungen.
Das erste richtige Experiment in der Praxis war die Implementierung eines Prototyps für Lynx. Ausgangspunkt war eine experimentelle Version von Svelte mit der neuen Custom Renderer API. Die Herausforderungen zeigten sich schnell: Lynx ist ein noch sehr junges System, mit sparsamer Dokumentation und experimentellen APIs. Nach einigen Tagen intensiver Arbeit konnte jedoch eine einfache Todo-App direkt auf einem mobilen Gerät ausgeführt werden, was eine wichtige Bestätigung der Machbarkeit war. Die gezeigte Todo-App kombiniert die typischen Svelte-Features mit nativen UI-Elementen von Lynx und nutzt dessen Event-System.
Dabei wurde deutlich, wie der Custom Renderer Sveltes Komponentencode nahtlos in das Lynx-Runtime-System einbindet. Das eröffnet faszinierende Möglichkeiten für den Einsatz von Svelte in nativem Kontext – sei es für mobile Geräte oder möglicherweise auch Desktop. Die Vision ist eine Welt, in der Entwickler ihre Anwendung einmal in Svelte schreiben und sie dann ohne großen Mehraufwand als Web-App, als native Mobil-App und auch als Desktop-App veröffentlichen können. Nichtsdestoweniger befindet sich das Projekt noch deutlich vor seiner Marktreife. Es fehlen wichtige Features wie etwa die Unterstützung von Hintergrund-Threads für Events oder eine umfassende Abdeckung möglicher UI-Komponenten.
Ebenso steht eine grundlegende Überarbeitung der Svelte-Interna an, um die Custom Renderer API stabil und wartbar zu machen. Auch das Thema Testing ist essenziell, um unerwartete Fehler in produktiven Anwendungen zu vermeiden. Für Unternehmen und Entwickler, die von dieser Technologie überzeugt sind, bietet sich jetzt bereits die Möglichkeit, die Entwicklung zu unterstützen oder aktiv daran mitzuwirken. Mainmatter bittet um Sponsoring und Zusammenarbeit, um den Weg von der experimentellen Basis hin zu einem robusten, produktiv einsetzbaren Ökosystem zu ebnen. Aus strategischer Perspektive ist es bemerkenswert, wie sich Sveltes Philosophie mit der Custom Renderer API weiterentwickelt.
Der Fokus bewegt sich weg von einer rein browserzentrierten Lösung hin zu einem Don’t-Lock-In-Ansatz, bei dem der Entwickler die Freiheit hat, den Renderprozess der UI flexibel zu gestalten. Dieses Paradigma entspricht dem Trend, dass Anwendungen zunehmend nahtlos über verschiedene Zielplattformen laufen müssen und das Entwickeln mit wiederverwendbaren Komponenten immer wichtiger wird. Abschließend kann man sagen, dass das Thema „Truly Native Apps mit Svelte“ in der Entwicklung steckt, aber großes Potenzial birgt. Die Kombination aus Sveltes Reaktivität und Performance mit nativen Rendering-Engines könnte die App-Entwicklung revolutionieren. Die Custom Renderer API schafft den Kern für diese Evolution, indem sie das Framework um wichtige Schnittstellen erweitert.
Die nächste Zeit wird spannend sein, wenn dieses Vorhaben weitere Fortschritte macht und in der Praxis erprobt wird. Für Entwickler, Unternehmen und Fans von Svelte lautet der Aufruf also: Augen auf und bereithalten! Die Zeiten, in denen Svelte ausschließlich Webapps dominierte, könnten sich bald zum Positiven verändern. Wer heute in die Community und Projekte wie die Custom Renderer Initiative investiert, positioniert sich bestens für die Zukunft nativer App-Entwicklung mit Svelte.
