Linux: Welche Programmiersprache

[jb_alvarado]

Button Design kann man in so gut wie allen empfohlenen Sprachen/Frameworks ändern. In Webapps ist man designtechnisch sogar mit am flexibelsten.

 

[TomH22]

Dart+Flutter scheinen das gleiche zu können wie Electron.
Die Buttons sehen bei beiden Systemen schrecklich aus.

Die Buttons sind Bestandteil des jeweils benutzten UI Themes. Electron selber kümmert sich garnicht darum. Vermutlich liegt es daran, dass die Tutorials ein entsprechendes Design Kit gewählt haben.

Ich glaube Du musst Dich erst mal mit den Grundlagen der Web Entwicklung auseinandersetzen.

 

[KitKat::new()]

Bei C++ muss man viele Details beachten. Das Debuggen kostet viel Zeit.

Schon mal überlegt Rust auszutesten?
Das würde die Debugging Zeit erheblich reduzieren.

Es hat zwar eine steilere Lernkurve (da du aber schon Erfahrung in C++ hast, hält sich die in Grenzen) als JavaScript, aber dafür bekommst du ein ähnlich Performances Ergebnis wie mit C++.


Es gibt da verschiedene Möglichkeiten.
Der gehypte neue Desktop "COSMIC" für Linux wird beispielsweise mit Iced (Crossplattform) entwickelt:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Gibt aber einige weitere gute Optionen.

Auf Elektron würde ich nur im äußersten Notfall setzen.
Für Endnutzer ist das durch den hohen Ressourcenverbrauch (sowohl RAM, Speicherplatz und CPU Nutzung bei Start und Betrieb) die maximale Zumutung, gerade bei älterer und langsamer Hardware.

 

[Don_2020]

Web-Apps habe ich bei meinem Projekt nicht im Focus. Wenn es das noch dazu gibt: gut.

Was ich brauche ist eine SQL-Datenbankanbindung, ein bischen Menüeführung und Erstellung von SQL-Abfragen. Als kein Hexenwerk. Die Datenbank ist im lokalem Netzwerk. Allerdings sind die SQL-Abfragen recht komplex. Die Datenbank ist z.Z. ca. 1 GB groß. Tendenz stark zunehmend.

 

[pseudopseudonym]

Und wie geht das?

Flutter auf Desktop? Indem z. B. unter Linux "under the hood" QT läuft, muss dich aber nicht drum kümmern.

Oder das Design? Theming. Hier gibt's z. B. was dazu:
https://docs.flutter.dev/platform-integration/windows/building
...wobei das wohl eher für die modernen Windows-Apps ist, hab nur kurz draufgeguckt.

Gibt aber auch Spaßvögel, die Bock auf Win95 haben und gleich ganze UI-Komponenten dafür liefern:
https://pub.dev/packages/flutter95

Kannst auch irgendwelche Aero-Apps bauen:
https://pub.dev/packages/flutter_acrylic

Eigentlich nur ne Frage der Themes bzw Komponenten. Kannst da auch sehr viel selbst machen oder eben nach was fertigem suchen.

 

[sh.]

Was ich brauche ist eine SQL-Datenbankanbindung, ein bischen Menüeführung und Erstellung von SQL-Abfragen. Als kein Hexenwerk.

Java oder PHP, im Prinzip kannst du das mit jeder Sprache machen, kein Hexenwerk.
Wo ist den das Problem oder wo hängt es?

 

[Dalek]

Web-Apps habe ich bei meinem Projekt nicht im Focus. Wenn es das noch dazu gibt: gut.

Was ich brauche ist eine SQL-Datenbankanbindung, ein bischen Menüeführung und Erstellung von SQL-Abfragen. Als kein Hexenwerk. Die Datenbank ist im lokalem Netzwerk. Allerdings sind die SQL-Abfragen recht komplex. Die Datenbank ist z.Z. ca. 1 GB groß. Tendenz stark zunehmend.

1GB ist noch Spielzeugdatenbank, das sollte mit praktisch allen Technologien noch ohne Probleme gehen.

