No, XAML, QML, JavaFX, Android, Cocoa are much better, with guaranteed hardware acceleration, and offer RAD GUI designers that are much more powerful than hand-editing HTML/CSS.
As funny anecdote, CSS Grid was originally proposed by XAML team.
Google apparently is pushing for the low level rendering control that native UI APIs enjoy on their Houdini project. Right now, it is yet again a Chrome only feature.
The big problem is that out of the 5 technologies you mentioned,only two are cross-platform, and only one builds an exe (yet).
Oh, and that one is practically designed around a hybrid C++, so if you don't like C++ (last time I tried C++ with mingw on Windows I had a horrible time installing libraries), you're out of choices.
JavaFX doesn't run on iOS. While your Electron app will be tweaked to make a Cordova app that runs on iOS.
Avalonia is at beta level at best, would you bet your startup on it? Xamarin.Forms ok, but XAML is not 100% the same everywhere, anyway. WPF is not Xamarin.Forms.
My point of view is that if it is to be done with the Web stack, then by all means it should be delivered to whatever browser the user likes to use on their platform.
Anything else should take advantage of the native UI/UX tooling.
You have to actively ignore the web's landscape in the past 5-6 years to state something like this.
Lately, major vendors (with Edge, that includes Microsoft) are agreeing on standards, developing them FAST, and the web moves forward faster than it has ever moved. Long gone are the days where your standards can get stopped for multiple years. And vendor prefixes are less prevalent now as features get implemented properly sooner.
You have extra word in your second point. There is norhing mature. If anything webtech rushes implementation of some feature just so the checkbox “we can do it too” is ticked and that’s it.
Do you know of a Qt app that looks and feels fully native on macOS and Windows and maybe iOS and Android?
I'm genuinely curious. Years ago, I used several Qt apps, and they never felt native. They felt like Java Swing or Delphi apps. Clunky and not pretty. Slack, to me, doesn't _look_ quite native, but it still doesn't feel like an outsider on the platform.
I imagine that using native Apple kits are easy from C++ thanks to ObjC interop, no idea about Android.
Having done a lot of React development (in TypeScript), and recently dealing more with Android, I disagree.
Having to manually mutate the UI instead of describing it with a `render` function feels like a huge step back. Even data binding is often too limited.
Trying to get a screen in Android to have the correct layout and style is also way clunkier - even with ConstraintLayout.
If they were "much better", devs wouldn't be flocking to Electron. If there's something amiss, claiming there isn't with hand-waves brushes whatever issues there are under the carpet.
You also have to consider where the users are coming from. If you only have experience in web dev, obviously you are going to choose the framework that lets you do what you always did and get a desktop app in the end.
If you have been building GUIs in Visual Studio or VBA, you're probably not going to suddenly switch to Electron.
And if you have mostly been writing Python scripts for the terminal, you might use something like Gooey [1] to build a basic GUI with almost no additional effort.
Really, I agree that there are probably better markup options, but still, there's a reason people choose Electron over the alternatives. For me, personally, that reason is the ease of prototyping - the time it takes for me to have something in front of me that looks good and works easily is so much less using something like Electron.
Ok, but from an engineering standpoint I see this as a bit shortsighted.
I mean, shouldn't you care more about shipping a good product (i.e. developing something that doesn't thrash your users' resources) than ease of development?
I get that if it's too hard to develop there's no product to speak of, but still, aren't we going too far off the equilibrium point?
As funny anecdote, CSS Grid was originally proposed by XAML team.
Google apparently is pushing for the low level rendering control that native UI APIs enjoy on their Houdini project. Right now, it is yet again a Chrome only feature.