On the other hand, Xamarin.Forms had an announcement recently, an announcement that Hacker News missed. I submitted the news a few days ago but it didn't reach the first page:
Xamarin.Forms will support desktop environments:
- Windows (WPF)
- MacOS (Cocoa)
- Linux (GTK#)
This is on top of the mobile bits: iOS, Android, UWP.
As an added bonus, they've added Xamarin.Forms embedding into native interfaces.
It's actually major news since Xamarin.Forms would become the first cross platform UI toolkit that:
1. supports both desktop and mobiles
2. is backed by a major vendor
3. is truly usable from a memory managed language as part of the core offering
All depends on how polished your UI needs to be. Anything too polished and you're better off going straight Xamarin or pure native.
Also note that my experience with this is building an extremely simple business-y app for internal users.
1. Its moving fast so documentation is lacking and the "right" way to do something, posted 6 months ago, is wrong\deprecated\wonky
2. The tooling leaves a lot to be desired. Although this has greatly improved, there are still tons of steps to publish (https://developer.xamarin.com/guides/android/deployment,_tes...).
3. Updates constantly breaking things. To be fair, this is also improving
4. There may still be instances where you have to drop into native code or split code based on platform. This means you sometimes will need to know: c#, xamarin.forms oddities, java\android stuff AND objective c\iOS. This may not be an issue for simple apps
5. UI builder is limited. The apps will be native looking but you won't be winning any design awards. Some things also seem impossible so it helps if the customer\designer\stakeholder is really flexible. If someone asks for an app to collect and display data, you will probably be ok. If they give you pixel dimensions and other minutiae run.
If it's more about the technical details, such as general issues regarding cross platform UI frameworks, I think we're way past that point considering HTML5/Js :)
Or the lack of integration with native animation frameworks, widgets, behaviours and system APIs, even with HTML 5.
Or hacks like Service Worker with in browser database, to be able to write offline apps, something that just works out of the box in native apps.
I get now why people use Electron. It's 2017, Qt has been around forever, and they still haven't figured out the fricking deployment issue! You still have to cobble together a bunch of scripts and otherwise crappy solutions to get something that runs on Linux/Mac/Windows in any shape or form that approaches "out of the box" and "continuous integration".
If you want extra layers of pain, try to use any of the Python bindings for Qt on mobile :D
The options I'm aware of are:
https://github.com/picoe/Eto (OP - BSD)
Currently only with a preview for Mac, Xamarin.Forms is roadmapped for desktop platforms "Q3 2017": https://blog.xamarin.com/glimpse-future-xamarin-forms-3-0/
Licensing for Xamarin Forms was funky for a while (required paying for Xamarin prior to MS acquisition) but appears to be MIT now.
It's based on the old XNA framework. At least one successful commercial game (Fez) was written with it.
Bastion was another one that comes to my mind.
As additional remark, indies have been doing games in C# since the Managed DirectX days.
Also the love they are getting from MS and Google for VR/AR.
Build apps for Windows, OS X, Linux, Android and iOS with C# and XAML. Sounds pretty cool to me. So it isn't to say this isn't a great idea by the BrowseEmAll devs, but I'm just not sure how needed it'll be once Microsoft steps in.
I hereby release it into the public domain.
Edit: sorry, I see there's a top level license. Browsing github on my phone wasn't giving me the info I wanted :)
Qt has been around for a while and though it gained traction Electron is far outpacing it. It seems that there is no ASP.NET Core since it was borne out of an actual use case with ASP.NET.
Again, kudos to the author and it seems like a great technical feat, but to my knowledge what matters is adoption rate.
You're acting like the whole desktop app industry has moved to implementing desktop apps in HTML with Electron.
Fortunately for users this assertion is false, given how shitty most Electron apps are usability and performance wise (VSCode being the only exception).
As for Qt, web devs have C++ allergy, hence why the company behind Qt came up with QML. exactly to fight against this trend.