Mehrere Benutzer und eine zentrale Datenbank ist das absolute Paradebeispiel für Webanwendungen. Klar geht es auch mit Desktopanwendungen, macht man aber heute fast gar nicht mehr. Dazu müsste man entweder separate Server- und Clientanwendungen schreiben oder die DB direkt ins Netz exponieren, was man eher ungern macht.

Und absolut jede Programmierumgebung kann diese Art von Anwendung. Wenns einfach sein soll würde ich auf eine klassische serverseitig gerenderte Webanwendung gehen.

 

[TomH22]

Auf Elektron würde ich nur im äußersten Notfall setzen.
Für Endnutzer ist das durch den hohen Ressourcenverbrauch (sowohl RAM, Speicherplatz und CPU Nutzung bei Start und Betrieb) die maximale Zumutung, gerade bei älterer und langsamer Hardware.

Electron verbraucht erst mal nicht mehr Ressourcen als die gleiche Web Anwendung im Browser ausgeführt.
Und ein Rechner der mit aktuellen Browsern und Webseiten strauchelt, will man generell nicht mehr als Desktop einsetzen. Allerdings sehe ich unabhängig davon den Sinn von Eletctron hier nicht, besonders nicht für ein Einsteigerprojekt in kleinem Rahmen. Eine normale Web Oberfläche reicht doch völlig aus.

Natürlich kann man eine Datenbank basierte Anwendung für wenige User auch ganz "altmodisch" als 2-Anwendung bauen:

• Datenbank im Backend
• "Fat Client" mit Business Logik und GUI als Desktop Applikation.

Und wenn @Don_2020 mit diesem Modell schon Erfahrung hat, es nur im LAN (oder notfalls VPN) benutzt wird, die User Anzahl klein, die Umgebung vetrauenswürdig, bzw. die Anwendung nicht kritisch ist, dann kann man das auch noch so machen. Aber Stand der Technik ist es nicht.

Stand der Technik sind 3-Tier Anwendungen, wo die Business Logic auf einem Applikationsserver liegt und man das Front End auf "Web 2.0" Techniken beruht.

Generell würde ich den Anwendungsserver solch einer Anwendung nicht in C++ und auch nicht in Pascal schreiben. Beide sind eher unhandlich für diese Art Anwendung.

Ergänzung (27. Februar 2025)

Web-Apps habe ich bei meinem Projekt nicht im Focus. Wenn es das noch dazu gibt: gut.

Web App meint in diesem Umfeld, das man halt das GUI im Browser laufen lässt, anstatt es z.B. mit Qt zu bauen. Da macht auch Electron, nur das es halt den Browser gleich lokal mitbringt.

Was ich brauche ist eine SQL-Datenbankanbindung, ein bischen Menüeführung und Erstellung von SQL-Abfragen.

Wenn der Schwerpunkt auf Abfragen ist, dann würde ich ja eher irgendein allgemeines Query Tool verwenden. Ich habe aber keine Ahnung was es da an Open Source und unter Linux so gibt. Das ist so eine typischer Bereich wo man im geschäftlichen Umfeld eher auf Low-Code Platformen geht. Die sind nur meist kostenpflichtig, aber eben viel billiger als Arbeitszeit von Programmierern...

 

[KitKat::new()]

Electron verbraucht erst mal nicht mehr Ressourcen als die gleiche Web Anwendung im Browser ausgeführt.

Das stimmt so nicht - auf 2erlei Aspekten:

• Im Browser läuft nicht für jedes Fenster eine eigene separat installierte Browserinstanz
• bei Elektron ist noch einiges mehr dabei als beim Browser, z.B. Interaktion mit dem OS - und irgendwie hab ich eine Vermutung, dass sich dieser Overhead auch negativ auf die Performance der ganzen Anwendung auswirkt.

Und ein Rechner der mit aktuellen Browsern und Webseiten strauchelt, will man generell nicht mehr als Desktop einsetzen.

s.o. + viele sehen das anders, insbesondere, wenn hauptsächlich Elektron-Applikationen nicht nur das ganze System beeinträchtigen, sondern auch noch erhebliche Auswirkungen auf Akkulaufzeiten haben.

 

