19 ms·

ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

66 points by rdfi 7y ago

mikece 7y ago
This is fantastic and long overdue.
Hawxy 7y ago
Steve Sanderson (creator of Blazor) is working on something similar that doesn't use Electron: https://blog.stevensanderson.com/2019/11/01/exploring-lighter-alternatives-to-electron-for-hosting-a-blazor-desktop-app/ https://blog.stevensanderson.com/2019/11/01/exploring-lighte... 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.
- efdee 7y ago
  But the big advantage of using Electron is that you know exactly what browser and Node version you are targetting. That takes away a lot of the cross-browser HTML/CSS pain.
  - bob1029 7y ago
    I don't really see this as an advantage anymore (especially contrasted against how horrible electron is in terms of memory & CPU utilization). Modern browsers are much better about being consistent with standards. Perhaps if you are starting from zero on the CSS front you will see minor quirks browser-to-browser, but if you start with something like bootstrap 4 and leverage the responsive layouts you can see consistent results that your clients will enjoy pretty much immediately.
  - pjmlp 7y ago
    Except for the users that have to take with dozens of Electron instances running on their low to mid range computers.
- belinder 7y ago
  One of the comments on that blog leads to WinUI, which I would assume Microsoft would recommend first https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md https://github.com/microsoft/microsoft-ui-xaml/blob/master/d... Not sure if it's cross-platform though.
  - miguelrochefort 7y ago
    Uno Platform attempts to make WinUI cross-platform. https://github.com/unoplatform/uno https://github.com/unoplatform/uno
    - belinder 7y ago
      Oh that looks good. Wonder what the timeline on these technologies will be. Sounds like it will be after .NET 5
  - localhost 7y ago
    Microsoft is not a single entity; there is plenty of room for innovative ideas like what Steve has that challenges the status quo around formerly innovative ideas like electron. We certainly have no shortage of highly successful electron apps at the company either (e.g., VS Code and Teams).
    - pjmlp 7y ago
      I don't consider the return of MSHTML or XUL an innovative idea.
- rafaelvasco 7y ago
  That is a much better way to go on imo. No Electron and no Node involved. A tiny crossplatform webview + .net core is much preferable for me.
  - ryuukk_ 7y ago
    tiny? .net core is ~100mb, you replace big dependency with big dependency, why?
  - bobblywobbles 7y ago
    Check out this page: https://blog.stevensanderson.com/2019/11/01/exploring-lighter-alternatives-to-electron-for-hosting-a-blazor-desktop-app/ https://blog.stevensanderson.com/2019/11/01/exploring-lighte...
- headmelted 7y ago
  I've sort of mixed feelings about this. Instinctively this does seem better than Electron as a solution. It's much leaner, isn't subject to the browser sandbox, and should be consistent across platforms - so it ticks the same boxes in a leaner package. I just don't think Electron is a solution we should try to emulate elsewhere. Most Electron apps that I've seen don't really need access to the underlying platform, and as a user I really don't want to trust the author with native access to the platform where it's not obviously necessary. Even where it is necessary I have no real granularity as regards the permissions I'm handing over. PWA's are dismissed more or less out-of-hand in the article but they're pretty much what it goes on to suggest, just with compromises. Electron (or an Electron-but-leaner approach) gives us this: - Common platform for offline applications that run in a browser engine. PWA's give you that, and also this: - Permissions system for out-of-the-ordinary platform requirements that (1) have API consistency across devices and (2) that the user has visibility and granular control over. - Updates are managed inherently by the nature of the open web (reload page, service worker updates). - No seperate framework to install for JS, but if a framework needs to be bundled (e.g. for .NET Core) it can be cached between applications similarly to if it were installed on the computer seperately. Honestly I think PWA's over WebAssembly and the open web is a much better fit for this. People complain about Electron not being available on mobile devices and things like Chromebooks, but the reason for that is because there's a better solution already in place: Websites pinned to the home screen. They're a webview without window chrome that can request access to perform most tasks you might want to do with Electron, but inside the sandbox. The only thing I can think of that needs platform access and is commonly built on Electron is code editors, and even then only to run and debug command line applications that are running seperately on the platform. For almost every other type of application I've seen on Electron it would be better as a PWA.
  - pjmlp 7y ago
    PWAs are also what we decided to invest on for mobile Web. And I get a feeling that WebAssembly + WebGL/WebGPU will have a shinny future, unless the browser authors change course.
