Discord zeigt: Windows-Apps müssen Electron nicht mehr ertragen

Ist das eine komplette UI-Neufassung in einem nativen/nicht-Web-Framework? Denn falls nicht, läuft das immer noch in einem Browser, d.h. es steht bei etwa 80% des Bloat-Faktors von Electron, und was es schneller macht, ist möglicherweise (hauptsächlich?) dass sie noch nicht dazu gekommen sind, so viel Zeug hinzuzufügen wie beim regulären Client.

Discord ist ein serverseitiges Protokoll (der Client tut nicht viel außer den vom Server vorgegebenen Zustand anzuzeigen), es gibt dort sehr wenig Logik/Berechnung, die einen himmelweiten Unterschied erklären sollte.

Electron ist ziemlich großartig darin, dass es einem kleinen Team ermöglicht, eine anständige GUI-App mit ihrem vorhandenen Web-Skillset zu bauen, aber es fühlt sich auch so an, als wäre es an der Zeit für etwas Besseres.

Bei den verrückten RAM-Preisen. Es ist ziemlich frustrierend, mehrere GB fressende Anwendungen laufen lassen zu müssen, nur um ein paar grundlegende Aufgaben zu erledigen (90% ist Lesen und Schreiben von Nachrichten, im Fall von Discord). Ich verstehe, dass andere Leute vielleicht die fortgeschritteneren Funktionen (Sprachchat usw.) nutzen, aber diese könnten bei Bedarf geladen werden.

Es ist ein bisschen verrückt für mich, dass ich bequem einen ganzen Linux-Stack (+ Podman, Monitoring, Alerting und mehrere Dienste) in 512 MB RAM laufen lassen kann (mit 40% frei, gerade nachgesehen!). Mein Windows-PC braucht jedoch 5,5 GB nur um den Desktop anzuzeigen! Realistisch braucht er irgendwo zwischen 8 GB und 16 GB für etwas grundlegendes Web-Browsing und selbst dann kann es sich langsam anfühlen, wenn man ein paar Apps wie Discord im Hintergrund laufen hat.

Ich verstehe diese Idiotie nicht – es ist super einfach (ich habe es selbst alleine viele Male gemacht), eine einzige Codebasis in Qt für alle Betriebssysteme, sogar BSDs, zu haben.

Ich denke, die Leute werden super faul... "Ah, es wird ein paar Hundert MB RAM belegen, kein Problem, lass es uns ausliefern."

Es sind Unternehmen mit Milliarden oder sogar Billionen, die mit Electron Scheiße ausliefern.

Wir haben uns heutzutage so sehr an langsamen App-Start gewöhnt, glaube ich. Ich habe vor kurzem angefangen, Task Slinger [1] zu benutzen, und jedes Mal, wenn ich es starte, habe ich das Gefühl, dass es bereits lief und nur sein Fenster aufgetaucht ist. Ich wünschte, alle moderne Software wäre so.

[1]: https://taskslinger.net/

Ich habe selten eine Electron-App gemocht, sowohl wegen der Performance als auch weil es ein Gefühl von Aufgeblähtheit zu fördern scheint, mangels eines besseren Wortes. Habe VS Code ausprobiert, aber fallen gelassen, als sie anfingen, zu viel KI und zu viel Komplexität einzubauen. Sublime ist so viel besser.

Ich weiß nicht... es scheint etwas Unangenehmes an allen Electron-Apps zu geben.

Discord ist meiner Meinung nach nicht wirklich das Modell, dem man hier folgen sollte. Sie haben ihre native Android-App eingestellt und sind zu React Native gewechselt, und jetzt lassen sie React Native fallen (während Mobile laut dem Tweet ihres CTOs irgendwie "native UI" behält). Wenn sie die Code-Wiederverwendung maximieren und die Feature-Entwicklung beschleunigen wollten, hätten sie stattdessen Kotlin Multiplatform in Betracht ziehen sollen, dann hätten sie den React-Native-Umweg überspringen können, während sie tatsächlich Apps bauen, die nativ für die Plattform sind. (Rust und seine Kakophonie von UI-Frameworks sind meines Wissens nach nirgends wirklich plattformnativ. Vielleicht Pop OS, aber ich kenne niemanden, der das speziell anvisiert.)

Dieser Teil ist offensichtlich subjektiv, aber Rust als Sprache ist einfach nicht ergonomisch genug für viele der Anwendungsfälle, auf die Leute es anwenden wollen, besonders UI-Entwicklung. Die meisten Rust-UI-Bibliotheken, die ich bisher gesehen habe, verwenden entweder einen eher imperativen Stil oder versuchen, deklarativere Ansätze wie Compose UI oder SwiftUI nachzubilden, aber ohne die schöne Sprachästhetik, die das Lesen und Schreiben einfach macht. Und wenn das Gegenargument dort ist, dass LLMs dieses Zeug lesen und schreiben sollen, das ist ein ganz anderes Fass: (1) Die Ära der subventionierten Inferenz geht schnell zu Ende und (2) wenn man sowieso LLMs verwendet, warum nicht Apps pflegen, die so nativ wie möglich für jede Plattform sind?

Electron ging es schon immer darum, plattformübergreifende Apps schnell auszuliefern, auf Kosten von höherem Speicherverbrauch und potenziell schlechterer Performance. Mit oder ohne LLMs bleibt das Kernwertversprechen dasselbe. LLMs verstärken einfach die bestehenden Stärken des Frameworks.

Raycast, ursprünglich ein nativer macOS-Launcher, hat kürzlich v2 mit einer hybriden Architektur veröffentlicht. Es ist nicht Electron, aber es folgt einem ähnlichen Ansatz wie Spotifys Desktop-App und verwendet Web-Technologien innerhalb einer nativen Hülle.

Der Speicherverbrauch ist immer noch ziemlich signifikant. Es verwendet etwa 350–450 MB im Leerlauf und kann je nach Arbeitslast manchmal 1–2 GB erreichen. Der Vorteil ist, dass sie jetzt den Großteil ihres Codes zwischen macOS und Windows teilen und sich über einen reinen App-Launcher hinaus weiterentwickeln können.

Es ging schon immer um Kompromisse, und LLMs ändern das grundsätzlich nicht.