suji - eine Electron-Alternative

Eine mit Zig gebaute Electron-ähnliche Lösung.
Der Titel ist ehrlich gesagt etwas großspurig formuliert, aber eigentlich ist es einfach ein mit Zig gebautes Desktop-Framework.
Ich denke, Electron ist in Wahrheit ein Framework, dem man bei der Entwicklung von Desktop-Apps kaum aus dem Weg gehen kann.

Gerade wenn man macOS- und Windows-Umgebungen gleichzeitig berücksichtigen und dabei schnell produktiv sein will, gibt es meiner Meinung nach kaum ein Framework, das so attraktiv ist wie Electron.

Man kann das JS-Ökosystem unverändert nutzen, es ist am Markt bewährt (vscode, slack, discord usw.),

und weil es so universell einsetzbar ist und viele Vorteile hat, wird es auch an vielen Stellen verwendet — entsprechend sind aber auch seine Nachteile weithin bekannt, und es bekommt viel Kritik ab.

Ich gehöre ebenfalls zu den Nutzern, die damit unzufrieden sind.

Deshalb habe ich Tauri ausprobiert, aber auch dort störten mich die

chronischen Einschränkungen(?) durch die System-WebView sowie die Tatsache, dass die Backend-Sprache bei Tauri auf Rust beschränkt ist,

bei Electron auf Node beschränkt ist

und bei Wails auf Go beschränkt ist.

Natürlich kann man mit FFI auch andere Sprachen einbinden, aber ...

Gerade in einer Zeit wie heute, in der Sprachbarrieren stark gefallen sind, gefiel mir nicht, dass ein Framework sprachliche Einschränkungen mit sich bringt.

zig, rust, go, lua, node

können jeweils als Backend-Sprache gewählt werden, und man kann sogar mehrere Sprachen gleichzeitig auswählen und das Backend mit mehreren Sprachen konfigurieren.

Ich plane, fortlaufend weitere Backend-Sprachen hinzuzufügen.
Python und Ruby auch.

Da mehrere Sprachen eingebunden werden können, können die einzelnen Backend-Sprachen auch per IPC miteinander kommunizieren.

Wenn man zum Beispiel SQLite aufruft, muss man unter Node

better-sqlite3 installieren, aber im Fall von SQLite ist es auch als integriertes Plugin enthalten, und Node kann Zig direkt aufrufen und verwenden.

Es lässt sich auch für mobile Plattformen bauen, aber bisher ist abgesehen von macOS alles noch instabil.
Nur auf iOS kann Node aus Richtliniengründen nicht als Backend-Sprache verwendet werden.

Derzeit ist macOS tatsächlich in einem Zustand, in dem Builds und Produktivbetrieb möglich sind, während Windows und Linux noch etwas Nacharbeit brauchen.
Unterstützung für Mobile ist ebenfalls geplant.

Wegen der Nachteile der System-WebView, die ich bei Tauri erlebt habe,

plane ich auf dem Mac keine System-WebView zu verwenden.

API und Nutzung habe ich so weit wie möglich an die API von Electron angelehnt,

und weil es Dokumentation und Spezifikationen gibt, mit denen AI leicht entwickeln kann, reicht es praktisch schon, nur den Doku-Link anzugeben, und E2E-Validierung wird selbstständig durchgeführt. Deshalb kann man es als ein Framework sehen, das bei der AI-Produktivität anderen konkurrierenden(?) Frameworks deutlich überlegen ist.

Eigentlich habe ich es einfach gebaut, weil mich Electron und Tauri genervt haben,
und persönlich nutze ich inzwischen suji, wenn ich DX-Tools oder Desktop-Apps entwickle.

Vielleicht habe ich falsch gemessen, aber ich bin zufriedener damit, weil in dieser Struktur die Kommunikation zwischen Sprachen schneller möglich ist als Aufrufe über FFI.

Für das Erstellen einfacher Apps und dafür, ohne Sprachbeschränkungen schnell etwas herauszuhauen, fühlt es sich für mich persönlich schneller an als Electron oder Tauri. Ich bin damit also zufrieden,

aber ich frage mich auch, ob ich nur deshalb zufrieden bin, weil ich es selbst gebaut habe, und wollte hören, was andere über diese Idee und diesen Ansatz denken — deshalb poste ich das hier!