WebAssembly vs. Flatpak: Deployment-Alternativen für nkrunner

Ein Werkzeug ist nur dann nützlich, wenn man es unkompliziert ausführen kann. Da der nkrunner – unsere Custom UI-Engine – als hardwarenahe Codebasis entwickelt wird, umgehen wir von Haus aus die typischen Abhängigkeits-Orgien moderner Web-Frameworks. Dennoch stellt sich die Frage, wie man die Anwendung am saubersten an den Nutzer ausliefert, ohne in der Linux-Binary-Hölle zu versinken.

Zwei moderne Ansätze drängen sich für ein solches Projekt auf: Flatpak und WebAssembly (Wasm). Beide basieren auf dem Konzept der Sandbox, lösen das Problem aber auf völlig unterschiedlichen Ebenen.

1. Das Sandbox-Modell: Isolation vs. Kapselung

• Flatpak (Der native Weg): Flatpak nutzt Linux-Kernel-Features (Namespaces, Bubblewrap), um die Anwendung vom restlichen System zu isolieren. Der Code läuft absolut nativ auf der CPU des Hosts. Will die Engine jedoch Konfigurationsdateien lesen oder ins Netzwerk funken, muss sie explizit durch sogenannte XDG-Portals greifen. Das System schützt den Nutzer, erfordert aber Konfigurationsaufwand für das Paket-Manifest.

Exkurs: Die Ursprünge von Flatpak
Flatpak entstand aus dem historischen Bedürfnis, die chronische Fragmentierung des Linux-Desktops zu überwinden. Der Hauptentwickler Alexander Larsson startete das Projekt 2015 unter dem Namen xdg-app. Das primäre Ziel war es, Desktop-Anwendungen unabhängig vom Basis-Betriebssystem und dessen Release-Zyklen auszuliefern. Maßgeblich vorangetrieben und finanziert wird Flatpak bis heute von Red Hat und dem GNOME-Projekt (unter dem Schirm von freedesktop.org). Im Gegensatz zu Canonical, die mit Snap einen stark firmenzentrierten Weg einschlugen, etablierte sich Flatpak als der von der Community bevorzugte, dezentrale Open-Source-Standard für Desktop-Sandboxing.

• WebAssembly (Die absolute Kapselung): Hier bietet der Browser die ultimative Sandbox. Der Engine-Kern wird in Wasm-Bytecode übersetzt und komplett vom Host-Betriebssystem isoliert ausgeführt. Es gibt keinen direkten, unkontrollierten Zugriff auf das Dateisystem. Höchste Sicherheit für den Nutzer, ohne dass auch nur eine einzige Berechtigung im OS konfiguriert werden muss.

Exkurs: Wer steht hinter WebAssembly?
WebAssembly ist eine technologische Seltenheit: Ein Standard, bei dem sich die sonst konkurrierenden Tech-Giganten einig wurden. Wasm wurde 2015 angekündigt, nachdem sich Vorgängertechnologien wie Mozillas asm.js oder Googles Native Client (NaCl) als zu kompromissbehaftet herausstellten. Entwickelt wurde Wasm in einer beispiellosen Kooperation der großen Browser-Schmieden: Mozilla, Google, Microsoft und Apple. Heute wird der Standard vom W3C (World Wide Web Consortium) gepflegt. Wasm wurde explizit erfunden, um performance-kritische Anwendungen (wie 3D-Engines, Video-Editoren oder CAD-Software) mit nahezu nativer Geschwindigkeit sicher im Browser auszuführen, ohne JavaScript als rechenintensiven Flaschenhals zu nutzen.

2. Grafik und Performance

Die Engine ist darauf getrimmt, tausende Objekte parallel bei stabilen 60 FPS zu rendern. Wie schlagen sich die Zielplattformen dabei?

• Flatpak: Liefert kompromisslose native Performance. Der nkrunner spricht hier direkt mit den lokalen Grafikkartentreibern des Hosts (OpenGL/Vulkan) und schöpft die Hardware zu 100 % aus.

• WebAssembly: Da die Architektur unserer Engine strikt plattformunabhängig entworfen ist, lassen sich die internen Grafik-Befehle im Web-Kontext nahtlos nach WebGL2 oder WebGPU übersetzen. Dank moderner JIT-Compiler in den Browsern läuft das überraschend performant und erreicht oft 80–90 % der nativen Geschwindigkeit. Ein minimaler Overhead bleibt durch die Abstraktionsschicht des Browsers bestehen, ist für UI-Anwendungen aber in der Regel vernachlässigbar.

3. Der Cross-Platform-Hebel

• Flatpak: Bindet das Tooling zwingend an den Linux-Desktop. Das löst das Deployment für unsere Kern-Arbeitsumgebung, lässt aber Windows- oder macOS-Nutzer komplett außen vor.

• WebAssembly: Das ist der architektonisch eleganteste Pfad. Aus dem gleichen Quelltext purzelt eine einzige .wasm-Datei. Der nkrunner läuft damit sofort und ohne Code-Anpassungen auf Linux, Windows, macOS, Android und iOS. Der Nutzer muss nichts installieren, keine Abhängigkeiten auflösen und keinen Paketmanager bedienen – ein Klick auf eine URL genügt, und die Engine bootet im Tab.

Die Kehrseite: Wo WebAssembly schmerzt

Wenn man den nkrunner als reine Web-App ausliefert, verliert man allerdings fundamentale Eigenschaften eines klassischen Desktop-Werkzeugs. Der Verzicht auf direkten Systemzugriff ist der Preis für die grenzenlose Portabilität:

• Dateizugriff: Man kann nicht einfach eine lokale Konfigurationsdatei aus ~/.config/nkrunner parsen oder ungefragt Projekte vom Desktop laden. Im Browser ist man auf lokale Datenbanken (IndexedDB) oder die explizite Interaktion über Datei-Dialoge angewiesen.
• System-Integration: Es gibt keine nativen OS-Menüs, kein echtes Tray-Icon und globale System-Shortcuts des Window-Managers lassen sich nicht einfach kapern.
• Das "Desktop-Gefühl": Soll sich die Wasm-Version wie eine vollwertige, eigenständige App anfühlen, müsste man sie wiederum in einen nativen Wrapper verpacken (z. B. als sehr leichtgewichtige Web-View-Shell), was den Deployment-Vorteil der reinen URL wieder etwas relativiert.

Fazit für den nkrunner

Für die Entwicklung von interaktiver UI-Logik sind beide Wege extrem wertvoll.

Während der Entwicklung wird die Engine weiterhin rein nativ kompiliert, um blitzschnelle Iterationszyklen und volles Debugging zu garantieren. Für das finale Deployment zeichnet sich jedoch ein hybrider Ansatz ab: Für Power-User, die den nkrunner lokal mit tiefgreifenden Dateisystem-Rechten und maximaler GPU-Leistung nutzen wollen, ist ein Flatpak die sauberste Lösung. Um die Technologie jedoch reibungslos zu demonstrieren oder plattformübergreifend bereitzustellen, ist WebAssembly unschlagbar. Die Engine-Architektur gibt diesen doppelten Weg glücklicherweise her, ohne dass wir uns technisch in eine Sackgasse manövrieren.