Warum ist Claude eine Electron-App?

 (dbreunig.com)
10 Punkte von GN⁺ 2026-02-22 | 1 Kommentare | Auf WhatsApp teilen
  • Electron ist ein Framework, mit dem sich Desktop-Apps auf Basis von HTML, CSS und JS erstellen lassen, die Windows, Mac und Linux gleichzeitig unterstützen; zahlreiche Apps wie Slack, Discord und VS Code setzen darauf
  • Da jede App jedoch die Chromium-Engine separat mitliefert, sind sie groß, es kommt zu Latenz- und Nichtreaktionsproblemen, und auch die Integration in OS-Funktionen ist eingeschränkt
  • Seit Coding Agents auf Basis von Spezifikationen und Tests plattformabhängig nativen Code generieren können, scheint der Vorteil von Electron kleiner zu werden
  • In der Praxis können Agents die Entwicklung jedoch nur bis zu 90 % automatisieren, während die letzten 10 % aus Ausnahmebehandlung und Wartung weiterhin schwierig und personalabhängig bleiben
  • Deshalb gibt es selbst bei der Claude-App von Anthropic trotz fortschreitender Agent-Technologie weiterhin praktische Gründe für den Einsatz von Electron

Vorteile und Grenzen von Electron

  • Electron ermöglicht es, mit Webtechnologien plattformübergreifende Desktop-Apps zu entwickeln
    • Eine einzige Codebasis unterstützt Windows, Mac und Linux
    • Bestehender Web-App-Code lässt sich wiederverwenden, was die Entwicklungseffizienz erhöht
  • Zu den Nachteilen zählen größere App-Pakete und schlechtere Performance
    • Jede App enthält ihre eigene Chromium-Engine und erreicht dadurch schnell mehrere hundert MB
    • Es treten Probleme wie geringere Reaktionsgeschwindigkeit und eine schwächere Integration in OS-Funktionen auf
  • Einige Probleme lassen sich durch OS-spezifische Optimierungen verbessern, doch der strukturelle Vorteil von Electron fördert das nicht besonders

Das Aufkommen von Coding Agents und die Erwartungen

  • In letzter Zeit zeigen Coding Agents die Fähigkeit, auf Grundlage von Spezifikationen (spec) und Tests Implementierungen zwischen Sprachen und Plattformen hinweg zu automatisieren
  • Theoretisch lassen sich mit einer Spezifikation und einem Testsatz native Apps für jede Plattform erzeugen
  • Dadurch entsteht die Aussicht, dass kleine, fokussierte Teams leistungsstarke native Apps für einen breiten Markt bereitstellen können

Der Fall Claude und Anthropic

  • Anthropic hat einen Rust-basierten C-Compiler mit einem Coding Agent implementiert, stieß jedoch im letzten Schritt an Grenzen
    • Beim Hinzufügen neuer Funktionen oder beim Beheben von Bugs wurden bestehende Funktionen immer wieder beschädigt
    • Das Ergebnis war zwar beeindruckend, wurde aber als für den praktischen Einsatz ungeeignet bewertet
  • Auch die Claude-Desktop-App wurde auf Basis von Electron entwickelt und wird als langsame, fehleranfällige und große App erwähnt

Die Schwierigkeit der „letzten 10 %“

  • Coding Agents erledigen die ersten 90 % der Entwicklung schnell,
    doch Ausnahmebehandlung und Wartung in realen Umgebungen bleiben weiterhin komplex und erfordern menschliches Eingreifen
  • In echten Nutzerumgebungen häufen sich unerwartete Szenarien, sodass die Entwicklung nie wirklich abgeschlossen ist
  • Wenn für jede Plattform eine eigene App gebaut wird, verdreifachen sich Bugs und Supportumfang, was die Wartung deutlich belastet
    • Electron entschärft dieses Problem teilweise durch einen gemeinsamen Wrapper

