I think WASM will eventually produce the solution (hear me out before you tune out). I've been thinking about this for a while. So we have WASI[0], which doesn't yet address the UI issue, but there's half a dozen at least projects attempting to create runtimes for WASM. If most languages wind up compiling for WASM / WASI I think eventually a good effort could be done towards a WASI-UI or WASUI.
Imagine if major OS platforms had a common UI framework that any language can produce a UI for, every major browser already supports WASM, why not a WASI based common runtime that would benefit every OS that supports it. I havent seen anyone else discussing this I've just been contemplating it for a while and I'm not sure what it would look like short of recreating a cross-platform X window system.
However, as crazy as I sound my reason for this is simple: the issue with a lot of UI frameworks is that they tend to be language specific and are mostly useful to the languages they officially or directly support. If you can build a UI compatible stack that any language can target, you can gain a lot more adoption. I could easily see Rust, D, Go, etc supporting a common UI runtime.
Electron sells itself rather easily cause most devs are familiar with HTML / CSS / JS. What we need is a cross-platform cross-language solution that isn't XML based but something a language can implement rather simply, or maybe even a compiler / standard library could manage.
Imagine if major OS platforms had a common UI framework that any language can produce a UI
This has been attempted a number of times, both in the browser and without, and it always comes down to people complaining that the widget set isn't "native" in look and feel and operation, and the pendulum swings back the other way.
People used to complain that browser widgets didn't confirm to the OS's UI guidelines. Then you could style them with CSS and things really started looking crappy, then you have web UI frameworks that forgo all that customization (or at least discourages it in the name of ease of development).
Umm - a large group of most popular productivity apps are cross platform and look nothing like native - from dev tools like IDEA, VSCode over Slack, MS Office, to multimedia tools like Adobe tools, almost all 3D modeling software like maya, max, audio software like Ableton, FL. None of the apps I use on a day to day basis look native (ie. like the apps provided by Apple)
You are confusing cross platform UI with frameworks that have programmer art widgets and no cross platform polish - eg. GTK+, FLTK, and even to some extent QT widgets (and many more). When people say widgets don't look native they usually mean "the widgets suck", you can create beautiful cross platform apps - Electron has quite a few because it allows standard designer tools from web dev.
Flutter is another promising development, but the desktop port seems underwhelming - it's obvious the widgets were intended for mobile apps, they will probably need a custom widget set to cover desktop UI - but the approach is sound.
The native apps you mention have heavy customization because they are meeting advanced professional needs. But these apps still participate in the platform's UI conventions. Menus, windows, etc. work like Mac or Windows users expect.
Electron apps are also heavily customized, but ignore platform UI conventions. The buttons may have lovely drop shadows, but basic interactions (menus, undo, drag and drop...) are routinely broken or work in some discordant, unfamiliar way. This isn't meeting professional needs; it's that web tech sucks for building actual apps.
And even if web tech improved, there's still the cultural bias towards re-invention and churn. Web dev will always cons up a button from a div and an onClick handler, no matter what the framework provides. There's no mechanism to get web apps onto a shared UI platform because the gravity of the web is dispersive.
If MS Office was truly cross platform in look, feel, and operation, then finance people who insist on using Excel wouldn't also insist on using Windows just to use Excel.
All those specialized tools can get away with having completely-unlike-anything else UI/UX because people are paying for them and they are considered best(and only)-of-breed.
Electron apps are cross platform only in terms of them looking alike on different platforms, because they use the same widget set. If slack was a truly, full native app on OSX, it wouldn't look like it does.
In my experience, finance people who insist on using Excel only on Windows generally do so not because of any reliance on "native controls", but on longstanding dependencies upon VBA macros with hard-coded dependencies on specific legacy COM components.
I don't know enough about Excel but I highly doubt it's about the looks - I have Office installed on my MBP and the ribbon looks like I remember it from Windows.
I don't understand your point - non-native widgets are not a deal breaker and there are plenty of examples, Electron being the most common non-native cross platform framework recently (it has technical limitations but even the subpar performance doesn't make it a deal-breaker). So it's possible to create cross-platform UI frameworks and most of the the most successful apps I can think of are using some version.
I remember when people used to tell me VB6 was slow... but I bet you a lot of VB6 apps are miles faster than Electron apps and use significantly less resources / storage despite being single threaded by comparison.
WebAssembly is basically the latest in the line of Java Applets and Macromedia Flash. Maybe it'd be useful if someone built a tiny wasm emulator for x86 linux stdio binaries and posted it on a google cdn. I haven't seen anyone do that yet.
I'm pretty happy with web pages as a GUI framework. If I needed a desktop GUI, I certainly would not want my binaries to be 200megs with Electron. If we're OK trading away drop-down boxes, wizards, and installers, then it's actually possible to build 10kb static native win32+linux+bsd+mac terminal programs using ape. https://justine.storage.googleapis.com/ape.html
You asked me how to avoid the overhead of Electron and I suggested you try αcτµαlly pδrταblε εxεcµταblε since the distributables are 10,000x smaller. If it's not possible to meet your requirements using a command line c program, or a web application that runs in the browser, then could you help me understand why you need electron?
I'm not advocating for Electron... I think either you're misunderstanding me or we're misunderstanding each other (quite possible as well).
I'm advocating for some small cross-platform cross-language API / runtime / framework (not sure what it looks like, but since most languages are targetting WASM (if this is what's making you think I'm advocating for Electron... then you missed my commentary about people making stand alone WASM runtimes) as opposed to solutions that are platform or language specific, and when I say platform specific lump in web (which means Electron too) in that bucket.
What most people want is to be able to use their own preferred language and do a UI without having to import a bunch of C or C++ libraries that will add additional overhead over their language.
Edit: Just saw the post you were referring to, it would of made more sense had you linked to it:
While this answers the 1 binary problem while producing a rather massive executable file larger than Electron in many cases, this still doesn't solve the problem I'm mentioning: We need a cross-platform cross-language UI solution. If you want to do away with things like Electron, you need to consider all platforms and all languages.
Imagine if major OS platforms had a common UI framework that any language can produce a UI for, every major browser already supports WASM, why not a WASI based common runtime that would benefit every OS that supports it. I havent seen anyone else discussing this I've just been contemplating it for a while and I'm not sure what it would look like short of recreating a cross-platform X window system.
However, as crazy as I sound my reason for this is simple: the issue with a lot of UI frameworks is that they tend to be language specific and are mostly useful to the languages they officially or directly support. If you can build a UI compatible stack that any language can target, you can gain a lot more adoption. I could easily see Rust, D, Go, etc supporting a common UI runtime.
Electron sells itself rather easily cause most devs are familiar with HTML / CSS / JS. What we need is a cross-platform cross-language solution that isn't XML based but something a language can implement rather simply, or maybe even a compiler / standard library could manage.
[0]: https://wasi.dev/