- Nutzt keinen eingebetteten Browser, sondern den bereits im OS installierten Browser (kein WebView)
- Unterstützt Chromium & Firefox
- Kleine Bundle-Größe und schnelle Builds
- Unterstützt schnelles Prototyping mit einer einfachen, aber leistungsstarken API
- Unterstützung für Deno statt Node.js (experimentell)
- Windows/Linux werden unterstützt, Unterstützung für Mac ist in Arbeit
6 Kommentare
Scheint Wails zu ähneln, das ein ähnliches Konzept hat und mit Go entwickelt wurde.
Es wirkt wie eine interessante Technologie, aber mir fällt kein passender Anwendungsfall dafür ein.
Ist das nicht eine Art, die nur die Nachteile der Methode zum Einbetten eines Webbrowsers und der Verwendung von WebView zusammenbringt..?
Geht es nicht darum, die Bundle-Größe zu reduzieren und Speicher zu sparen?
Ich habe bei beiden Punkten meine Zweifel.
Gluon wird nämlich als Struktur beschrieben, bei der sowohl ein Webbrowser ausgeführt wird als auch NodeJS, das diesen Webbrowser steuert. Es ist gut möglich, dass der komplette Webbrowser genauso viel oder sogar mehr Speicher als eine WebView-Komponente benötigt — wegen des UI/UX-Teils — und dann kommt noch NodeJS obendrauf. Ob das wirklich Speicher spart, bezweifle ich ...
Sogar die dort angegebene Bundle-Größe für die Website basiert auf der Annahme, dass „NodeJS bereits auf dem System installiert ist“, weshalb die Größe so ausfällt; und bei der Build-Zeit startet die Tauri-Seite mit einem vollständigen Cold Build, einschließlich der Rust-Crates, ganz von vorn ...
Es wirkt ungefähr wie ein mit Node umgesetztes Konzept ähnlich wie bei Tauri (Verwendung des im System vorhandenen Browsers) ...
Wenn bestehende Browser-Instanzen wiederverwendet werden, spart das natürlich Speicher. Bei Electron-Apps besteht derzeit das Problem, dass jede App ihre eigene Electron-Engine in den Speicher laden muss.