- pjmlp 7y ago
  I hope that they end up improving Xamarin instead.
injidup 7y ago
How about Avalonia. https://avaloniaui.net/ https://avaloniaui.net/ 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. Or go full functional with an Elmish architecture using F#, .net core and Avalonia.
- pjmlp 7y ago
  F# is a niche language among .NET developers, because adopting it closes the doors to lots of enterprise tooling (including Visual Studio designers), that only consider VB.NET and C#
  - injidup 7y ago
    Visual Studio designers are an abomination. Once beyond anything trivial it is slow and buggy and a pain. Look at FUNC.UI https://github.com/FuncUI/Avalonia.FuncUI https://github.com/FuncUI/Avalonia.FuncUI to see how code only UIs could look.
    - pjmlp 7y ago
      I know how code only UIs could work, I've been doing UIs since Turbo Vison for MS-DOS, and lost count how many toolkits I have used since then. No designer, I get to move into something else. The Web being the exception here, as it keeps rebooting itself without ever learning from native toolkits.
blinkingled 7y ago
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. It's got to be better than anything Electron for sure. Anyone know if .NET Core Qt bindings are a technical possibility?
- cheez 7y ago
  It's JS, but not webdev JS, which means they can't really transfer much of the DOM knowledge/tooling.
- juliangoldsmith 7y ago
  .NET Qt bindings are possible; the question is how much effort it would take. There are already GTK bindings for Mono through Gtk#. Those should be usable under .NET Core.
- dx87 7y ago
  > I always wonder why Qt5+/Qml/QtQuick have not taken the XP desktop development by storm. If I had to guess, it's because people are misinformed about the pricing and features. I regularly see people who assume that you either have to pay a large per-developer fee, or completely open source your application, even though Qt is licensed under the LGPL, so you're fine as long as you don't statically link it or depend on secret modifications to Qt for your application. A lot of people also assume it only supports C++ and dismiss it outright.
  - jacobush 7y ago
    LGPL is problematic for App Store, since the user should be able to relink the app with a newer version [of QT] if they wanted to.
    - de_watcher 7y ago
      They can relink. The object files for relinking aren't required to go through App Store. Static/dynamic linking isn't a problem.
thesuperbigfrog 7y ago
This is a great step forward, but it seems like a great deal of overhead and complexity to have a cross-platform GUI. 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. To illustrate, here is the "Hello World" cross-platform GUI application in Java: https://docs.oracle.com/javase/tutorial/uiswing/examples/start/HelloWorldSwingProject/src/start/HelloWorldSwing.java https://docs.oracle.com/javase/tutorial/uiswing/examples/sta... Setting up a connection between two processes and building async handlers is way too much if the application is running on one machine.
- bluejekyll 7y ago
  Would that Java application be capable of running in the browser? JavaFX, maybe?
  - thesuperbigfrog 7y ago
    That "Hello World" example uses Java's Swing GUI framework which is older and does not port to the web as easily as JavaFX. Here is the JavaFX-based "Hello World": https://docs.oracle.com/javafx/2/get_started/hello_world.htm#CHDIFJHE https://docs.oracle.com/javafx/2/get_started/hello_world.htm... There are also numerous Java to Web frameworks and solutions like TeaVM (https://blogs.oracle.com/javamagazine/java-in-the-browser-with-teavm https://blogs.oracle.com/javamagazine/java-in-the-browser-wi...), JSF (https://javaee.github.io/javaserverfaces-spec/ https://javaee.github.io/javaserverfaces-spec/), and many others, but at that point you are no longer talking about just a cross-platform GUI--you are talking about a web application.
    - bluejekyll 7y ago
      Isn’t that generally the main benefit of using electron based apps? The ability to target both desktop and web? We can bemoan the inefficiency of this, and how wasteful it is, but at the end of the day, it’s a very portable way of delivering applications. I think VSCode is a huge success because of this model.
