Ska jag lära mig GTK+, Nuklear, wxWidgets eller OpenJFX?

Från din lista:

I/O
Är det någon som är Node.JS riktigt starka sida så är det hantering av I/O, så på denna punkt vinner Electron/Node.JS över både .NET och Java/springboot

UI
Här beror det primärt på vad man är van men, har egentligen inte gjort speciellt mycket UI och när det hänt har jag alltid föredragit webfront-ends just för att kunna köra det på vilket OS som helst. Electron är i praktiken en Chrome-fönster i en lokal applikation, d.v.s. man använder samma verktyg där som man designar webbapplikationer med och finns "drag-n-drop" (men personligen vill jag göra UI i "kod", men kanske säger hur simpla saker jag gör UI-mässigt). Givet vilka applikation som är gjorda i Electron så visar det ändå hur bra tekniken fungerar.[/li]

Industrianpassat
.NET är betydligt vanligare i Sverige än vad det är i stort. Node.JS har lite samma status i Nordamerika som .NET har här. Java/Spring Boot/Node.JS är alla så välanvända i "industrin" att ingen kommer försvinna under övrskådlig tid. NPM (pakethanterare för JS) måste rimligen ha klart mest paket ställd mot NuGet och whatever kan tänkas finnas i Java-världen (har varit i den, men är väldigt länge sedan nu, då var fortfarande J2EE och serverlets "hippt")

Snabbutvecklat
Är det något JS, Python m.fl. har en fördel mot statiskt typade kompilerade språk är det snabbare turn-around-tid vid utveckling. Personligen tycket jag värdet från statisk typning + allt det medför i form av möjlighet att hitta fel tidigt väger upp extra-tiden, föredrar därför TypeScript över både JS och Python (men Python + frivillig typanotering + VS Code tar en en hyfsad bit på vägen och då slipper man fortfarande helt kompilering-steg)[/li]

Grafer och CRUD
Ser inte riktigt varför dessa ska grupperas, men finns väldigt bra stöd för visualisering av data i webbläsaren och dessa fungerar även i Electron. CRUD vilar ju på I/O, I/O är Node.JS verklig starka punkt ställd mot .NET och Java.

Passa alla plattformer
Detta är .NET riktigt svaga sida, även om det blivit rejält mycket bättre med .NET-core. Och även med .NET-core har ARM64 stödet varit ett sorgebarn, men även det jobbas det på rejält på numera från Microsoft sidan och senaste versionen av .NET core har enorma prestandavinster på ARM64 (men säger mer om hur kasst det var innan, både Java och NodeJS har redan lysande ARM64 stöd).

WPF verkar lite på väg ut och vad jag kan se fungerar det bara under Linux+.NET-core via Wine, vilket i praktiken säger att det inte fungerar på Linux. Det borde helt utesluta MacOS.

Det jag hittade om MAUI är att det initialt kommer stödja Windows, MacOS, iOS och Android, ser inget om stöd för "vanliga" Linux.

Så även om dotnet-core gjort .net tillgängligt för Windows, MacOS och Linux i "back-end" är det fortfarande ett rätt uselt val för Linux UI. Java är ett helt OK val, webb-teknik (t.ex. Electron) är det klart "säkraste" valet då det har lysande stöd på alla relevanta OS.

Ovanpå det nämnde du C++ för högprestanda saker. C++ är tyvärr inte speciellt enkelt att integrera med något annan programspråk, utom möjligen C, då man aldrig standardiserat dess ABI. Men då NodeJS är byggt på bibliotek som själva är utvecklade i C++ är det av alternativen det som är enklast och har minst overhead mot C++ extensioner. Beroende på vad man gör är det i.o.f.s. ibland möjligt att köra beräkningar i en separat process, i det läget kan man ju kombinera det med vilken annan teknik/annat språk som helst utan större problem.

Alltså allt har ju sin plats. Vill man göra något mot hårdvarunära kanske inte web teknologier är att föredra alltid.

Även om. Net numera har Linux stöd kommer det ta några år för det att ta fart. Har för mig att många gamla paket inte fungerar osv utan att uppdateras och det är ju problematiskt.

Men ärligt talat så är inte Linux stöd så intressant ur ett användarperspektiv. Det grymma är att man nu kan köra. Net på linux servrar! 😁

Jag vet inte om det är riktigt det som utlovas, men projekt som kan byggas på Windows kan även byggas på Linux (under vissa förutsättningar: än så länge gäller det ju som sagt terminalprogram och bibliotek, och det finns till exempel inte heller stöd för c++/cli).

Dessutom undrar jag om det verkligen är anledningen till att Java väljs när så sker. Det lyfts ju ofta fram som en stor fördel (särskilt förr), men viktigare är nog att utvecklarna redan är bekväma med Java, att de smidigt vill interagera med andra komponenter skrivna i Java eller utnyttja Javas stora standardbibliotek eller utvecklingsverktyg.

Man kan tycka det, men kanske underlättar det att Mac har ett mera standardiserat grafik-api?

