ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core(blinkingcaret.com) |
ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core(blinkingcaret.com) |
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?
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.
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.
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.
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.
[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.
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.
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.
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.
It is a markup language, just like the SGML you talked about. In-fact, it started out as a subset of SGML. If it could handle state, it would not be a markup language. The same applies for any desktop GUI that uses a custom markup language to declare a UI.
> via HTML + DOM + CSS + JavaScript + JavaScript libraries to something that natively handles GUI's. Those 5 parts together have proven fragile
They have proven so fragile, that the whole web, billions of pages handling all sorts of things from banking to social media run on top of them. Not to mention PWA mobile apps and cross-platform desktop apps like VS Code. And it is actually 4 parts, all platforms have libraries.
> That's why we need a dedicated GUI markup language and browser (or pluggin).
We already have one, maybe you just don't like it, don't understand it or its not cool/edgy enough for your tastes. It's called HTML.
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.
Yes, but then what would be the point of ElectronCGI?
If the goal is to target desktop and web then Electron is a great choice. There are many popular Electron-based applications that show this, e.g. Slack, VSCode, etc.
ElectronCGI is supposed to provide a cross-platform GUI for use cases where the full Electron stack is not wanted or perhaps not available.
I applaud the effort, but it strikes me as a strange choice since it brings the client-server and async complexities from web programming into a desktop environment. It seems like a very niche use case. Perhaps if you have a large .NET codebase that needs to be available as a cross-platform desktop application, but for some reason you can't use Electron / Blazor ?
That said I haven't touched their IDEs in 2 years so maybe something changed.
There used to be many libraries (most of them were awful, half of them tried to mimic circa 2002 Mac OS X Aqua) so i do not remember any names, though i remember trying one with a visual editor that i gave to a designer at the place i worked at. We didn't ended up using it though because of the price.
http://www.jgoodies.com/ is still in business, to give a possible example.
class HelloWorld : View() {
override val root = HBox(Label("Hello world!"))
}
class HelloWorldApp : App() {
override val primaryView = HelloWorld::class
}
Static/dynamic linking isn't a problem.
0: https://apps.apple.com/us/app/qt-5-showcases-by-v-play-apps/...
Additionally, the nature of the library is that it's probably a plugin that's loaded by a regular Qt application, as a result you've got their classes available in the QML scripts. It isn't very intrusive on the practical level.
They don't say what license they use though.
I also don't enjoy functional programming, I find that it quickly becomes unreadable and kotlin is a weird mix between FP and OOP.
https://www.youtube.com/watch?v=SpKANTHXwmo
As mentioned, having a designer on the team matters.
The onus is on the person making the app that links against the LGPL library to provide you with the build instruction.
At worse they would give you their main static library and Qt LGPL source code and you just have to relink them and open Xcode to upload it to your iDevice ?
Here is for instance the source code for the telegram app for iOS which is under GPL : https://github.com/TelegramMessenger/Telegram-iOS
there is no difference with... basically every other open source project ? Open the .xcodeproj, build, run.
yes, and as I said if they are not providing them to you they are breaking the LGPL plain and simple. If they break their contract you're in undefined-behaviour land anyways :-)
> Also, requiring that your users have an Apple dev account before they can execute their rights is problematic at best. I am not alone in rejecting Qt on these grounds, in favour of some MIT or similarly licensed alternative.
You don't need a dev account to upload something to your phone since Xcode 7 or 8. Only to put it on the appstore. Prior to that, sure, it was hard to comply with the LGPL.