The author stating that using a webserver and a full web framework for a desktop application feels wasteful seems oddly ironic when you follow up by using a browser and full framework for a desktop application.
Steve Sanderson (creator of Blazor) is working on something similar that doesn't use Electron:<p><a href="https://blog.stevensanderson.com/2019/11/01/exploring-lighter-alternatives-to-electron-for-hosting-a-blazor-desktop-app/" rel="nofollow">https://blog.stevensanderson.com/2019/11/01/exploring-lighte...</a><p>From Blazor roadmaps a few months ago, I think the idea is that Blazor will become the recommended .NET Core cross-platform UI choice sometime after .NET 5.
How about Avalonia. <a href="https://avaloniaui.net/" rel="nofollow">https://avaloniaui.net/</a> The assertion that there are no .NET core GUI frameworks and that resorting to the abomination that is electron is the solution is just false.<p>Or go full functional with an Elmish architecture using F#, .net core and Avalonia.
I always wonder why Qt5+/Qml/QtQuick have not taken the XP desktop development by storm. QML is JS like, there's an IDE and KDE seems to have built lot of good looking desktop software using Kirigami/QtQuick.<p>It's got to be better than anything Electron for sure.<p>Anyone know if .NET Core Qt bindings are a technical possibility?
This is a great step forward, but it seems like a great deal of overhead and complexity to have a cross-platform GUI.<p>If I were creating a new cross-platform desktop application I would probably reach for Java instead. I know that's not the popular answer, but if a .NET Core cross-platform GUI requires either using Electron or simulating a client-server setup with Node then it's not there yet.<p>To illustrate, here is the "Hello World" cross-platform GUI application in Java:<p><a href="https://docs.oracle.com/javase/tutorial/uiswing/examples/start/HelloWorldSwingProject/src/start/HelloWorldSwing.java" rel="nofollow">https://docs.oracle.com/javase/tutorial/uiswing/examples/sta...</a><p>Setting up a connection between two processes and building async handlers is <i>way too much</i> if the application is running on one machine.
What's really needed is a standard GUI markup language (SGML) and probably a dedicated browser, or at least a browser pluggin. Emulating desktop-like GUI's using JavaScript and DOM has proven clunky and unreliable, largely because HTML browser makers do what they want when they want. A dedicated GUI browser wouldn't break GUI's because doing GUI's is its sole purpose.<p>HTML browser makers usually don't care if they break a particular JavaScript library by adding or tweaking features. It's a matter of focus. The SGML browser's only job is to do GUI's right. But HTML browsers have 100's of jobs. If changes harm a few of those, they become roadkill.<p>But using JavaScript as the starting point of a SGML may be the only way to gain momentum. However, the end game should be using mostly markup to manage a GUI, not JavaScript.<p>Standard and common GUI idioms and behaviors should be done in a declarative fashion using such markup, such as having a button open (make visible) a given window. While some client scripting may be needed, most of the processing could and should be done at the server if the SGML browser does most of the UI grunt-work.
If it uses Electron it is not a solution.<p>Even Microsoft's own React Native team bashes on Electron's resource usage.<p><a href="https://www.youtube.com/watch?v=IUMWFExtDSg" rel="nofollow">https://www.youtube.com/watch?v=IUMWFExtDSg</a><p><a href="https://www.youtube.com/watch?v=TZnajQqqKV8" rel="nofollow">https://www.youtube.com/watch?v=TZnajQqqKV8</a><p>About 160% more resource usage, ideally to use a computer as heating replacement.