The desktop became just another platform to target. Few cross platform apps can afford to not target the web with all of its benefits like instant, no install required delivery. A whole generation of developers is growing up on Webpack, Babel and React.
Who can fault Electron for existing?
As a user I mourn the cost at which this new wave of desktop apps come. If it were only memory I could buy more – up to a limit – but many of these apps put us back a good 10 years in responsiveness and even screen real estate. My workstation feels like a two year old phone. Who thought unchecking “Show window contents while dragging” would ever make sense again?
Luckily, to get to the original question, we are getting new options. I'm quite excited about Xamarin, which lets us provide a good experience on mobile, against the native toolkit if we like, but also a fast, familiar desktop app.
This isn't worth anything as long as we can't target the web and this is where I hope WebAssembly will bring us.
I remain hopeful. We must be able to do better than ship web browsers to our desktop users, but maybe we're not quite there yet.
VB and C# make use of .NET Native and C++/CX are just a few C++ extensions that look like C++/CLI but compile to native code as always. One can also use standard C++ with WRL or C++/WinRT libraries.
.NET Native shares the compiler backend with Visual C++.
The issue is that the .NET Native compiler team doesn't care about supporting the IL required by F#.
It's really too bad, Win2D was quite nice.
Windows 8 was also AOT compiled to native code, but using the old Bartok toolchain from Singularity(MDIL).
UWP is what Longhorn should have been in first place, if WinDev and DevTools actually worked together.
COM based OS ABI fully native, to the point only VB and C# are used in most Windows talks, even for the new UI composition engine.
C++ is still there for the kernel, device drivers, audio and graphical critical performance components like DirectX.
Everything else can enjoy the productivity of .NET languages and respective tooling.
Which meant that any of my WP 8.x and 10 devices run considerably faster than Android devices of similar price range, while having less overall memory requirements.
Also, look at all we gave up for AOT. Dynamic compilation in the DLR was pretty nice...and it was reduced to an interpreter in UWP because....no JIT. Granted, I was probably the only person to notice because no one else probably thought to cross the two.
The problem with Microsoft is that as soon as they move to the next thing, they basically abondon the previous one without having the next thing truly replace the previous one. So here comes UWP, meant for "different" things, but it gets all the new stuff while WPF is basically dead. Ya, want to use those new APIs? Sorry, you'll need to use UWP even if you have no intention of running on low end android devices.
So much good stuff, but you have to make a Faustian bargain to use them.
Two years after UWP was introduced still no roadmap in sight for .NET Native support, Visual Studio 15.3 just shipped with the F# team telling people to use VS Code instead.
I bet it will be joining Silverlight in a couple of years.
However Microsoft is not alone in these kind of decisions. I can think of a few similar ones from Apple, Google, IBM, HP, Oracle, Sun,....
If you need it to be offline and integrate into the operating system, then electron would be the next logical step in that direction.
If you want deep, and award winning support, you're going to have to write your product natively for each OS using native APIs. There's just no way around that requirement unfortunately.