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.
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.
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.
And I get a feeling that WebAssembly + WebGL/WebGPU will have a shinny future, unless the browser authors change course.
https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...
Not sure if it's cross-platform though.
Or go full functional with an Elmish architecture using F#, .net core and Avalonia.
It's got to be better than anything Electron for sure.
Anyone know if .NET Core Qt bindings are a technical possibility?
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.
You could just go to the repo and check the licenses there :
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).
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…).
There are already GTK bindings for Mono through Gtk#. Those should be usable under .NET Core.
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.
[0] https://gluonhq.com/gluon-substrate-and-graalvm-native-image...
I gave the Swing "Hello World" example because it shows a minimal, simple example of how little code is needed to create cross-platform GUI in Java.
JavaFX is also technically an external library now since Oracle spun out JavaFX to OpenJFX and Gluon has taken over development and maintenance, although many but not all OpenJDK distributions include it.
https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/
JavaFX does allow CSS to be used to style it:
https://docs.oracle.com/javase/8/javafx/user-interface-tutor...
Lack of design skills doesn't improve just because one changes UI stack.
Here is the JavaFX-based "Hello World":
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-wi...), JSF (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.
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 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.
It doesn't handle "state" well, and lacks common GUI idioms like menu bars, tool-bars, editable data grids, combo-boxes, model dialog boxes/windows, MDI, and others. Perhaps HTML can be modified to do those well, but it probably wouldn't be "HTML" anymore.
Re: "If changes to the markup language break a library in the scripting one, its clearly the library that needs fixing."
I'm comparing the emulation of desktop GUI's via HTML + DOM + CSS + JavaScript + JavaScript libraries to something that natively handles GUI's. Those 5 parts together have proven fragile. The chain is as strong as the weakest link.
Re: "Expecting browser makers to somehow keep their HTML engines backward compatible with JS libraries isn't really realistic or practical."
That's why we need a dedicated GUI markup language and browser (or pluggin). You would be very careful about breaking GUI's if GUI's are your tool's only job. HTML (current) browser makers have a lot of other concerns. Breaking a GUI emulator library is just collateral damage to them that makes them yawn.
Those who tried to do something somewhat similar failed because they put too much on their plate: Flash and Java Applets. They tried to be entire virtual OS's, making them a hacker haven. Lesson: don't be an application programming language, don't be a compiler, don't be an OS, don't be a code editor, don't be a toaster, just be a GUI browser and only a GUI browser.
So now appreciate what HTML has turned into.
And I'm not sure about its cross-platform abilities, but I haven't tested the limits.
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.