- TypeScript-basiertes Desktop-App-Framework, das Bun für den Main-Prozess und Zig für native Bindings verwendet
- Unterstützt macOS, Windows, Ubuntu vollständig und erzeugt Installer, automatische Updates und Artefakte für differenzielle Patches automatisch
- Bietet ein vollständiges Set an Desktop-Funktionen wie Fenstersteuerung, Menüs, Tastenkürzel, Zwischenablage, Dialoge, Session Storage usw. sowie eine stabile Webview auf OOPIF-Basis
- Die interne Architektur nutzt Buns FFI- und Shared-Memory-Modell, um auch in Multi-Prozess-Umgebungen effizient zu bleiben
- Entwickelt von einem Entwickler, der die Grenzen von Electron und Tauri erfahren hat und dafür 2 Jahre lang Zig, C, C++ und Objective-C gelernt hat
- Ziel ist ein integrierter Workflow, mit dem sich in 5 Minuten Code schreiben und in 10 Minuten deployen lässt
Überblick und Ziele des Electrobun-Projekts
- Architektur, bei der der Main-Prozess mit Bun läuft, das TypeScript der Webview gebündelt wird und native Bindings in Zig geschrieben sind
- Sowohl Main-Prozess als auch Webview werden in TypeScript geschrieben, während Isolation zwischen den Prozessen erhalten bleibt und schnelle, typisierte RPC-Kommunikation bereitgestellt wird
- Selbstextrahierendes App-Bundle mit einer Größe von etwa 12MB (bei Nutzung der System-Webview, größtenteils Größe der Bun-Runtime)
- Mit bsdiff-basierten differenziellen Updates kann die Patch-Größe auf minimal 14KB reduziert werden
- Ziel ist die Bereitstellung eines integrierten Workflows, mit dem man innerhalb von 5 Minuten mit dem Coden beginnen und innerhalb von 10 Minuten bis zum Deployment gelangen kann
- Mit dem Befehl
npx electrobun init lässt sich ein projektbasiertes Template starten
Hintergrund der Entwicklung
- Seit der Zeit von Visual Basic 6 wurden Desktop-Apps entwickelt; der Ausgangspunkt war die Erfahrung, in der Ära von Adobe AIR mehrere Startup-Produkte an Tausende Nutzer ausgeliefert zu haben
- Trotz mehr als 20 Jahren als früher Startup-Ingenieur beim Aufbau und der Skalierung von Produkten in Unicorn-Größe hat sich die Desktop-Entwicklungsumgebung eher zurückentwickelt
- Beim Bau von co(lab), einem hybriden Webbrowser+Code-Editor+PTY-Terminal, stieß der Entwickler auf so viele Unannehmlichkeiten, dass er sich entschloss, das Framework selbst zu bauen
- Die erste Version wurde mit Electron erstellt, doch Code Signing, Notarisierung, Distribution und Updates fühlten sich eher wie ein Kampf mit dem Framework als wie App-Entwicklung an
- Gewünscht war continuous shipping wie im Web, aber bestehende Toolchains machten das unnötig kompliziert
- Tauri wurde ebenfalls ausprobiert, doch Rust erschien nicht für alle Entwickler passend; da Bun damals noch mehrere Monate vor Version 1.0 stand, begann die Eigenentwicklung
Von macOS zu plattformübergreifend
- Anfangs konnten nur macOS-Apps gebaut werden, inzwischen werden Build und Deployment für macOS, Windows, Ubuntu als erstklassige Ziele unterstützt
- Installer, Artefakte für automatische Updates und differenzielle Patches werden alle automatisch erzeugt
- Wenn nur noch ein statischer Host (R2, S3, GitHub Releases) angebunden wird, ist das Deployment abgeschlossen
- Für differenzielle Updates kommt zig-bsdiff zum Einsatz, eine von C nach Zig portierte und mit SIMD und zstd optimierte Implementierung
- Nachdem Buns FFI stabil wurde, wurde der Großteil der zuvor geschriebenen Zig-FFI-Schicht durch Bun ersetzt
- Die Architektur entwickelte sich positiv weiter, da Bun beim Erzeugen von Workern Shared Memory verwendet und so auch in Multi-Prozess-Umgebungen effizient bleibt
Verfügbare Funktionen
- Das Framework bietet inzwischen als vollwertiges Framework plattformübergreifende Fenstersteuerung, Menüs, Tastenkürzel (accelerators), globale Shortcuts, Zwischenablage, Dialoge, Webview-Partitionen, Session Storage, Seitensuche (find-in-page) sowie Tooling für Bundling und Updates
- Die OOPIF-Implementierung (Out-of-Process Iframe) hat einen Stand erreicht, auf dem sie tatsächlich funktioniert
- Das
<webview>-Tag von Electron ist in Chromium deprecated, ohne dass bislang eine Alternative bereitsteht
<electrobun-webview> ist ein echtes „Super-Iframe“, bei dem DOM-Positionierung, Prozessisolierung und Layering korrekt funktionieren- Plattformübergreifender Betrieb ohne Cursor-Flicker und ohne Patches an der Browser-Engine
Status der Plattformunterstützung
- macOS 14+: offiziell unterstützt
- Windows 11+: offiziell unterstützt
- Ubuntu 22.04+: offiziell unterstützt
- Andere Linux-Distributionen (gtk3, webkit2gtk-4.1): Community-Support
Nächste Schritte
- co(lab) wurde vollständig auf Electrobun neu geschrieben; auf Basis der Stabilisierung von v1 soll nun der Fokus wieder intensiv auf die Entwicklung von co(lab) gelegt werden
- Das zentrale Ziel ist, das Framework so weit zu stabilisieren, dass sich darauf ambitionierte langfristige Produkte bauen lassen, ohne von platform churn erschüttert zu werden
- Die Discord-Community wächst, und Nutzer, die mit Betatests, Issue-Reports und Feedback beigetragen haben, haben die Entwicklung des Frameworks mitgeprägt
- Electrobun ist das erste große Produkt, das von Blackboard veröffentlicht wird
5 Kommentare
Dort steht, es sei eine vollständige Neuschreibung von co(lab), daher dachte ich, es gehe zusammen mit Google um die Verbesserung der Cloud-Stabilität für die Ausführung von
ipynb, aber es ist ein Entwicklungsprojekt des Blackboard-Teams, das damit überhaupt nichts zu tun hat.Trotzdem scheint es eine wichtige Erfahrung zu sein, dass sich das per
npxinstallierte OOPIF ansprechen lässt.„Code-Signing, Notarisierung, Distribution und Updates fühlen sich an, als würde man eher mit dem Framework kämpfen als die App zu entwickeln“
Im Haupttext wird der Hintergrund der Entwicklung mit der obigen Aussage beschrieben.
Tatsächlich gibt es Fälle, in denen die Auslieferung mehr Aufwand verursacht als die eigentliche App-Entwicklung. Allein dafür, dass dieses Problem behoben wurde, bewerte ich es sehr positiv.
Es scheint sich doch ziemlich leicht und unkompliziert zu machen, Zig an Flutter anzubinden.
Ohne großen Unterschied zu den Dart/C-FFI-Dokumenten...
> Ich frage mich, warum die wichtigsten Linux-Distributionen kein standardmäßiges WebView bereitstellen. Das ist ein großes Hindernis für den Ausbau des App-Ökosystems.
Bei Betriebssystemen mit GUI-Umgebung sollte WebView inzwischen wohl als Standardkomponente etabliert sein.
Hacker-News-Kommentare
Hallo, ich bin der Entwickler von Electrobun
Wir haben jetzt die stabile Version v1 veröffentlicht. Die Architektur ist festgelegt, und wenn ihr Bugs findet oder APIs braucht, die ihr in Electron/Tauri verwendet habt, hinterlasst bitte ein GitHub-Issue – ich werde das vorrangig bearbeiten
Im letzten Monat habe ich 50.000 Zeilen Code überarbeitet und die Stabilisierung abgeschlossen
Es gibt auch ein Demo-Video des mit Electrobun gebauten Open-Source-Projekts Colab (Webbrowser + Code-Editor + PTY-Terminal)
Electrobun verwendet standardmäßig die WebView des Systems, kann aber mit der Option
bundleCEFauch CEF einbinden. Strukturell ist es von WebView unabhängig, sodass es sofort durch Servo oder Ladybird ersetzt werden kann, sobald diese bereit sindAußerdem wird zu jedem Release ein automatisch komprimiertes Paket auf zstd-Basis erzeugt, um die anfängliche Downloadgröße zu verringern, während Updates mit etwa 14 KB sehr klein bleiben können
partitionangibt, tritt ein TypeScript-Fehler aufElectrobun sieht sehr vielversprechend aus. Ich werde mein nächstes Projekt damit bauen
Mit einem Full-TypeScript-Stack ist die Produktivität am höchsten. Ich freue mich über eine leichtere und schnellere Alternative zu Electron, ganz ohne Rust oder lange Compile-Zeiten
Auf Discord experimentieren viele Spieleentwickler mit Desktop-Spielen auf Basis von Electrobun
Es könnte einen Teil von Electron im Indie-Game-Markt auf Steam ersetzen
Besonders die TypeScript-Spielentwicklung mit sofortigem Reload über
bun --watch game.tsist extrem schnell und reibungslosDas Hauptproblem bei Tauri ist, dass die Qualität der System-WebView je nach OS unterschiedlich ist
Unter Linux gibt es keine offizielle WebView, und unter Windows 7 oder frühem Windows 10 wird Edge WebView nicht verwendet. Wegen solcher Unterschiede kann der Start auch mal mehr als 20 Sekunden dauern
Ich frage mich, ob man für eine Ersparnis von 100 MB solche Trade-offs in Kauf nehmen sollte
Die meisten Nutzer haben schnelles Internet, daher ist die Downloadgeschwindigkeit kein großes Problem
Ich hatte mich gefragt, ob Electrobun einen integrierten Chromium-Renderer unterstützt, aber das war in der Dokumentation nicht klar
Im Titel hätte klarer stehen sollen, dass es sich bei diesem Beitrag um einen retrospektiven Blogpost zum Projekt handelt
Das eigentliche Projekt schaut man sich besser über den Link zur offiziellen Dokumentation an
Die Hauptseite des Projekts ist hier
Die Oberfläche wirkt sauber, und da ich mit Zig vertraut bin, dürfte mir der Zugang leichter fallen als bei Rust
Wir werden diese Woche im Unternehmen eine neue Electron-App ausrollen, und ich wünschte, Electrobun wäre ein Jahr früher erschienen
Electron Builder vereinfacht Updates und den Signierungsprozess zwar teilweise, aber es bleibt trotzdem umständlich
Bei meinem nächsten privaten Projekt werde ich Electrobun ausprobieren
Im Artikel wurden die Probleme mit Notarization und Stapling erwähnt, und wenn man Xcode nicht benutzt, macht Apple diesen Prozess wirklich sehr schwierig
Auch unter Windows ist CI-Automatisierung nicht einfach. Wenn Electrobun dafür eine bessere Lösung bietet, bin ich sehr interessiert
notarize: trueIch habe mit Electrobun schon mehrfach signiert und notariell beglaubigt, ohne Probleme. Für komplexe Fälle gibt es auch einen Escape Hatch
Wenn du Hilfe brauchst, schreib mir gern per DM auf Discord. (Ich habe nichts mit Electrobun zu tun, kenne aber das Leid mit Apples Notarisierungssystem sehr gut)
Wenn eine Electron-App mehr als 500 MB groß ist, wirken die 14 MB von Electrobun wirklich sehr klein
Schade, dass Distributionen außer Ubuntu derzeit außerhalb des unterstützten Bereichs liegen
Die dazugehörige Diskussion findet sich in diesem Issue-Kommentar