[TomH22]

Im Browser läuft nicht für jedes Fenster eine eigene separat installierte Browserinstanz

Das stimmt, aber das belegt zwar Plattenplatz und ggf. auch mehr Speicher für den Code, aber da auch im Browser jeder Tab einen eigenen Prozess/Adressrsaum hat, ist der Unterschied in der Praxis garnicht so groß.

s.o. + viele sehen das anders, insbesondere, wenn hauptsächlich Elektron-Applikationen nicht nur das ganze System beeinträchtigen, sondern auch noch erhebliche Auswirkungen auf Akkulaufzeiten haben.

Das liegt allerdings nicht an Electron, sondern daran, dass die Anwendungen selber nicht sehr effizient sind. Der Energieverbrauch von MS Teams liegt dann z.B. unter anderem an der intensiven Nutzung von AVX Befehlen für das Video Processing.
Im Vergleich dazu ist z.B. VSCode ziemlich schnell und saugt auch nicht den Akku leer, solange man nicht irgendeine schlecht programmierte Erweiterung nutzt.

Klar, JIT compiliertes JavaScript/WebAssembly ist niemals so effizient wie guter C/C++/Rust Code. Gerade weil der JIT auch relativ viel Energie braucht.


Bewegt sich jetzt aber ehrlicherweise zu weit von der Fragestellung des TE weg, daher sollten wir das jetzt nicht vertiefen.

Letztendlich sieht man, dass „viele Wege nach Rom“ führen und der TE sagt nur wenig darüber was er genau vorhat.

 

[KitKat::new()]

Im Vergleich dazu ist z.B. VSCode ziemlich schnell und saugt auch nicht den Akku leer, solange man nicht irgendeine schlecht programmierte Erweiterung nutzt.

um Größenordnungen langsamer als Alternativen obwohl ein Milliardengigant dahintersteckt (und btw. nichtmal mehr Elektron nutzt - zumindest unter Windows)

 

[Don_2020]

Danke für die vielen Anregungen.

Flutter sieht gut aus, ist aber nicht so ganz mein Ding. Smartphone-Anwendungen (ja ich weiss damit kann man viel mehr machen) ist nicht mein Ziel. Die meisten Toutorials beschäftigen sich mit Android-Smartphones.

Electron werde ich noch tiefer prüfen. Scheint mir sehr mächtig zu sein.

Jetzt bin ich noch auf Python mit Pyside6 gestoßen. Das arbeitet mit dem QT-Toolkit. Sieht auch ganz gut aus. Das könnte für meine Zwecke das richtige sein. Werde das mal in den nächsten Tagen testen.
Python scheint aktuell keine Sackgasse zu sein.

 

[4nudels]

pyhton weil openscource udn viel damiet geht

 

[sPeziFisH]

Python, und für GUI-Kram ist das Qt-framework eine gute Wahl, vgl. KDE Plasma jetzt auf Basis qt6, QGis, .. und viele andere. GUI könnten zb. mit dem qt Designer erstellt werden.
Siehe zb. https://wiki.qt.io/Qt_for_Python (Pyside6) und https://www.pythonguis.com/pyside6-tutorial/
Python kann man auch mal gut in einem Jupyter-notebook nutzen (andere Programmiersprachen natürlich auch).

 

[Drexel]

Ich würde eher PyQt statt PySide nehmen. PyQt scheint mir nach wie vor etwas weiter zu sein als PySide. In meinem Projekt hatte ich mit PySide z.B. Schwierigkeiten mit der DBus Kommunikation, mit PyQt war das kein Problem.

Aber die Basics waren mit PySide natürlich auch kein Problem.

 

[SheepShaver]

um Größenordnungen langsamer als Alternativen obwohl ein Milliardengigant dahintersteckt (und btw. nichtmal mehr Elektron nutzt - zumindest unter Windows)

Das halte ich für arg übertrieben. Auf aktueller Hardware ist praktisch kein Unterschied zu einer nativen Anwendung spürbar. Zudem frage ich mich, wie Du darauf kommst, dass VSCode nicht mehr Electron als Runtime nutzt. Bis dato gibt es keinerlei konkrete Pläne, Electron den Rücken zu kehren. In den Diskussionen zur Roadmap wurde das stets abgewiesen.

 