Goz3rr 7y ago
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.
sqldba 7y ago
Calling it CGI seems like an awful awful move.
DonnyV 7y ago
Thinks using a web server is too much. Then recreates http. ¯\_(ツ)_/¯
- de_watcher 7y ago
  Reinwheeling is what the modern web is.
sproketboy 7y ago
JavaFX FTW!
sproketboy 7y ago
Why bother with this when you have JavaFX which is superior in every single conceivable way.
tabtab 7y ago
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. 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. 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. 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.
- azhenley 7y ago
  I like your idea and Microsoft probably hoped for XAML to become that standard.
  - tabtab 7y ago
    It's fairly close to what I have in mind, but it's also mostly static, I believe. It would need enhancements to handle interaction and UI updates better. And I'm not sure about its cross-platform abilities, but I haven't tested the limits.
    - WorldMaker 7y ago
      > It's fairly close to what I have in mind, but it's also mostly static, I believe. It would need enhancements to handle interaction and UI updates better. XAML Behaviors and Storyboards have been around since very early in XAML history. They aren't fun to write by hand, which is why originally they were a "Blend thing" focused for Designers mostly (and a lot of the XML namespaces still have "Blend" or "Expression" keywords in them) and the non-Designer Developer story for them has always lagged behind, which sometimes seems a shame because they can also be really powerful. > And I'm not sure about its cross-platform abilities, but I haven't tested the limits. There was the brief period where Silverlight was very cross-platform. Xamarin and Uno and Avalonia all seem healthy and to imply that XAML works well cross-platform.
pjmlp 7y ago
If it uses Electron it is not a solution. Even Microsoft's own React Native team bashes on Electron's resource usage. https://www.youtube.com/watch?v=IUMWFExtDSg https://www.youtube.com/watch?v=IUMWFExtDSg https://www.youtube.com/watch?v=TZnajQqqKV8 https://www.youtube.com/watch?v=TZnajQqqKV8 About 160% more resource usage, ideally to use a computer as heating replacement.

66 points by rdfi 7y ago

This is fantastic and long overdue.

Steve Sanderson (creator of Blazor) is working on something similar that doesn't use Electron: https://blog.stevensanderson.com/2019/11/01/exploring-lighter-alternatives-to-electron-for-hosting-a-blazor-desktop-app/ https://blog.stevensanderson.com/2019/11/01/exploring-lighte... 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.

efdee 7y ago
But the big advantage of using Electron is that you know exactly what browser and Node version you are targetting. That takes away a lot of the cross-browser HTML/CSS pain.
- bob1029 7y ago
  I don't really see this as an advantage anymore (especially contrasted against how horrible electron is in terms of memory & CPU utilization). Modern browsers are much better about being consistent with standards. Perhaps if you are starting from zero on the CSS front you will see minor quirks browser-to-browser, but if you start with something like bootstrap 4 and leverage the responsive layouts you can see consistent results that your clients will enjoy pretty much immediately.
- pjmlp 7y ago
  Except for the users that have to take with dozens of Electron instances running on their low to mid range computers.
belinder 7y ago
One of the comments on that blog leads to WinUI, which I would assume Microsoft would recommend first https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md https://github.com/microsoft/microsoft-ui-xaml/blob/master/d... Not sure if it's cross-platform though.
- miguelrochefort 7y ago
  Uno Platform attempts to make WinUI cross-platform. https://github.com/unoplatform/uno https://github.com/unoplatform/uno
  - belinder 7y ago
    Oh that looks good. Wonder what the timeline on these technologies will be. Sounds like it will be after .NET 5
- localhost 7y ago
  Microsoft is not a single entity; there is plenty of room for innovative ideas like what Steve has that challenges the status quo around formerly innovative ideas like electron. We certainly have no shortage of highly successful electron apps at the company either (e.g., VS Code and Teams).
  - pjmlp 7y ago
    I don't consider the return of MSHTML or XUL an innovative idea.
