ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core | Hacker News Reader

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

blinkingcaret.com

66 pointsrdfi83 comments

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.

Steve Sanderson (creator of Blazor) is working on something similar that doesn't use Electron:

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.

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

Except for the users that have to take with dozens of Electron instances running on their low to mid range computers.

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.

Uno Platform attempts to make WinUI cross-platform.

https://github.com/unoplatform/uno

Oh that looks good. Wonder what the timeline on these technologies will be. Sounds like it will be after .NET 5

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

I don't consider the return of MSHTML or XUL an innovative idea.

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.

Check out this page: https://blog.stevensanderson.com/2019/11/01/exploring-lighte...

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.

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.

I hope that they end up improving Xamarin instead.

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#

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 to see how code only UIs could look.

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.

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?

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

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

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

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.

They can relink. The object files for relinking aren't required to go through App Store.

Static/dynamic linking isn't a problem.

Interesting. If I install this [0] app, how can I relink it against my patched QT5?

0: https://apps.apple.com/us/app/qt-5-showcases-by-v-play-apps/...

Felgo most certainly uses Qt through the commercial license so nothing is LGPL here.

Right. Now imagine it didn't. What then?

you ask them for the LGPL package, they send it to you, you compile ?

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.

I am not talking primarily about open source projects, but about closed source projects with LGPL components on app stores. You’d need the proprietary main object from them. 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.

> I am not talking primarily about open source projects, but about closed source projects with LGPL components on app stores. You’d need the proprietary main object from them.

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.

Normally you ask them for the object files, but those specific guys are middleware developers so they provide QtCreator configured to build with their library (to get a different Qt version, select a different Qt Kit in QtCreator settings).

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.

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

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

Wow, that looks neat and the sample worked as expected including picking up the KDE breeze theme!

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.

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

You could just go to the repo and check the licenses there :

https://github.com/qt/qtbase

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

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

Setting up a connection between two processes and building async handlers is way too much if the application is running on one machine.

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

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

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.

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.

>> Isn’t that generally the main benefit of using electron based apps? The ability to target both desktop and web?

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 ?

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

Customizing the appearance is one place where Swing's age shows. It is possible to create a custom "Look and Feel", but it is not as easy as HTML / CSS:

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

I remember >10 years ago there used to be some "plaf" libraries that provided very easy themeing abilities for Swing that even came with a WYSIWYG tool to create themes. It is a shame something like that never became part of Swing itself and instead you have to create tons of classes just for a theme.

Or actually buy them.

http://www.jgoodies.com/ is still in business, to give a possible example.

This doesn't fix the issue of Swing theming being hard. The fix would be to make it much easier, preferably with a visual editor.

You mean like Netbeans Matisse, or more like actually having a designer on the team?

I was talking about themes, not UI design. Think GTK themes (though not their implementation), not where buttons in a form will go.

"How to design a modern Java Swing UI inspiration using Netbeans"

https://www.youtube.com/watch?v=SpKANTHXwmo

As mentioned, having a designer on the team matters.

I wasn't talking about such a thing. I was talking about being able to create a "plaf" theme using a visual editor or at least some rules in CSS or similar script that applies to the entire Swing application (like Swing's own plafs do) and doesn't require creating subclasses. This has nothing to do with having a designer or not and it is orthogonal to it (you can give the tool/rules/whatever to a designer if you want).

Swing can look fantastic if you put in the effort as IntelliJ (based on Swing) shows. I'm not necessarily an IDE guy, but good luck with getting that kind of functionality with JS on Electron even remotely.

I wouldn't say IntelliJ's stuff looks -good-. It's a lot more workable than most Swing apps but it's still a long way from looking "good".

That said I haven't touched their IDEs in 2 years so maybe something changed.

I'd say IntelliJ looks like it belongs on the platform it is run on - which I'll take any day over some over-designed cross-platform 'styling'.

The problem with Swing theming is that you need to create a ton of classes "just" for theming your application. I did that years ago myself, but really Swing should have something like those libraries released years (>10) ago that had a bunch of premade themes as well as WYSIWYG editors for them.

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.

Not only it is a breeze, after reading books like "Filthy Rich Clients", I have full control over hardware acceleration instead of playing CSS tricks with Z ordering in the vain hope that the browser will do the right thing.

Lack of design skills doesn't improve just because one changes UI stack.

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

Last I checked (late last year) JavaFX hadn't HiDPI support.

According to the release notes for version 8 HiDPI is supported.

Is that for Gluon? Sorry for not looking it up myself, but it's probably worth pointing out that at least Swing has (kindof) Oracle and a major Java desktop app behind, whereas JFX hasn't seen any love at all. I played around with JFX a couple years ago but there were serious problems with its WebKit integration. Coming to think about it, I'm wondering if there are any plans to integrate JFX and WebKit on GraalVM as a serious Electron contender.

I agree with you. JavaFX is better than Swing for most use cases.

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.

Makes sense. The tornadofx hello world is pretty minimal too:

    class HelloWorld : View() {
      override val root = HBox(Label("Hello world!"))
    }

    class HelloWorldApp : App() {
      override val primaryView = HelloWorld::class
    }

I've bee conflicted in my research on choosing Tornado or default JavaFX

I'm waiting for Tornado to support Java 11+ before I jump on the bandwagon. It's getting closer[1], but it's still not production ready, from what I can tell.

[1]: https://github.com/edvin/tornadofx/issues/899

Well I guess that makes it easier. I'd rather write Java than Kotlin anyway.

Really? That's the first time I've ever heard someone say that. What is it about Kotlin you don't like?

I just like Java. I know it well and mainly don't have issues with the problems kotlin is trying to solve. The main benefits I see of kotlin are coroutines (coming to java with project loom) and nullable reference types (which isn't a deal breaker for me).

I also don't enjoy functional programming, I find that it quickly becomes unreadable and kotlin is a weird mix between FP and OOP.

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.

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

WPF was great to program in for the most part -- was able to write some really compelling and complex UI's in it, and UI programming isn't really my thing.

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.

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

XAML kind of follows (in spirit) the ideas behind XHTML, and its related standards.

https://www.w3.org/standards/xml/components

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

Re: "What's wrong with HTML?"

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.

> It doesn't handle "state" well

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.

I would just say HTML is a document markup, not an application ui. And you need css to make a none-document look nice.

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.

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=TZnajQqqKV8

About 160% more resource usage, ideally to use a computer as heating replacement.

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

Reinwheeling is what the modern web is.

Calling it CGI seems like an awful awful move.

This is fantastic and long overdue.

Reply on news.ycombinator.com