Warum Electron weiter genutzt wird

  • Selbst wenn spezifikationsbasierte Entwicklung möglich ist, bleiben die Entwicklungskosten und der Wartungsaufwand der letzten 10 % bestehen
  • Trotz der Fortschritte bei Agent-Technologien ist der Vorteil einer einzigen Codebasis in Electron in der Praxis weiterhin relevant
  • Zum jetzigen Zeitpunkt wird Electron noch immer als vernünftige Wahl angesehen
  • Coding Agents machen erstaunliche Fortschritte, sind als vollständiger Ersatz aber noch unzureichend

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-22
Hacker-News-Kommentare

  • Boris vom Claude-Code-Team hier
    Wir hatten früher Ingenieure, die an Electron gearbeitet haben, daher bestand eine Präferenz dafür, es nicht nativ umzusetzen.
    So kann man Code zwischen Web und Desktop teilen und dadurch dieselbe UI/UX beibehalten.
    Natürlich ist alles eine Frage von Trade-offs, daher könnte sich das in Zukunft ändern.

    • Aus Nutzersicht würde ich selbst mit etwas weniger Funktionen lieber weniger CPU-Verbrauch und eine ruckelfreie UI haben.
      Ich denke, das ließe sich auch ohne Stack-Wechsel durch Performance-Optimierung lösen. Bei Mobile-Apps ist es genauso.
    • Wenn Coding angeblich schon ein gelöstes Problem ist, frage ich mich, warum man immer noch den einfachsten Tech-Stack verwendet.
    • Firmen wie Anthropic sagen bei AI-Coding-Tools, dass Portierungen zwischen Sprachen einfach seien, handeln in der Praxis aber anders.
      Das ist eine gute Lektion darin, dass Taten wichtiger sind als Worte.
    • Jemand teilte einen YouTube-Link mit dem Kommentar: „Bist du das?“
      Wenn ja, könne man Claude doch einfach scherzhaft sagen: „Mach das bitte nicht beschissen.“
    • Interessanter als die Frage, ob es auf Electron basiert, ist, ob man, falls man native Apps für drei Plattformen bauen müsste,
      AI-Agenten allein mit Spezifikationen und Tests auch die Wartung übernehmen lassen könnte.
      Gerade angesichts der Grenzen von Modellen wie Opus 4.6 wäre spannend, was dabei herauskäme.

  • Warum Code nicht kostenlos ist, ist ziemlich klar.
    Unser Team hat Claude sechs Monate lang intensiv genutzt, aber die Bug-Rate ist immer noch da.
    AI ist keine Universallösung.

    • In etwa einem Jahr wird wahrscheinlich niemand im Team mehr verstehen, woher diese Bugs kommen.
      Wenn man Denken an AI auslagert, verliert man die mentale Landkarte des Systems.
    • Erst vor rund drei Monaten kamen Modelle heraus, die dauerhaft coden können, und selbst vor 15 Tagen gab es noch große Verbesserungen.
      Dass jetzt schon gefragt wird, warum nicht alles mit AI neu geschrieben wird, ist schon komisch.
    • Das erinnert an Shens Meme „I’m stupid faster“.
      Siehe Imgur-Link.
      AI-Coding-Agenten sind vielleicht noch nicht ganz auf diesem Niveau, aber vor schnelleren Fehlern sollte man sich hüten.
    • Dann frage ich mich allerdings, warum Claude nicht gleich auch QA-Tests übernimmt.

  • Auch OpenAIs Browser ist vier Monate nach dem Release immer noch nur für macOS verfügbar.
    Obwohl er bereits auf einer Cross-Platform-Engine läuft, ist die langsame Ausweitung merkwürdig.

    • Wahrscheinlich liegt es eher an einer schwachen Nutzerakzeptanz.

  • Die Formulierung „Free as in puppy“ war witzig.
    Angeblich begann der ursprüngliche Titel mit „If code is free,“.

    • Ich fand den Kommentar so lustig, dass ich sogar den Blog gesucht habe, und er war wirklich großartig.
    • Jemand fragte scherzhaft: „Ich bin ein Welpe, ich verstehe das nicht.“
    • Dann ging der Humor weiter mit: „Ist das so ähnlich wie ein alter deutscher Wagen, der kostenlos ist?“

  • Dieser Artikel und der ganze Thread wirken wie ein typisches HN-Streitmuster.
    Immer wieder dieselbe Konstellation: „AI schlecht“, „JavaScript schlecht“, „Electron schlecht“.
    Electron ist praktisch eine „vierte OS-Plattform“, aber viele Entwickler verstehen das nicht.

    • Ich finde trotzdem, alle Electron-Apps sollten durch native ersetzt werden.
      Viele Apps sehen heute wie zusammengeflickte Websites aus, mit Stilbrüchen und vielen Bugs.
      Es fühlt sich einfach viel besser an, eine native Mac-App zu bauen.
    • Nicht Code ist der Kostenfaktor, sondern Ingenieure.
      Electron hat Vorteile, aber es wird kaum pro OS optimiert.
      Es gibt auch viele schlechte native UIs, und am Ende hängt alles davon ab, wie Menschen den Code schreiben.
      Wenn Claude ohnehin ein CLI-Tool anbietet, ist die Wahl von Electron nachvollziehbar.
    • Als Autor des Artikels gesagt: Ich habe nie behauptet, dass AI schlecht sei.
      Ich habe die Vorteile von Electron anerkannt und auch erklärt, warum man sich dafür entscheidet.
      Ich fand nur interessant, dass es selbst auf einem Mac Studio mit 64 GB RAM langsam ist.
    • Dass ein 30-Milliarden-Dollar-Unternehmen so eine UX ausliefert, ist schwer nachvollziehbar.
      Sogar npm-Abhängigkeiten standardmäßig mitzuliefern wirkt wie mangelnder technischer Stolz.
      Das passt nicht zum Slogan, man stelle „die besten Talente“ ein.
    • Selbst mein Mac mit 24 GB nutzt wegen Electron-Apps ständig Swap.
      Ich mag JavaScript, aber der RAM-Verbrauch ist verrückt.

  • Anthropic hat nie gesagt: „Code ist kostenlos“.
    Sie haben Produktivitätssteigerung betont und schreiben tatsächlich den Großteil ihres Codes mit LLMs.
    Wenn man Kritik üben will, sollte man keine Strohmänner aufbauen, sondern reale Probleme benennen.

    • Trotzdem bleibt die Frage: Wenn diese Produktivität so hoch ist und man so teure Ingenieure hat,
      warum kommt dann nichts Besseres dabei heraus?
    • Der Leiter von Claude Code sagte erst vor ein paar Tagen, „Coding ist fast ein gelöstes Problem“.
      Siehe das Interview im Lenny’s Newsletter.
    • Tatsächlich gibt es viele Leute, die behaupten, „Code sei fast kostenlos“.
      Dieser Artikel scheint sich eher gegen solche Leute zu richten.

  • Felix hier. Ich verantworte die Electron-Apps für Claude Code Desktop und Claude Cowork.
    In unseren Apps steckt auch ziemlich viel Rust-, Swift- und Go-Code.
    Warum wir Electron verwenden und warum wir unsere eigene Engine ausliefern,
    erklären wir ausführlich in der offiziellen Dokumentation.
    Electron ist nur ein Werkzeug, und wenn nötig, würden wir auch etwas anderes nutzen.

    • Lassen wir die Electron-Debatte beiseite: Die App hat viele UI/UX- und Performance-Probleme.
      Der CEO hat gesagt, Coding sei fast ein gelöstes Problem — da möchte man schon fragen, warum dann so ein Ergebnis herauskommt.
    • Manche meinen auch, bei einem vollständig AI-getriebenen Code gäbe es solche Trade-offs gar nicht erst.

  • Ich hatte Probleme beim Claude-Login.
    Der Browser hing in einer Endlosschleife beim Laden fest, und ein Klick auf Login leitete zur Registrierung weiter.
    Dass selbst solche Grundfunktionen instabil sind, ist für die „Zukunft des Codings“ etwas enttäuschend.

  • Code ist niemals kostenlos.
    Am Ende bezahlt man immer in irgendeiner Form dafür.
    Selbst wenn AI den gesamten Code schreibt, braucht man jemanden, der ihn versteht.
    Die Fähigkeit, Handbücher zu lesen, ist eine Stärke von Hackern,
    und ein Unternehmen, das nicht weiß, wie sein eigenes Produkt funktioniert, ist gefährlich.

  • Ich denke, dass Claude Electron nicht aus technischen, sondern aus kulturellen Gründen verwendet.
    Für ein Startup ist Electron vernünftig,
    aber ein großes Unternehmen sollte in native App-Qualität und UX investieren.
    Dass man es trotz möglicher automatisierter Entwicklung immer noch nicht tut,
    zeigt, dass die heutige Entwicklerkultur den Willen verloren hat, „die bestmögliche Software“ zu bauen.