rafaelvasco 7y ago
That is a much better way to go on imo. No Electron and no Node involved. A tiny crossplatform webview + .net core is much preferable for me.
- ryuukk_ 7y ago
  tiny? .net core is ~100mb, you replace big dependency with big dependency, why?
- bobblywobbles 7y ago
  Check out this page: https://blog.stevensanderson.com/2019/11/01/exploring-lighter-alternatives-to-electron-for-hosting-a-blazor-desktop-app/ https://blog.stevensanderson.com/2019/11/01/exploring-lighte...
headmelted 7y ago
I've sort of mixed feelings about this. Instinctively this does seem better than Electron as a solution. It's much leaner, isn't subject to the browser sandbox, and should be consistent across platforms - so it ticks the same boxes in a leaner package. I just don't think Electron is a solution we should try to emulate elsewhere. Most Electron apps that I've seen don't really need access to the underlying platform, and as a user I really don't want to trust the author with native access to the platform where it's not obviously necessary. Even where it is necessary I have no real granularity as regards the permissions I'm handing over. PWA's are dismissed more or less out-of-hand in the article but they're pretty much what it goes on to suggest, just with compromises. Electron (or an Electron-but-leaner approach) gives us this: - Common platform for offline applications that run in a browser engine. PWA's give you that, and also this: - Permissions system for out-of-the-ordinary platform requirements that (1) have API consistency across devices and (2) that the user has visibility and granular control over. - Updates are managed inherently by the nature of the open web (reload page, service worker updates). - No seperate framework to install for JS, but if a framework needs to be bundled (e.g. for .NET Core) it can be cached between applications similarly to if it were installed on the computer seperately. Honestly I think PWA's over WebAssembly and the open web is a much better fit for this. People complain about Electron not being available on mobile devices and things like Chromebooks, but the reason for that is because there's a better solution already in place: Websites pinned to the home screen. They're a webview without window chrome that can request access to perform most tasks you might want to do with Electron, but inside the sandbox. The only thing I can think of that needs platform access and is commonly built on Electron is code editors, and even then only to run and debug command line applications that are running seperately on the platform. For almost every other type of application I've seen on Electron it would be better as a PWA.
- pjmlp 7y ago
  PWAs are also what we decided to invest on for mobile Web. And I get a feeling that WebAssembly + WebGL/WebGPU will have a shinny future, unless the browser authors change course.
pjmlp 7y ago
I hope that they end up improving Xamarin instead.

injidup 7y ago

How about Avalonia. https://avaloniaui.net/ https://avaloniaui.net/ 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. Or go full functional with an Elmish architecture using F#, .net core and Avalonia.

pjmlp 7y ago
F# is a niche language among .NET developers, because adopting it closes the doors to lots of enterprise tooling (including Visual Studio designers), that only consider VB.NET and C#
- injidup 7y ago
  Visual Studio designers are an abomination. Once beyond anything trivial it is slow and buggy and a pain. Look at FUNC.UI https://github.com/FuncUI/Avalonia.FuncUI https://github.com/FuncUI/Avalonia.FuncUI to see how code only UIs could look.
  - pjmlp 7y ago
    I know how code only UIs could work, I've been doing UIs since Turbo Vison for MS-DOS, and lost count how many toolkits I have used since then. No designer, I get to move into something else. The Web being the exception here, as it keeps rebooting itself without ever learning from native toolkits.

blinkingled 7y ago

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. It's got to be better than anything Electron for sure. Anyone know if .NET Core Qt bindings are a technical possibility?

cheez 7y ago
It's JS, but not webdev JS, which means they can't really transfer much of the DOM knowledge/tooling.
juliangoldsmith 7y ago
.NET Qt bindings are possible; the question is how much effort it would take. There are already GTK bindings for Mono through Gtk#. Those should be usable under .NET Core.
dx87 7y ago
> I always wonder why Qt5+/Qml/QtQuick have not taken the XP desktop development by storm. If I had to guess, it's because people are misinformed about the pricing and features. I regularly see people who assume that you either have to pay a large per-developer fee, or completely open source your application, even though Qt is licensed under the LGPL, so you're fine as long as you don't statically link it or depend on secret modifications to Qt for your application. A lot of people also assume it only supports C++ and dismiss it outright.
- jacobush 7y ago
  LGPL is problematic for App Store, since the user should be able to relink the app with a newer version [of QT] if they wanted to.
  - de_watcher 7y ago
    They can relink. The object files for relinking aren't required to go through App Store. Static/dynamic linking isn't a problem.