[andy_m4]

Das halte ich für arg übertrieben. Auf aktueller Hardware ist praktisch kein Unterschied zu einer nativen Anwendung spürbar.

Selbst auf aktueller Hardware fühlt es sich nicht so geschmeidig an, wie eine native Anwendung.
Abgesehen davon ist es eine unelegante Lösung. Ich meine, Man muss einen Webserver und einen ganzen Browser mitschleppen, um ein GUI-Programm zu realisieren. Das ist sehr "von hinten durch die Brust ins Auge".
Man hat davon eigentlich nur zwei Vorteile. Man kann einfach daraus eine reine Webanwendung machen die auf nem Server läuft und nicht lokal installiert werden muss und man kann zur Programmierung von dem Ding Webtechniken benutzen. Ansonsten hat es nur Nachteile (und man zieht sich eine Menge Komplexität mit rein).

Ich finde den Ansatz den GTK da macht ganz interessant. Das man verschiedene GDK-Backends setzen kann. Dann kann man sich aussuchen, ob man das ganze im Browser laufen lässt oder das was die native Plattform anbietet. Das hat zwar so seine Grenzen, aber gibt einem mehr Flexibilität.

In den Diskussionen zur Roadmap wurde das stets abgewiesen.

Es gab also Diskussionen darum. Das heißt, das Leute mit electron unzufrieden sind, ist keine verirrte Einzelmeinung.
Keine weiteren Fragen. ;-)

 

[KitKat::new()]

Das halte ich für arg übertrieben.

Ich denke nicht

Zudem frage ich mich, wie Du darauf kommst, dass VSCode nicht mehr Electron als Runtime nutzt.

Hatte ich tatsächlich falsch in Erinnerung.
Tatsächlich ist Teams auf Windows weg von Electron

 

[SheepShaver]

Man hat davon eigentlich nur zwei Vorteile. Man kann einfach daraus eine reine Webanwendung machen die auf nem Server läuft und nicht lokal installiert werden muss und man kann zur Programmierung von dem Ding Webtechniken benutzen. Ansonsten hat es nur Nachteile (und man zieht sich eine Menge Komplexität mit rein).

Es hat hinsichtlich Nachhaltigkeit und Einfachheit eigentlich nur Vorteile. Streamlining der Technologiestacks, die Anwendung ist praktisch OS agnostisch, Zugriff auf einen sehr großen Entwicklerpool, ein riesiges Ökosystem, etc.
Die Geachwindigkeitseinbussen sind in Zeiten von SSDs und riesigen Mengen an Hauptspeicher wiederum verkraftbar.
GTK ist unglaublich angestaubt und unelegant und ist nur ein UI-Toolkit und somit nicht vergleichbar. Dann schon eher Tauri oder React Native, die so wie Electron eine komplette Runtime bieten.

Ergänzung (2. März 2025)

IHatte ich tatsächlich falsch in Erinnerung.
Tatsächlich ist Teams auf Windows weg von Electron

Teams nutzt jetzt intern Edge statt Chromium und React statt Angular. Es ist aber immernoch eine hybride Webapp.

 

[KitKat::new()]

Es hat hinsichtlich Nachhaltigkeit und Einfachheit eigentlich nur Vorteile.

Boah Nachhaltigkeit im Zusammenhang mit Electron.
Genau das Gegenteil bei dem enormen Ressourcenverbrauch.

Streamlining der Technologiestacks, die Anwendung ist praktisch OS agnostisch, Zugriff auf einen sehr großen Entwicklerpool, ein riesiges Ökosystem, etc.
Die Geachwindigkeitseinbussen sind in Zeiten von SSDs und riesigen Mengen an Hauptspeicher wiederum verkraftbar.

TLDR: maximale Einsparungen bei der Entwicklung auf Kosten aller anderen, insbesondere der Anwender.
Electron ist quasi das Temu in der Softwareentwicklung.