Was ist von Desktop-Anwendungen, die in JavaScript geschrieben sind, zu halten?
JavaScript kennt man eigentlich aus dem Web. Es für die dynamische Gesaltung von Websites eingesetzt. Mit dem Framework Electorn können Desktop-Anwendungen in JavaScript entwickelt werden. Da läuft unter der Haube dann der Chromium-Browser und Node.js. Im Grunde ist eine Electron-Anwendung also eine lokale Website.
Das ganze hat dann ein paar kleine Nachteile: Wer schon einmal eine Electron-Anwendung genutzt hat, stellt schnell fest, dass die extrem viel Speicher verbrauchen und unheimlich langsam sind. Von den häufigen Sicherheitslücken, die entdeckt wurden, fange ich gar nicht erst an.
Ich finde es eine Seuche, dass diese komischen Hipster-Techniken aus dem Web den Desktop erobern wollen.
Gibt es also irgendwelche Vorteile, die Electron und hippe JavaScript Desktopanwendungen haben oder überwiegen die Nachteile.
Das Ergebnis basiert auf 8 Abstimmungen
8 Antworten
Typische "Umfrage" bei dem der Fragende das gewünschte Ergebnis schon vorweg nimmt. Bis zu dem Absatz
Ich finde es eine Seuche, dass diese komischen Hipster-Techniken aus dem Web den Desktop erobern wollen.
fand ich die Frage eigentlich gut. Ich bin auch nicht der Meinung dass Javascript besonders für Desktop geeignet ist. Deine Formulierung zeigt aber, dass es dir nicht um sachliche Argumente geht sondern nur darum, deine vorgefertigten Meinungen zu präsentieren.
Wow, jetzt hat du mich argumentativ völlig in die Ecke gedrängt. Ich gebe auf.
Das Problem ist, dass zu viele nicht mehr programmieren, sondern die Nutzung einer Programmiersprache lernen, die sie dann in jeder Situation nutzen wollen. Mit einer Tabellenkalkulation lassen sich auch Warenwirtschaftssysteme erstellen ... ob das sinnvoll ist, sei dahingestellt.
Genauso kann man einen Nagel mit einer Schere in die Wand hauen. Angesichts der Mühe und der Kollateralschäden wird derjenige beim nächsten mal einen Hammer haben. Im IT-Bereich läßt sich der Bezug zu den Kollateralschäden leider selten 1:1 spüren. Da werden dann gerne andere Sündenböcke gesucht.
Notiz am Rande: Es gibt nicht wenige, die in Java das Einführen der Annotations mit dem Untergang der Programmiersprache gleichsetzen. In der Tat ist es sehr gefährlich, was da teilweise passiert. Annotations, die das Verhalten einer Klasse massiv verändern. Dass du ohne tiefste Kenntnisse eines Frameworks dem Source-Code nicht mehr ansiehst, was er tut.
Andersherum gibt es viele, die in JavaScript das Prototyping u.ä. bejubeln oder verteufeln, sich das in Java wünschen oder in anderen Programmiersprachen.
Die Wahrheit liegt in etwas völlig anderem: Heutzutage will sich keiner mehr das gönnen, was eine wahre Kunst ist: Durchdachte Software-Architektur und Sprach-Semantik. Das Echo kommt hinterher: Wenn selbst der Entwickler, der etwas "verbrochen" hat, nach einem halben Jahr seinen eigenen Code nicht mehr kapiert. Wenn man das einmal dahin geschmierte nach einem Jahr wegwerfen und neu machen muss, weil es unmöglich zu warten und zu erweitern ist oder man Angst hat, irgendeine Code-Zeile zu verändern.
Tja, und dann kommt man in ein junges Startup und sie sagen "Wir wollen Meter machen, wir wissen gar nicht, was ein Software-Architekt ist und wir haben dafür kein Geld". Selbst Schuld :-)
Gibt es also irgendwelche Vorteile, die Electron und hippe JavaScript Desktopanwendungen haben oder überwiegen die Nachteile.
Einige. Zum einen wäre da die schiere Prävalenz von Entwicklern, die JS beherrschen und damit einhergehend die weite Verbreitung und das Vorhandensein von unendlich vielen Bibliotheken, mit denen sich Teilfunktionen schnell und sicher realisieren lassen.
Zum anderen ist es so recht einfach seine Anwendung sowohl als Desktop-Anwendung, als auch als klassische Webanwendung zur Verfügung zu stellen ohne großen Portierungsaufwand.
Dann hätten wir da noch die Betriebsystemunabhängigkeit.
Ich finde es eine Seuche, dass diese komischen Hipster-Techniken aus dem Web den Desktop erobern wollen.
Das ist ein ziemlich unqualifiziertes Statement, dass du dir hättest sparen können und nur deine guten Argumente (Sicherheit und Ressourcenauslastung) gegen Electron verwässert.
... das Vorhandensein von unendlich vielen Bibliotheken, mit denen sich Teilfunktionen schnell und sicher realisieren lassen.
So wie bei node.js, wo "Hello World" in Abhängigkeiten zu Drittmodulen ertrinkt?
So etwas hat nichts, aber auch gar nichts, mit sauberer Software-Entwicklung zu tun. Und wenn es noch so einfach / komfortabel / anfängerfreundlich ist.
Das ist - gelinde gesagt - ein riesen Haufen Mist, und dieser besagte Mist zieht sich durch die gesamte JavaScript-Welt, egal ob in Form von node, Electron, vue.js, WebAssembly, ... so ziemlich alles was mit JS in Berührung kommt, widerspricht dem, was man gemeinhin als guten Stil, defensive Programmierung, oder einfach "Qualität" bezeichnet.
JS-Entwickler neigen zum Codebloat, und das ist nix Positives! :)
Das Argument höre ich häufig. Die Puristen unter den Software-Entwicklern würden am liebsten für jede Anwendung ihr eigenes OS schreiben, damit ja nicht eine Bibliothek mitgeladen wird, die nicht gebraucht wird.
Effizient ist das nur, wenn man Arbeitszeit nicht mit betrachtet. Hardware ist billig.
Und Qualität einer Software richtet sich am Ende des Tages nach dem Mehrwert den sie für den Benutzer stiftet, nicht danach wie viel gute Gefühle sie beim Entwickler erzeugt.
Und bevor du mir mit Wartbarkeit kommst: Ich sage nicht, dass man nach belieben alles zusammenkippen und dann vergessen soll. Ich will nur darauf hinweisen, dass es im realen Leben mehr Aspekte als "schönen Code" gibt.
Man muss immer abwägen wo der ideale Kompromiss ist.
Das, was du schreibst denken auch viele Startups ... und dann gibt es einen Datenreichtum, der Ruf ist ruiniert, und die Firma meldet Konkurs an.
Wenn etwas gegen ordentliche Code-Qualität spricht, dann sollte man in Erwägung ziehen, dass es evtl. falsch ist.
Software ist nun mal Code, und wenn der nicht ordentlich ist, dann ist es die Software auch nicht.
Was du sagst ist: "Pfuschen ist OK, solange man es verkaufen kann". Da bin ich anderer Meinung.
Aber - um auf das ursprüngliche Thema zurück zu kommen - du sagst ja selbst, dass Electron Bloatware ist. Von daher sind wir uns wohl einig. :)
Was du sagst ist: "Pfuschen ist OK, solange man es verkaufen kann". Da bin ich anderer Meinung.
Nein, das sage ich nicht.
Ich sage, dass Code Qualität nicht das einzige Kriterium ist und es andere Faktoren gibt, die in Erwägung gezogen werden müssen.
Du argumentierst aus der Warte eines Entwicklers und das ist auch völlig korrekt so. Das ist deine Aufgabe, dafür wirst du bezahlt (hoffentlich ;)). Aber die Welt endet nun mal nicht beim Kompiler ;)
Wenn ich nicht komplett falsch informiert bin setzen einige sehr große und erfolgreiche Unternehmen (Google, Twitter, Facebook & Co.) JS ein und pushen dies auch Massiv. Angular, Node, React sind alles Frameworks die von den "Großen" auf die Welt losgelassen wurden.
Ich halte es für ein bisschen vermessen, dass einfach so ab zu tun und zu sagen "Ich weiß es besser".
Man kann über Google & Co. ja denken was man möchte, aber ihren Erfolg kann man nicht verleugnen.
Aber - um auf das ursprüngliche Thema zurück zu kommen - du sagst ja selbst, dass Electron Bloatware ist. Von daher sind wir uns wohl einig. :)
Korrekt. Ich find's nur nicht so schlimm wie du.
Nun, das gleiche kann man über Flash sagen, und ich habe damals ähnlich gegen Flash argumentiert, und was soll ich sagen: Offensichtlich wusste ich es tatsächlich besser. :)
Es ist nicht vermessen, wenn man Electron als Bloatware bezeichnet, sondern einfach nur eine Tatsache. Dass ein "Hello World" bei node.js über 900 Abhängigkeiten hat, ist mit nichts zu rechtfertigen.
Wartbarkeit spielt eine Rolle und ist in der ISO 25010 festgehalten.
Software ist nun mal Code, und wenn der nicht ordentlich ist, dann ist es die Software auch nicht.
Du machst Software-Qualität also von der Anzahl der Abhängigkeiten abhängig und in erster Linie bzw. nur davon? Diese Denkweise ist - mit Verlaub - völliger Unsinn.
Selbst als Entwickler ist diese Argumentation Unsinn. Eine gute Software-Qualität hat nicht nur nach ISO-Standard sehr viele Einflussfaktoren. Die Anzahl der (impliziten) Abhängigkeiten ist tatsächlich exakt keines davon. Das sogar aus gutem Grund.
Denn nicht die Anzahl der Abhängigkeiten beeinflusst die messbare Software-Qualität, sondern die Klarheit der Schnittstellen, die Klarheit in der Verwendung der Abhängigkeiten und ggf. auch die Kopplung mit den eigenen Modulen.
Nun, das gleiche kann man über Flash sagen, und ich habe damals ähnlich gegen Flash argumentiert, und was soll ich sagen: Offensichtlich wusste ich es tatsächlich besser. :)
An dem Punkt der Diskussion bist du - mit Verlaub - auf einem Trollniveau angelangt. Der Niedergang von Flash hat mit der Anzahl der Abhängigkeiten so ziemlich nichts zu tun.
Dass ein "Hello World" bei node.js über 900 Abhängigkeiten hat, ist mit nichts zu rechtfertigen.
Ein Hello World ist aber nun mal nicht das, wofür man es einsetzt. Ich setze auch keinen Full-Stack-Spring mit Kafka usw. für ein Hello World ein. Das ergibt 0 Sinn. Du kannst nicht völlig absurde Anwendungsfälle aufstellen und die dann als Totschlag-Argument auf Gott und die Welt loslassen.
Schau mal, was alles an DLLs oder SOs geladen wird für ein natives GUI-Hello-World-Programm, das ein hübsches sich drehendes Hello World anzeigt. Das wäre auch ein Totschlag-Argument gegen C++ und Kollegen. Wenn man deiner Logik folgt. Ergibt irgendwie keinen Sinn oder?
Dass ein "Hello World" bei node.js über 900 Abhängigkeiten hat,
console.log("Hello World")
Wo sind da Abhängigkeiten? Das ist reine Polemik.
Es geht um node.js ... mach ein neues leeres Projekt und zähle die Abhängigkeiten. In diesem Falle hätte auch dein console.log() Beispiel die selbe Anzahl von Abhängigkeiten!
Du machst Software-Qualität also von der Anzahl der Abhängigkeiten abhängig und in erster Linie bzw. nur davon? Diese Denkweise ist - mit Verlaub - völliger Unsinn.
Das mag in der JS-Welt anders sein, aber allgemein gilt: Übermäßig viele Abhängigkeiten == schlechter Stil bzw. schlechtes Design.
Denn nicht die Anzahl der Abhängigkeiten beeinflusst die messbare Software-Qualität, ...
Ähm, doch! Exakt DAS ist der Fall. In welchem Bereich entwickelst du denn bitte Software???
Ein Hello World ist aber nun mal nicht das, wofür man es einsetzt. Ich setze auch keinen Full-Stack-Spring mit Kafka usw. für ein Hello World ein. Das ergibt 0 Sinn. Du kannst nicht völlig absurde Anwendungsfälle aufstellen und die dann als Totschlag-Argument auf Gott und die Welt loslassen.
Es ging ursprünglich um Abhängigkeitsbloat, und der ist - unabhängig von welchem Projekt - bei Electron einfach gegeben.
Schau mal, was alles an DLLs oder SOs geladen wird für ein natives GUI-Hello-World-Programm, das ein hübsches sich drehendes Hello World anzeigt.
20 dynamische Bibliotheken unter Linux mit qt.
Das mag in der JS-Welt anders sein, aber allgemein gilt: Übermäßig viele Abhängigkeiten == schlechter Stil bzw. schlechtes Design.
Nochmal. Das ist völliger Quatsch. Das ist in keiner Welt so und - egal in welcher Programmiersprache - behauptet das niemand.
Ähm, doch! Exakt DAS ist der Fall. In welchem Bereich entwickelst du denn bitte Software???
Ich entwickele Software für über 100tsd Anwender, die diese Software täglich nutzen. In einer Entwickler-Mannschaft von mehr als 1000 Entwicklern. Enterprise-Software. Im Banken-Sektor. Seit über 2 Jahrzehnten. Magst du mir nun glauben oder auch nicht.
Es ging ursprünglich um Abhängigkeitsbloat, und der ist - unabhängig von welchem Projekt - bei Electron einfach gegeben.
Ich habe nicht gesagt, dass der nicht gegeben ist. Ich habe gesagt, dass dies kein Kriterium für die Software-Qualität ist.
20 dynamische Bibliotheken unter Linux mit qt.
Und das für ein einfaches Hello World. Was für ein "Abhängigkeitsbloat". Wo ein einfaches hello World doch mit weniger als 1KB und nur 2 oder 3 dynamischen Abhängigkeiten auskommen muss.
Du merkst immer noch nicht, wie unsinnig dein Argument ist?
Nochmal. Das ist völliger Quatsch. Das ist in keiner Welt so und - egal in welcher Programmiersprache - behauptet das niemand.
Du hast als Entwickler noch nie von der "Abhängigkeitshölle" gehört?
https://en.wikipedia.org/wiki/Dependency_hell#Problems
Das ist ein seit Jahrzehnten bekanntes Problem, welches es zu vermeiden gilt. Und das ist Konsens auf eigentlich allen Plattformen bei allen möglichen Programmiersprachen.
Probleme zu lösen, indem man noch einen Layer API-Müll drauf kippt, ist kein guter Stil!
Und das ist übrigens auch einer der Hauptgründe, warum Google Fuchsia als Alternative zu Android entwickelt: Android hat einfach viel zu viele API-Schichten und zu viele Abhängigkeiten. Aber das ist ein anderes Thema ...
Ich entwickele Software für über 100tsd Anwender, die diese Software täglich nutzen. In einer Entwickler-Mannschaft von mehr als 1000 Entwicklern. Enterprise-Software. Im Banken-Sektor. Seit über 2 Jahrzehnten. Magst du mir nun glauben oder auch nicht.
Ich glaube dir das schon, aber das sagt ja nichts über die Qualität deiner Fähigkeiten aus. :)
Ich habe nicht gesagt, dass der nicht gegeben ist. Ich habe gesagt, dass dies kein Kriterium für die Software-Qualität ist.
Ist es aber. Oder willst du sagen, gute Software erkennt man am Bloat? Nicht ernsthaft, oder? Die andere Richtung ist korrekt: Wenn Software schlanker ist, ist sie bei weitem leichter wartbar und hat per Definition weniger Fehler.
Und das für ein einfaches Hello World. Was für ein "Abhängigkeitsbloat". Wo ein einfaches hello World doch mit weniger als 1KB und nur 2 oder 3 dynamischen Abhängigkeiten auskommen muss.
Du hast von einem hübsch animierten, sich drehenden "Hello World" gesprochen, also würfel hier jetzt mal nichts durcheinander!
Für deine ursprüngliche Aufgabe sind ca. 20 Bibliotheken nicht viel, zumal die Abhängigkeiten dabei rekursiv betrachtet werden und 2 der 20 Abhängigkeiten in Wirklichkeit gar keine *.so Bibliotheken, sondern der dynamische Linker ist.
Wenn du dich jetzt plötzlich umentschieden hast, und von einem einfachen "Hello World" redest, ist die einzige Abhängigkeit die libc, oder - falls statisch gelinkt - existieren Abhängigkeiten faktisch GAR nicht.
Bei node.js benötigt console.log() schon über 900 Dateien. Du merkst den Unterschied?
Irgendwie haben du und ich ein anderes Verständnis von "Bloatware". :)
Du merkst immer noch nicht, wie unsinnig dein Argument ist?
Sagst du das auch den weltweit anderen Millionen von Entwicklern, die versuchen, nicht in die "Dependency Hell" zu kommen?
Nochmal: Codebloat und übermäßige Abhängigkeiten sind ein gängiges Antipattern. Das habe nicht ICH mir so ausgedacht, das ist seit Jahrzehnten bekannt und Konsens.
https://jaxenter.de/mcgarr-dependency-hell-63493
Und jetzt erzähle mir noch mal, Abhängigkeitsbloat sei kein Kriterium für schlechte Software! Das Netz ist voll mit ähnlichen Vorträgen, Talks, Papers, Websites, Blogpostings, Foreneinträgen, usw.
Bloat wird - außer in deiner Seifenblase - generell als schlecht angesehen, und zwar aus vielerlei Gründen. Dass du das mit deinen 20 Jahren Berufserfahrung immer noch nicht erkannt hast, verwundert mich stark.
Du hast als Entwickler noch nie von der "Abhängigkeitshölle" gehört?
Das habe ich nicht gesagt. Liest du auch mal, was ich schreibe? Ich habe geschrieben, dass es kein Kriterium für die Software-Qualität ist. Selbst wenn man es als Problem sieht, ist nicht die Masse an Abhängigkeiten das Problem, sondern eher etwas völlig anderes, was damit einher geht und das drückt sich in anderen Dingen aus. Unklare Schnittstellen, fehlende Wartbarkeit durch Community-Inaktivität usw.
Ein echtes Problem mit Masse an Code im Sinne von Bytes hast du nur noch extrem selten. Ja, es gibt sie, die speziellen Geräte mit wenig Speicher usw. Aber das ist fernab der Einsatzzwecke für das hier angesprochene Framework. Die haben dann ohnehin oft keine Desktops, sind irgendwelche Spezial-Prozessoren in Industriemaschinen oder was weiß ich.
Die Speicherprobleme hast du kaum noch. Diese lustigen Argumente der "Dependency Hell" bezogen auf Speicherplatz, Download-Geschwindigkeiten, sind in der heutigen Zeit vollkommen albern. Wir reden hier auch nicht von Gigabytes.
Im ´übrigen sind deine weiteren Argumente der "Dependency Hell" teilweise berechtigt, teilweise aber ebenso unsinnig. Es ist ja nicht so, dass ich als Nutzer eines in sich geschlossenen Frameworks jede Dependency von Hand eintrage und mit pflegen muss. Dass eigentliche Problem für Versionskonflikte ist, dass ich keine klaren Schnittstellen habe, dass ich keine klare Architektur habe, dass niemand die Garantie übernimmt, dass das Framework in sich eine funktionierende Welt darstellt. Und das sind dann auch die eigentlichen Messgrößen für Software-Qualität.
Du hast von einem hübsch animierten, sich drehenden "Hello World" gesprochen, also würfel hier jetzt mal nichts durcheinander!
Nein, ich bin nicht derjenige, der es durcheinander wirft. Du bist es. Du verlangst von einem Framework, das überhaupt nicht auf ein einfaches Hello-World ausgerichtet ist, dass es mit Minimal-Abhängigkeiten auskommt, wenn man ein Hello-World programmiert. Das ist deine Behauptung und dein Argument für schlechte Software-Qualität. Du verlangst von einem Programm, was ein hübsch animiertes drehendes Hello-World anzeigen will, dass es genauso Schalspur sein soll wie ein einfaches Konsolen-Hello-World.
Ich halte dir nur den Spiegel vor.
Großartig finde ich zwar eigentlich etwas übertrieben aber Electron ist selten schuld dran, dass Leute damit Unsinn anstellen. Die Idee an sich ist gut. Es gibt eben viele Anwendungen die es auf Webbasis eh gibt und man möchte mit Electron dann z.B. eine schnellere, ggf. lokale Anwendung bieten.
Mit Visual Studio Code haben wir z.B. imo ein überragendes Produkt auf Electron Basis und langsam oder groß viel mehr Speicher verbrauchen tut da nix.
Größter Vorteil ist eben die Plattformunabhängigkeit, ob das Ding nun auch direkt ins Web kommt, auf dem PC läuft, dem MAC, unter Windows, Linux, auf dem Tablet oder Smartphone.
Klar sind native Anwendungen oft überlegen aber irgendwer muss diese ganze Entwicklung auch bezahlen und verwalten. Gerade kleine Teams tun sich schwer mit zig Sprachen. Sowas hat massive Auswirkungen auf den Betrieb. Wenn du der einzige bist, der sich nun mit Sprache X auskennt, dann bist du immer der Ansprechpartner.
Nach Feierabend, im Urlaub. Keiner kann dir Arbeit abnehmen, wenn das Projekt droht gegen die Wand zu fahren, kann man nicht Mitarbeiter hin- und herschieben, sondern du musst Überstunden schieben. Dein Kollege kann ja nix machen, er kennt sich mit der Sprache und der Anwendung nicht aus, hat nicht einmal die IDE oder Lizenzen dafür.
Alles in einen kleineren Ecosystem unterzubringen bringt da gerade für kleinere Firmen viele, viele Vorteile.
Mit Hipster hat das auch alles nix zutun. Ist eine Sprache wie jede andere auch. Hat ihre Vor- und Nachteile. Electron bietet dann natürlich mit den geshippten Clientcode deutliche Performancevorteile zu einer normalen Webapp. Gerade mit größeren Frameworks im Webbereich ist das eben der logische Schritt. Ebenso wenn man native Features wie Kontextmenüs und Menüs nutzen möchte bzw. ein wenig der Browserlogik entfernen möchte.
Ich finde es eben nicht sinnvoll, dass manche Menschen zwanghaft versuchen JavaScript in allen Bereichen einzusetzen. Für die einzelnen Bereiche gibt es gute und sinnvolle Sprachen. Und bei klassischen Desktop-Anwendungen ziehe ich andere Sprachen vor.
Ich hingegen arbeite in einem Betrieb und würde es mir wünschen. So gibt es oben angesprochene Probleme und wenn es hart auf hart kommt gibt es Wochen mit 100 Stunden aufwärts.
Es geht eben nicht ausschließlich um die Anwendung. Sag dem Kunden er zahlt statt 150.000 Euro, wie ggf. bei der Konkurrenz eine Million, weil du ihn eine Android, eine iOS, eine Mac, eine Linux und eine Windows App erstellst. Dafür Leute brauchst, für jede der Sprachen jemand Bereitschaft haben muss, für alle Ecken eine Wartung da sein muss, für alles Lizenzen fließen müssen.
Gut umgesetzt kann es eben super funktionieren wie Visual Studio Code zeigt. Ansonsten kann man auch mit jeder anderen Sprache grässliche Anwendungen erstellen. Als Entwickler schätze ich es auch, dass ich die Anwendungen leicht erweitern kann, was mittels Reverse Engineering und co. bei z.B. einer C++ Anwendung deutlich schwerer, sofern überhaupt möglich ist.
Während man im Webbereich sogar darauf baut mit Pluginschnittstellen.
Es gibt inzwischen sehr viele Sprache, sehr viele Frameworks, sehr viele Hypes und sehr vieles, was ständig aufs Neue erfunden und diskutiert wird. Gerade bei den Programmiersprachen ist das wohl so. Informatiker ticken so. Wirklich?
Im Grunde ist das ein extrem alter Hut. In jedem halbwegs homogen gewachsenen Framework und jeder halbwegs homogen gewachsenen Programmiersprache findest du immer wieder "Neuerungen", die man einfach woanders abgeguckt hat.
Das ist auch in sich völlig logisch. Die Welt dreht sich weiter. Man schaut sich um. Man sieht, was "andere" für Erfahrungswelten haben und versucht, diese irgendwie zu nutzen.
Die Frage nach einem "gut" oder "schlecht" ist dabei die falsche Frage. Du musst die Frage stellen, ob genau diese Sprache und genau dieses Framework "für dich" das "geeignete" ist. Das ist also sehr subjektiv. Was du als Vorteil siehst, sehen andere als Nachteil.
Electron schreibt sich folgenden Slogan auf die Fahnen: "Plattformübergreifende Desktop-Anwendungen mit JavaScript, HTML und CSS entwickeln". Wenn das genau dein Einsatzzweck ist, dann ist das für dich ein Vorteil. Wenn du aber reinrassisge Linux-Server-Anwendungen (im Regelfall konsolenbasiert) bauen willst, ist das ein extremer Nachteil, da es vollständig an deinem Ziel vorbei geht.
Andererseits kann man aber mal betrachten, wieso eigentlich vieles auf Web-Technologien ausgelegt ist. Wieso gibt es überhaupt JavaFX statt Swing zu modernisieren? Mit ein grund ist, dass man insbesondere im Bereich der Web-Oberflächen nun mal sehr gute Erfahrungswerte hat. Ich nenne nur mal das Stichwort "Responsive Design". Bringe das mal einer klassischen MFC-Anwendung oder einer Java-Scwing-Anwendung bei. Ich wünsche dir viel Spaß.
Wenn du also für deinen Einsatzzweck, deine persönliche Lernkurve und deine wichtigen Features nun eine sehr hohe Abdeckung durch Electron findest, so dass du schnell zu einem guten Ergebnis kommst, dann ist das womöglich dein Wunsch-Framework und JavaScript damit deine Wunsch-Sprache. Andere Entwickler werden womöglich zu einem anderen Ergebnis kommen. Das ist dann aber nichts, was Electron oder JavaScript gut oder schlecht werden lässt.
Im übrigen gibt es auch noch sehr viele weiche Faktoren für eine Wahl: Wie aktiv ist eine Community, wie aktiv wird die Sprache/ das Framework weiterentwickelt usw.
Das stimmt nicht.