thesuperbigfrog 7y ago

This is a great step forward, but it seems like a great deal of overhead and complexity to have a cross-platform GUI. 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. To illustrate, here is the "Hello World" cross-platform GUI application in Java: https://docs.oracle.com/javase/tutorial/uiswing/examples/start/HelloWorldSwingProject/src/start/HelloWorldSwing.java https://docs.oracle.com/javase/tutorial/uiswing/examples/sta... Setting up a connection between two processes and building async handlers is way too much if the application is running on one machine.

bluejekyll 7y ago
Would that Java application be capable of running in the browser? JavaFX, maybe?
- thesuperbigfrog 7y ago
  That "Hello World" example uses Java's Swing GUI framework which is older and does not port to the web as easily as JavaFX. Here is the JavaFX-based "Hello World": https://docs.oracle.com/javafx/2/get_started/hello_world.htm#CHDIFJHE https://docs.oracle.com/javafx/2/get_started/hello_world.htm... There are also numerous Java to Web frameworks and solutions like TeaVM (https://blogs.oracle.com/javamagazine/java-in-the-browser-with-teavm https://blogs.oracle.com/javamagazine/java-in-the-browser-wi...), JSF (https://javaee.github.io/javaserverfaces-spec/ https://javaee.github.io/javaserverfaces-spec/), and many others, but at that point you are no longer talking about just a cross-platform GUI--you are talking about a web application.
  - bluejekyll 7y ago
    Isn’t that generally the main benefit of using electron based apps? The ability to target both desktop and web? We can bemoan the inefficiency of this, and how wasteful it is, but at the end of the day, it’s a very portable way of delivering applications. I think VSCode is a huge success because of this model.

Goz3rr 7y ago

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.

sqldba 7y ago

Calling it CGI seems like an awful awful move.

DonnyV 7y ago

Thinks using a web server is too much. Then recreates http. ¯\_(ツ)_/¯

de_watcher 7y ago
Reinwheeling is what the modern web is.

sproketboy 7y ago

JavaFX FTW!

sproketboy 7y ago

Why bother with this when you have JavaFX which is superior in every single conceivable way.

tabtab 7y ago

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. 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. 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. 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.

azhenley 7y ago
I like your idea and Microsoft probably hoped for XAML to become that standard.
- tabtab 7y ago
  It's fairly close to what I have in mind, but it's also mostly static, I believe. It would need enhancements to handle interaction and UI updates better. And I'm not sure about its cross-platform abilities, but I haven't tested the limits.
  - WorldMaker 7y ago
    > It's fairly close to what I have in mind, but it's also mostly static, I believe. It would need enhancements to handle interaction and UI updates better. XAML Behaviors and Storyboards have been around since very early in XAML history. They aren't fun to write by hand, which is why originally they were a "Blend thing" focused for Designers mostly (and a lot of the XML namespaces still have "Blend" or "Expression" keywords in them) and the non-Designer Developer story for them has always lagged behind, which sometimes seems a shame because they can also be really powerful. > And I'm not sure about its cross-platform abilities, but I haven't tested the limits. There was the brief period where Silverlight was very cross-platform. Xamarin and Uno and Avalonia all seem healthy and to imply that XAML works well cross-platform.

pjmlp 7y ago

If it uses Electron it is not a solution. Even Microsoft's own React Native team bashes on Electron's resource usage. https://www.youtube.com/watch?v=IUMWFExtDSg https://www.youtube.com/watch?v=IUMWFExtDSg https://www.youtube.com/watch?v=TZnajQqqKV8 https://www.youtube.com/watch?v=TZnajQqqKV8 About 160% more resource usage, ideally to use a computer as heating replacement.