ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core (opens in new tab)

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.

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.

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.

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

Not sure if it's cross-platform though.

I hope that they end up improving Xamarin instead.

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#

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.

A .Net Core Qt Quick binding is not only possible, but very real: https://github.com/qmlnet/qmlnet

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

It's JS, but not webdev JS, which means they can't really transfer much of the DOM knowledge/tooling.

Because .NET, Delphi or C++ Builder are better options if you are paying anyway, and only focusing on Windows.

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

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

[0] https://gluonhq.com/gluon-substrate-and-graalvm-native-image...

Good luck getting that Swing app to look nice, though. Which is a breeze with HTML/CSS.

Would that Java application be capable of running in the browser? JavaFX, maybe?

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

That is what XHTML was supposed to become, but then people decided to misuse HTML and make it into HTML 5.

So now appreciate what HTML has turned into.

I like your idea and Microsoft probably hoped for XAML to become that standard.

Reinwheeling is what the modern web is.