Sedan vet man ju inte heller hur väl Maui kommer slå. Wpf känns ju som sagt lite på väg ut, och så har det väl varit i snart ett decennium..
Det är kanske inte så lätt att få folk att hoppa på nya tåg, och Microsoft har ju en viss tradition av att överge plattformar ibland.

Hehe, .Net 5 kommer faktiskt ur .Net core 3.1 snarare än det .Net som har funnits länge (och fasas ut nu). Till stora delar är de kompatibla, men skillnader finns.

Källkoden kan troligen kompileras om med .Net 5 (fast man måste konvertera projektfiler och liknade först), och eventuellt får man göra vissa förändringar om standardbiblioteket har ändrats men kompatibiliteten är nog rätt god ändå.

Nej då, det är ungefär lika lätt. Om man startar ett nytt projekt blir ju allt rätt från början och kommer troligen fungera många år framöver. Fast gui-biten är lite fragmenterad just nu, men möjligen kommer Maui till undsättning för alla med tiden. Dessutom finns Blazor, Avalonia och liknade.

Jag gillar Qt, men dess stora fördel är att det är ett så väldesignat ramverk. Det är en fröjd att använda jämfört med gtk+, wxwidgets och liknande.

@heretic16 Qt finns som sagt även gratis via till exempel L-GPL (vilket är ungefär samma som wxwidgets använder).

Jadå, med L-GPL får man länka till Qt från en kommersiell och stängd applikation (och det är ju så man typiskt använder ett sådant ramverk), men om du gör ändringar i själva Qt måste du publicera dem.

Tyvärr verkar QT licensen betydlig snårigare än så. Är bara vissa delar av QT som är tillgängliga under L-GPL, så man måste först reda ut om någon av de saker som ska användas faktiskt finns under den licensmodellen.

På denna sida verkar de visualisera vad som finns för respektive licens. Om jag inte missförstått deras high-light är ser det ut som endast den kommersiella licensen ger allt, övriga licensmodeller undantar vissa delar.

Man säger också detta på hemsidan

"Qt for Application Development is also available under GPL and LGPLv3 open source licenses. Qt tools and some libraries are only available under GPL."

Tänker då specifikt på att vissa saker verkar bara finnas under GPL, inte under LGPLv3.

Och då jag nämnt Electron flera gånger: den använder MIT-licens, d.v.s. man kan i princip använda det biblioteket fritt i sina applikationer.

vxWidgets verkar ha någon egen licens, som i praktiken beskrivs ligga väldigt nära LGPL. Fördelen där jämfört med QT är att allt täcks under samma licens.

Det skrivet: jag tillhör också de som verkligen gillar QT. Hoppades länge att det skulle bli den "vinnande" tekniken under Linux, men man får väl säga att det blev GTK+ som "vann". Ställt mot GTK+ har QT klara fördelar om man även vill stödja OS som Windows och MacOS. GTK+ må "fungera", men det brukar inte riktigt kännas "native" på Windows/MacOS.

Bara så det står helt klart: även om Electron använder CSS/HTML och JavaScript precis som man gör i webbapplikationer så skriver man "normala" desktop-applikationer med Electron som har samma tillgång till lokal HW som du har från QT eller WSL applikationer.

Den stora fördelen med Electron är att man använder samma teknik som för webbapplikationer, något som bl.a. medför att man väldigt enkelt kan bygga en webb-baserad version av sin applikation om så önskas. Finns projekt som jobbar på att göra Visual Studio code tillgänglig direkt i webbläsaren, är ju riktigt användbart!

En annan cool sak med NodeJS är hur brutalt bra prestanda det har trots att det är "interpreterat" (i praktiken sker ju en kompilering/JIT när programmet körs). Har man mer extrema prestandakrav finns som sagt officiellt stöd för att bygga moduler i C++, med Java och .NET får man i praktiken gå omvägen via C och de har väsentligt högre "overhead" i sin övergång till C++.

Har jobbat som arkitekt för en plattform för embedded-utveckling i "molnet". I den kan man dels jobba med saker lokalt via extensioner till Visual Studio Code, men också möjligt att utveckla, debugga och distribuera applikationer till nätverksanslutna enheter (t.ex. RPi:s och liknande system) med webbläsaren som enda krav. Electron, Angular 2 och NodeJS är en av de kritiska komponenterna där (och koden är en blandning av JS och TS, körde själv uteslutande TS).

100-tals projekt verkar ju helt wacko
Det är då inte problemet i de fall jag sett, där har det handlat om tiotalet projekt även om totala mängden kod varit milliontals rader.

Just hastigheten i att navigera kod på olika sätt, jämfört med andra IDE:er (och "andra IDE:er" är nästan alltid Visual Studio i detta kontext) är det folk primärt berömmer JetBrains Rider för. Men visst finns det ändå problem, t.ex. fick JVM:en lite spel på min jobbdator som har 128 GB RAM (vilket inte är extremt, men knappast normalfallet heller). Men gick att fixa med lite explicit konfig...