Desktop-Apps mit Webstandards – ohne Chromium-Ballast
SerieCross-Platform Development
Teil 3 von 4
Wer Desktop-Apps mit Webtechnologien bauen will, denkt zuerst an Electron. Das ist nachvollziehbar – Electron hat die Kategorie definiert. Doch der Preis dafür ist hoch: ein kompletter Chromium-Browser in jeder App, 150 MB Mindestgröße, hunderte Megabyte RAM im Leerlauf. Für viele Anwendungsfälle ist das unverhältnismäßig.
Neutralinojs geht einen anderen Weg. Statt einen eigenen Browser mitzuliefern, nutzt das Framework den Webview des Betriebssystems – Edge WebView2 auf Windows, WKWebView auf macOS, WebKit2GTK auf Linux. Das Ergebnis: App-Bundles unter 2 MB, minimaler Speicherverbrauch und ein Start in Bruchteilen einer Sekunde.
Wie Neutralinojs funktioniert
Die Architektur unterscheidet sich grundlegend von Electron. Neutralinojs besteht aus einem schlanken C++-Binary, das drei Aufgaben übernimmt: einen eingebetteten Webserver für die statischen Dateien starten, den systemeigenen Webview laden und eine WebSocket-Verbindung zwischen Frontend und Backend aufbauen.
Wenn JavaScript-Code eine native Funktion aufruft – etwa Dateizugriff, Clipboard-Operationen oder Systeminformationen – wird die Anfrage per WebSocket an das C++-Backend geschickt, dort ausgeführt und das Ergebnis als aufgelöstes Promise zurückgegeben.
Diese Entkopplung bringt einen interessanten Nebeneffekt: Neutralinojs-Apps können nicht nur im Webview laufen, sondern auch im Browser, als Chrome-App oder im Cloud-Modus. Der Webview ist eine Option, keine Voraussetzung.
Was Neutralinojs mitbringt
Die native API deckt die wichtigsten Bereiche ab:
- Dateisystem: Lesen, Schreiben, Kopieren, Verschieben, Löschen – inklusive Pfadauflösung
- Clipboard: Text, HTML und Bilder lesen und schreiben
- Fenster: Erstellen, Positionieren, Drag-Gesten, Drucken, Taskbar-Sichtbarkeit
- System: Umgebungsvariablen, Prozessausführung, native Dialoge, Tray-Icons, Benachrichtigungen
- Storage: Key-Value-Persistenz für App-Daten
- Auto-Updater: Eingebauter Update-Mechanismus für portable Apps
- Extensions: IPC mit externen Prozessen in beliebigen Sprachen
Seit Version 6.3.0 unterstützt Neutralinojs außerdem Single-Executable-Builds über postject – eine einzelne ausführbare Datei, die alle Ressourcen enthält. Das vereinfacht die Distribution erheblich.
Plattformseitig werden Linux, macOS und Windows unterstützt, jeweils auch auf ARM-Architekturen (Linux armhf/arm64, macOS arm64).
Vergleich mit den Alternativen
Die Wahl des Desktop-Frameworks hängt von den Anforderungen ab. Hier ein Überblick:
Bundle-Größe und Ressourcenverbrauch:
| Framework | Bundle-Größe | RAM (Leerlauf) | Webview |
|---|---|---|---|
| Neutralinojs | ca. 2 MB | Sehr gering | System-Webview |
| Tauri | 2,5 bis 10 MB | 20 bis 40 MB | System-Webview |
| Electron | 100 bis 150+ MB | 200 bis 400 MB | Chromium (gebundelt) |
| NW.js | 80 bis 100+ MB | 150 bis 300 MB | Chromium (gebundelt) |
| Flutter | 15 bis 25 MB | Variabel | Eigene Engine |
Architektur und Sprachen:
| Framework | Backend-Sprache | Node.js-Zugriff | Ökosystem |
|---|---|---|---|
| Neutralinojs | C++ (Framework) | Nein (Extensions) | Klein |
| Tauri | Rust | Nein (Rust-Backend) | Wachsend |
| Electron | Node.js | Voll | Sehr groß |
| NW.js | Node.js | Voll | Mittel |
Der zentrale Unterschied: Neutralinojs und Tauri nutzen beide den System-Webview, aber Tauri setzt auf Rust als Backend-Sprache und hat ein deutlich größeres Ökosystem mit ausgereiftem Tooling für Installer, Auto-Updates und Sicherheitsfeatures. Electron bietet mit Node.js-Integration den einfachsten Zugang zum gesamten npm-Ökosystem, bezahlt das aber mit Größe und Ressourcenverbrauch.
Neutralinojs positioniert sich als die leichteste Option: minimaler Overhead, schneller Einstieg, keine Rust-Kenntnisse erforderlich. Der Trade-off ist ein kleineres Ökosystem und weniger produktionsreife Tooling-Infrastruktur.
Wo Neutralinojs an Grenzen stößt
Die Leichtgewichtigkeit hat ihren Preis – und den sollte man kennen, bevor man sich festlegt.
Kein Node.js-Runtime: Das ist der größte Einschnitt. npm-Pakete, die Node.js-APIs nutzen (fs, crypto, net), funktionieren nicht. Stattdessen muss man die Neutralinojs-eigene API verwenden oder Extensions schreiben. Für viele Webentwickler bedeutet das einen Paradigmenwechsel.
Webview-Inkonsistenzen: Anders als bei Electron, wo überall derselbe Chromium läuft, verhält sich der Webview auf jedem Betriebssystem anders. CSS-Rendering, JavaScript-Engine-Verhalten, verfügbare Web-APIs – all das variiert. Was auf macOS perfekt aussieht, kann unter Linux anders rendern.
Installationsabhängigkeiten: Auf Windows muss Edge WebView2 vorhanden sein (seit Windows 10 standardmäßig ausgeliefert, auf älteren Systemen nachzuinstallieren). Auf Linux wird webkit2gtk benötigt – je nach Distribution nicht vorinstalliert.
Kein ausgereiftes Installer-Tooling: Electron hat electron-builder, Tauri hat seinen eigenen Bundler. Neutralinojs bietet seit v6.3.0 Single-Executable-Builds, aber vollwertige Installer (.msi, .dmg, .deb) muss man selbst orchestrieren.
Kleineres Ökosystem: Weniger Plugins, weniger Templates, weniger Community-Ressourcen. Bei Problemen ist man stärker auf die offizielle Dokumentation und GitHub Issues angewiesen.
Die Notiz-App Notesnook hat Neutralinojs evaluiert und die Features gelobt – sich aber letztlich für Electron entschieden, weil Sicherheit und Zuverlässigkeit im Produktionsbetrieb schwerer wogen als die Größenvorteile.
Projekt-Status und Entwicklung
Neutralinojs existiert seit 2018 und wird primär von Shalitha Suranga gepflegt, eingebettet in die gemeinnützige Organisation CodeZri. Die aktuelle Version ist 6.4.0 (Stand März 2026), mit einem Release-Zyklus von etwa zwei Monaten.
Die jüngsten Versionen brachten substanzielle Verbesserungen:
- v6.4.0: Storage-API-Erweiterungen (
storage.clear(),storage.removeData()), modernisierte macOS-APIs - v6.3.0: Single-Executable-Builds via postject,
--embed-resourcesFlag - v6.2.0:
window.print(),window.beginDrag(), erweiterte Fenstersteuerung
Das Projekt beteiligt sich am Google Summer of Code und pflegt ein Roadmap-Repository auf GitHub. Die Entwicklung folgt einem Community-getriebenen Modell – Feature-Wünsche und Pull Requests treiben die Richtung. Mit rund 8.400 GitHub-Stars und aktivem Commit-Verlauf (letzter Commit: März 2026) ist das Projekt lebendig, aber deutlich kleiner als Tauri oder Electron.
Die Governance ist ein Risikofaktor: Ein einzelner Hauptmaintainer bedeutet hohe Abhängigkeit von einer Person. Das Projekt arbeitet daran, die Maintainer-Basis zu erweitern – ein typisches Wachstumsthema für Open-Source-Projekte dieser Größenordnung.
Neutralinojs und Astro: Eine naheliegende Kombination
Astro generiert standardmäßig statisches HTML mit minimalem JavaScript – genau das, was Neutralinojs als Input erwartet. Die Integration ist konzeptionell einfach:
# 1. Astro-Projekt bauen
pnpm build
# 2. Neutralinojs-Konfiguration auf den Build-Output zeigenIn der neutralino.config.json verweist man auf das Astro-Build-Verzeichnis:
{
"documentRoot": "./dist/",
"url": "/",
"window": {
"title": "Meine App",
"width": 1200,
"height": 800
}
}Astros Stärke – wenig Client-JavaScript, schnelles HTML – wird hier zum Vorteil: Die resultierende Desktop-App startet sofort und verbraucht kaum Ressourcen. Astros Island-Architektur erlaubt es, interaktive Komponenten gezielt einzusetzen, während der Rest der App reines HTML bleibt.
Die Neutralino-Client-Library (neutralino.js) lässt sich als Script-Tag einbinden oder über einen Import integrieren, um native Funktionen wie Dateizugriff oder Systeminformationen aus der Astro-App heraus zu nutzen.
Was nicht funktioniert: Astros serverseitige Features – SSR, API-Routes, Middleware – setzen eine Node.js-Runtime voraus. In Kombination mit Neutralinojs ist ausschließlich der Static-Output-Modus (output: 'static') sinnvoll. Für Apps, die nur ein Interface über lokale Daten legen oder eine Konfigurationsoberfläche bereitstellen, ist das kein Problem. Für datenintensive Anwendungen mit Backend-Logik braucht man entweder Neutralinojs-Extensions oder ein anderes Framework.
In der Praxis: Admin-Dashboard mit Astro und Neutralinojs
Um zu testen, wie gut die Kombination tatsächlich funktioniert, habe ich ein Demo-Projekt auf GitHub gebaut – ein Admin-Dashboard mit Astro 5, Tailwind CSS 4 und Neutralinojs. Die App zeigt auf mehreren Seiten, wie die nativen APIs im Alltag funktionieren: Das Dashboard liest live Systeminformationen (RAM, OS, Hostname) über Neutralino.computer und Neutralino.os. Eine Aufgabenverwaltung nutzt Neutralino.storage als Key-Value-Store für ein Kanban-Board. Die Projektverwaltung persistiert verschachtelte JSON-Strukturen über Neutralino.filesystem. Und eine Export-Seite kombiniert native Speichern-Dialoge (Neutralino.os.showSaveDialog) mit Clipboard-Zugriff.
Das Ergebnis hat mich überzeugt: Für interne Tools, Konfigurations-Oberflächen oder kleine Verwaltungs-Apps reicht Neutralinojs vollkommen aus. Der Entwicklungszyklus ist extrem kurz – Astro baut in den resources/-Ordner, Neutralinojs verpackt das als native App. Kein Build-Pipeline-Drama, kein Framework-Overhead. Die App startet sofort, fühlt sich schnell an und die nativen APIs decken die typischen Anforderungen ab, ohne dass man sich in ein neues Ökosystem einarbeiten muss.
Wann Neutralinojs die richtige Wahl ist
Neutralinojs eignet sich besonders für bestimmte Szenarien:
Interne Tools und Utilities: Kleine Werkzeuge, die auf mehreren Plattformen laufen sollen – Konfigurations-Editoren, Log-Viewer, Datei-Manager. Hier zählt die schnelle Entwicklung mit bekannten Webtechnologien mehr als ein ausgereiftes Plugin-Ökosystem.
Prototypen und Proof-of-Concepts: Wenn man schnell validieren will, ob eine Desktop-App-Idee funktioniert, ist Neutralinojs der schnellste Weg von der Webseite zur Desktop-App. Kein Rust lernen, kein Electron-Overhead einrichten.
Ressourcensensible Umgebungen: Auf älteren Rechnern oder in Umgebungen mit begrenztem Speicher macht der Unterschied zwischen 2 MB und 150 MB einen realen Unterschied.
Kiosksysteme und Embedded-Anwendungen: Feste Installations-Szenarien, in denen die Webview-Abhängigkeit kontrollierbar ist und die App-Größe zählt.
Für produktionskritische Consumer-Apps mit hohen Anforderungen an Sicherheit, konsistentes Rendering und eine breite Plugin-Infrastruktur bleiben Electron oder Tauri die sicherere Wahl.
Einordnung
Neutralinojs löst ein reales Problem: Desktop-Apps mit Webtechnologien müssen nicht 150 MB groß sein. Der Ansatz, den System-Webview zu nutzen statt einen eigenen Browser mitzuschleppen, ist konzeptionell überzeugend und technisch sauber umgesetzt.
Gleichzeitig ist das Projekt dort, wo Tauri vor drei Jahren war – funktional, vielversprechend, aber noch nicht im Mainstream angekommen. Das kleinere Ökosystem, die Abhängigkeit von einem Hauptmaintainer und das fehlende Installer-Tooling sind keine Showstopper, aber Faktoren, die man in die Entscheidung einbeziehen sollte.
Für Teams, die bereits mit Astro oder anderen Static-Site-Generatoren arbeiten und eine leichtgewichtige Desktop-Hülle brauchen, ist Neutralinojs einen ernsthaften Blick wert. Der Einstieg ist niedrigschwellig, die Lernkurve flach – und wenn die Anforderungen wachsen, ist der Wechsel zu Tauri ein nachvollziehbarer nächster Schritt.