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.
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.
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.
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.
How about Avalonia. 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.
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#
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?
Two replies mention licensing, with two different answers (It's easy, people just don't understand! It's hard, people just don't understand!). Personally, I've tried a couple of times to read the license information on the Qt site and sort out how the licensing really works. I still only have a rough understanding. It seems like information on the Qt site is intentionally vague so you'll be more inclined to buy a commercial license just to feel "safe" using it. Unfortunately, any commercial projects I work on can't justify the commercial license price.
Anyway, the point is, people may not want to use Qt without being absolutely certain about how the licensing works and they (like me) probably don't have the time to try to understand the poorly organized information on the Qt site.
> 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.
I think most KDE apps are neither written using Kirigami nor Qt Quick however, but plain old Qt Widgets (maybe I'm misinformed, but Kirigami doesn't look much like it's customizable by the desktop environment, which is something I love about KDE apps).
My bet is the licensing stuff which can make it difficult/expensive to make proprietary apps with it. (In practice, I know the picture is a bit complicated.)
Also, personally, while QML probably is the nicest OOP/bindings style UI framework I've seen, it's still not as nice as any of the reactive ones (i.e. React, Vue, Angular2, Flutter, etc…).
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:
Swing is probably the wrong choice if youre going java. I do electron everyday for work and we use stdin/stdout to farm json to a Java process as well. Given the chance I would probably use JavaFX over Electron or Swing. The FX app will be easier to style than swing and Gluon just announced native compilation support via Graal for new FX apps [0].
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.
> What's really needed is a standard GUI markup language (SGML)
What's wrong with HTML? Isn't it already everywhere, including in all browsers?
> HTML browser makers usually don't care if they break a particular JavaScript library by adding or tweaking features.
HTML and JS are two different languages. One is a markup language, the other a scripting language. If changes to the markup language break a library in the scripting one, its clearly the library that needs fixing. Expecting browser makers to somehow keep their HTML engines backward compatible with JS libraries isn't really realistic or practical.
Goz3rr|6 years ago
Hawxy|6 years ago
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.
rafaelvasco|6 years ago
efdee|6 years ago
headmelted|6 years ago
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.
belinder|6 years ago
https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...
Not sure if it's cross-platform though.
pjmlp|6 years ago
injidup|6 years ago
Or go full functional with an Elmish architecture using F#, .net core and Avalonia.
pjmlp|6 years ago
blinkingled|6 years ago
It's got to be better than anything Electron for sure.
Anyone know if .NET Core Qt bindings are a technical possibility?
ubertakter|6 years ago
Anyway, the point is, people may not want to use Qt without being absolutely certain about how the licensing works and they (like me) probably don't have the time to try to understand the poorly organized information on the Qt site.
dx87|6 years ago
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.
solarkraft|6 years ago
I think most KDE apps are neither written using Kirigami nor Qt Quick however, but plain old Qt Widgets (maybe I'm misinformed, but Kirigami doesn't look much like it's customizable by the desktop environment, which is something I love about KDE apps).
TorbjornLunde|6 years ago
Also, personally, while QML probably is the nicest OOP/bindings style UI framework I've seen, it's still not as nice as any of the reactive ones (i.e. React, Vue, Angular2, Flutter, etc…).
cheez|6 years ago
pjmlp|6 years ago
juliangoldsmith|6 years ago
There are already GTK bindings for Mono through Gtk#. Those should be usable under .NET Core.
thesuperbigfrog|6 years ago
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/sta...
Setting up a connection between two processes and building async handlers is way too much if the application is running on one machine.
vips7L|6 years ago
[0] https://gluonhq.com/gluon-substrate-and-graalvm-native-image...
efdee|6 years ago
bluejekyll|6 years ago
tabtab|6 years ago
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.
orange8|6 years ago
What's wrong with HTML? Isn't it already everywhere, including in all browsers?
> HTML browser makers usually don't care if they break a particular JavaScript library by adding or tweaking features.
HTML and JS are two different languages. One is a markup language, the other a scripting language. If changes to the markup language break a library in the scripting one, its clearly the library that needs fixing. Expecting browser makers to somehow keep their HTML engines backward compatible with JS libraries isn't really realistic or practical.
pjmlp|6 years ago
So now appreciate what HTML has turned into.
azhenley|6 years ago
pjmlp|6 years ago
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=TZnajQqqKV8
About 160% more resource usage, ideally to use a computer as heating replacement.
DonnyV|6 years ago
de_watcher|6 years ago
sqldba|6 years ago
mikece|6 years ago
sproketboy|6 years ago
[deleted]
sproketboy|6 years ago
[deleted]