If you were going to build a GUI for a cross-platform desktop application, what would you use?
I haven’t seen a lot of desktop app content in discussions/articles on DEV, so I thought I’d start one! Just curious how others would approach the task.
Parameters:
- You cannot use Electron
- The GUI is decoupled from other app code and communicates via some local RPC/API
- You can use commercially licensed libraries/frameworks
I’m currently involved in maintaining an existing cross-platform desktop app, and have been thinking about some different approaches:
- Serve the GUI as a locally hosted site. Users interact with the app’s GUI in the browser of their choice.
- Separate codebases: use Cocoa/native libraries for Mac, Qt for Linux, WPF for Windows.
- Single codebase: Use Qt or wxWidgets for all platforms. (This is the approach I use today)
So... how would you do it? What choices would you make?
Top comments (8)
Unless I really need high performance, probably as a locally hosted site, most likely using whatever the standard native web server is for the backend environment, or H2O if it's C/C++. Taking this approach eliminates a significant percentage of the work you would have to do to get the RPC interface working for whatever native environment you might choose to use, and as much as I dislike JS, it's really good for event-based programming, which is really how you should be doing your UI logic.
Barring that, most likely Qt, after taking the time to learn it.
The problem with the split code-base approach is that it makes it harder to keep track of feature-parity among your different UI's, especially since one person can't as easily implement feature XYZ for all platforms as they can with the other two approaches.
Totally agree with your logic on the local site approach. I had not considered how JS would add the benefit of being well suited for event-based UI logic! I had mostly been considering broader advantages that using a “web” stack could offer: ease of development, tooling, code/component re-use and consistency in branding/experience with related sites. The biggest resistance I have to this approach is that it just feels weird to control a local application through a browser. I suppose it really depends on the purpose of the app.
Your point about the split codebase approach is right-on, but for some reason I keep getting stuck with the perception that, while it adds the feature parity problem, the user experience of a “more native” GUI could be a benefit. Maybe I’m taking a “grass is greener” point of view.
short rant:
I think Electron is great, BUT it comes at the cost of eating up more resources... for an app like VS Code, I think the argument can be made that they’ve done a great job optimizing, and what it’s doing with those resources is usually useful (from what I can tell). But for a simple-ish GUI to present some controls/log displays/“visibility” into the “backend” app... it just feels greedy to use.
Anyway, I appreciate the reply and thoughtfulness. Many of us use desktop apps every day and I would love to see (and contribute to) more content around the topic.
Also, I had not seen H20 before... looks like it could be super useful for some of my current use-cases. Thanks for adding that. I’ll be digging into that more for sure!
I started off writing Augean, in JavaFx
That didn't work out, I couldn't get the look and feel I wanted
Also, JavaFx WebView only supported ancient versions of javascript.
And Javafx, is no longer shipped as part of Java.
so now using a Java backend server, and displaying in Chrome browser.
This worked well (see augean.com)
I use typescript / HTML on the frontend and communicate with a Java Server on the back end. (java ships with an HTTP server)
I got some good results - works well on Mac, Windows, and Linux
I am thinking about releasing the framework I wrote
I think the chrome browser is the future of the cross-platform GUI
I would use web-view. I can still use the web stack for the frontend, and it would be a nice chance to finally learn Rust.
Nice!! I’ve definitely had my eye on the Rust ecosystem for a GUI framework/library, but had not seen this one. Seems like it’s still in a relatively early stage, but the readme sounds super promising.
Like you, I’ve been wanting to dive into Rust for a while, but haven’t done much yet. I went through a good chunk of the “Rust book” about a year ago and really enjoyed it.
Really curious why Electron can not be used. Is there something particularly unpalatable about it for your use case?
Sorry for the slow reply!!
There’s nothing inherently unpalatable about Electron... however, the app’s current memory footprint is quite small and if at all possible I’d like to maintain that benefit. One thing about the app is that the GUI is largely used for configuration purposes, so it’s not exactly required for basic use of the app. This is one major reason I’ve considered going the “separate codebases” route. Admittedly there would be more to maintain, but that seems like a reasonable trade-off given the advantages of that approach. My biggest constraint is dev time/effort required to “make the jump” to something new. Given that, I‘be started looking more towards serving static assets (html/css/js) from a local server.
Thanks for the reply! This makes sense.