WingNews logo WingNews GitHub [2]
top | item 28484658

Ask HN: How do you create a cross-platform GUI without using Electron?

92 points| mariocesar | 4 years ago | reply

I have the idea of an app that is mostly about communicating with an API on the WEB. It feels a considerable overkill for an Electron App. The size of a hello world app in Electron is 100x the size of my backend!

On the business side, I understand that many people on HN prefer to ship that spend time on technologies discussions.

But if you have the time, and your goal is to do something maintainable, reasonably close the most to the Desktop, and well-integrated to the OS, what tech/stack will you use?

Windows/Linux GTK/MacOS

110 comments

order
[+] cedws|4 years ago|reply
This thread doesn't inspire confidence. It's mostly small and unproven projects, some maintained by hobbyists.

I think the mess we're in with GUIs is because we've failed to find a way to convey at a very high level what the inputs and outputs of software are. In a utopian world, you'd define what you want the user to see and how the user can interact with the information. Something would then work out how to lay that for you (in a way that makes sense to a human) and construct a GUI using native OS APIs.

Instead, we have only three options that I'm aware of:

* Use a framework that ignores the native APIs, throws away the OS design language and does all the rendering inside

* Build separate applications for each platform

* Use Electron and potentially reuse work you already did on the web version

When looking at it this way, it's easy to see why Electron is popular. Not that I'm a fan of it in any way.

I think what we need is a lot of really smart people to come together to reinvent the presentation layer.

[+] armchairhacker|4 years ago|reply
I think part of the problem is that different OS chromas have different native widget sizes, and possibly different layouts. If you create a UI for Windows and just switch to the macOS chroma, it will have weird spacing, and I don’t think there’s a general way to fix this. Converting to the iOS chroma is even worse, with checkboxes -> switches, radios -> tables, and the combination of smaller screen + bigger controls.

So the solution for cross-platform apps is to use a non-native chroma which is the same for each OS. But that brings you to Qt or JavaFX or Electron.

[+] mjevans|4 years ago|reply
It's often trivial to cross-compile a basic command like program, OS filesystem specifics might be a small issue but there it's generally Windows vs everything else. Building one (mostly shared) codebase for different platforms is fine; or even shipping a script that's run locally.

However the solution to this problem needs:

  * To already be installed on every updated OS
  * Work, mostly, the same across every OS
  * Include the widgets we know from the last 20-30 years.
It's mostly that first bullet-point that's the killer. Windows needs it. OSX needs it. Neither the end user nor the application developer should have to worry about it staying updated.

I'd be happy enough if, across all the major OS today, I could use a pipe or localhost socket to talk to the browser and use it to render a webpage within a basic OS window (ZERO other browser decoration or interactions, still OS decorated). If THAT alone worked on every operating system that would be enough of a basic step for 99% of the CRUD style apps out there. Small extra bonus if a message-passing interface worked between the two.

[+] imagine99|4 years ago|reply
Delphi, believe it or not. Might even be the most mature and feature-rich of any of the technologies and frameworks mentioned here.

RAD Studio 11 just got released and allows native development for "all platforms" from a single codebase and GUI at the click of a button. [0]

I have ranted about and harshly criticised Embarcadero's misguided product policies as much as the next guy but that doesn't change the fact that Delphi is still the most mature and versatile Rapid (sic) Application Development environment out there, especially if UX and UI are important to you.

And the twenty-year old adage that you can knock out an MVP with a really nice and polished GUI in a Saturday afternoon is now even more true than ever.

In the end, a native binary with a small footprint (easily 1/100th the size of an Electron project) will fall out at the press of the F9 key and that's really something to behold...

The free Delphi community edition [1] might even offer all the features that you need, although I really wish Embarcadero would see the light already and sync its release cycle with the full version.

Delphi might not officially be regarded as hip or cool these days (mostly due to severely and ongoing errant product and community management by the company that makes it) but some great people and brilliant minds are associated with it and compared to the olden days Delphi is now somewhat of a secret underground Swiss army knife that ironically gets used now mainly in big and medium corporations.

I like to think its versatility combined with the fact that it's technically uncool and against the mainstream to do projects in Delphi these days might fit a hacker's (and HN user's) mindset very well...

[0] https://www.embarcadero.com

[1] https://www.embarcadero.com/products/delphi/starter?aldSet=e...

[+] Gys|4 years ago|reply
> The free Delphi community edition

For a moment I was tempted to look into Delphi again, as I have spend many years in that environment. However, I see now its free until you hit USD 5.000 revenue per year. Not 0 USD, not USD 50.000, but only USD 5.000. Yes, that is the Embercadero that I knew. Probably this 'free' edition is canceled next year. Would not be the first time...

Edit: yes, still only runs on Windows

[+] irq-1|4 years ago|reply
Does the community edition work on linux, or compile to linux? The page says:

> Delphi Community Edition is a full featured IDE for building iOS, Android, Windows and macOS apps ...

But looking at the feature matrix for the full product it says:

> deploy to the platforms you need to support and with RAD Studio that includes Windows, macOS, iOS, Android and Linux!

[+] diskzero|4 years ago|reply
There are several options, each with their own pros and cons.

Qt [1]

The main codebase is C++, but bindings are available for Python and several other languages. I have developed and shipped multiple cross-platorm applications using Qt, using both C++ and Python. Documentation and source code examples are readily available.

JUCE [2]

Another C++ framework, with Python bindings. The focus is on music and audio apps, but a cross-platform GUI framework is also part of the library.

Blazor Desktop [3]

I have developed C# web applications using Blazor and WASM and moved them to the desktop easily. Using C# and the Dotnet ecosystem is really interesing and worth looking at.

Flutter for Desktop [4]

Still in beta, but has the support of Google, for better or worse.

JavaFX [5]

A Java cross-platform still under active development. I think it is pretty nice if you like Java.

Red [6]

Let's add an outsider just to keep things interesting!

This github site seems somewhat current about other Electron alternatives as well. [7]

Good luck! You will find there are lots of alternatives out there.

[1] https://www.qt.io/

[2] https://juce.com/

[3] https://visualstudiomagazine.com/articles/2021/02 /17/net-6-preview-1.aspx

[4] https://flutter.dev/desktop

[5] https://openjfx.io/

[6] https://www.red-lang.org/p/about.html

[7] https://github.com/sudhakar3697/electron-alternatives

[+] Zelphyr|4 years ago|reply
I am really looking forward to the day that I can build cross-platform GUI apps in Red. Based on Rebol, it is a beautiful yet powerful language. They are always looking for more contributors, if anyone is interested.

Here's an example of what it could do on macOS four years ago: https://www.red-lang.org/2017/07/063-macos-gui-backend.html

Edit to add: You can build cross-platform GUI apps in Red now but, while they're very close to the finish line, and making progress every day, there are still a few missing pieces yet to complete on the 1.0 roadmap.

[+] babarganesh|4 years ago|reply
Is there a good grid control (ie a data grid) for Blazor? A colleague reviewed the offering from Infragistics and it wasn't anywhere near their WPF data grid control.
[+] emerged|4 years ago|reply
Funny, I actually use JUCE for audio and yet it never crossed my mind to use it as a general purpose cross platform UI. Good call!
[+] mherrmann|4 years ago|reply
If you have access to Python 3.5 or 3.6, you can use my open source library https://build-system.fman.io to create a Python / Qt app with an installer for all the OSs in minutes. Python 3.7-3.9 is also supported, but only available commercially.
[+] miovoid|4 years ago|reply
Vote for Flutter and QT
[+] squarefoot|4 years ago|reply
One word: Lazarus.

Cross platform done right (native code, no intepreter, no VM). Both IDE and generated code run native just about everywhere, from small ARM boards to virtual machines, and of course x86. As fast as C, decent sized executables, lots of built in or available libraries and components to do a lot of things, from managing databases to low level access to hardware, graphics, sound, etc. And of course it's 100% FOSS.

My last use case was a few years ago when a friend needed to monitor some security cameras, but they were of different brands and needed either their crappy Android/iOS app or a even more crappy XP-only ActiveX control on Internet Explorer, while he wanted to monitor them from a single screen on a Windows 7 PC. As soon as I discovered the right URL for each one to grab their video feed, I arranged a window container in Lazarus dropping there a bunch of media player components, each one linking to a camera, a few other controls and bingo, he could fire up the application and have the mutiple camera view on a monitor.

If it compiled more modern languages such as Nim, Rust or Crystal it would be perfect, but even by current standards Object Pascal it's still really powerful.

https://www.lazarus-ide.org/

https://wiki.lazarus.freepascal.org/Screenshots

https://wiki.freepascal.org/Projects_using_Free_Pascal

https://www.devstructor.com/index.php?page=tutorials

[+] mjevans|4 years ago|reply
What's the Lazarus experience like for cross-compiling to other platforms? E.G. how hard is it to build a working result for Windows, OSX and Linux (maybe BSD) from Linux or BSD?
[+] Mayzie|4 years ago|reply
Note for prospect Lazarus users: they use their own widget toolset that looks quite dated and doesn't really feel native, especially outside of Windows.

They don't integrate Qt widgets or other frameworks properly.

[+] rubyn00bie|4 years ago|reply
I'd highly suggest using Dart and Flutter.

I've probably written GUI apps in C, Java, Ruby, Objective-C, Swift, JavaScript, and probably a couple I forgot about. Dart+Flutter come the closest to being "good" and correct. There's some missing documentation for Desktop development with regards to Flutter + Dart but nothing is totally intractable if you're willing to read through issues. My only caveat is that Google is truly an awful company to depend on for your business; since, they 100% do not give a a single fuck about you unless you're paying them ~$100 million or more a year, or an EXTREMELY high profile client.

I've been getting ready to give Pascal a solid try but I still totally lose my mind when working in Lazarus (like where did the thing I just used go? Ah yes, tiny, free-floating window, of course). I have a feeling Pascal is probably the real diamond in the rough of UI application development these days.

Qt is probably fine but their licensing turns me off from ever using or considering it.

[+] mk89|4 years ago|reply
> Qt is probably fine but their licensing turns me off from ever using or considering it.

If I may ask why? They provide GPL and LGPL, and this last one is quite permissive.

See: https://www.qt.io/licensing/open-source-lgpl-obligations

> In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library. In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.

[+] jestar_jokin|4 years ago|reply
Doesn't Flutter fail point 1: all widgets are custom rendered (OpenGL) things? So integration with the host OS's capabilities may be lacking (e.g. accessibility features).
[+] mariocesar|4 years ago|reply
Qt has been mention a lot, it's confusing all the license deal. I kind of understand that is free of use if it's not embedded.

But flutter looks like a good option.

[+] wongarsu|4 years ago|reply
Sciter [1] is kind of a really lightweight electron. It's about 8Mb, cross platform, and you can either run it standalone (like electron) or use it as a library from Rust/D/Python/C#/whatever. You pay for the small size with a lack of compatibility with the existing Javascript ecosystem. Any moderately complex JavaScript library that interacts with the dom will probably use something that Sciter doesn't implement, so you end up reimplementing stuff like graph libraries. On the other hand there are a couple of very useful additional APIs that regular browsers don't have (like SQLite, control over window borders, transparent windows etc).

1: https://sciter.com/

[+] arpyzo|4 years ago|reply
I personally like wxWidgets: https://www.wxwidgets.org/

It's open source, the code has always felt reasonably clean to me, and it gives your apps native look and feel.

[+] Shorel|4 years ago|reply
I second this choice. It is the only toolkit that looks native in Windows.

And it is ridiculously fast compared to alternatives.

[+] mshekow|4 years ago|reply
I've successfully built apps with Python and Qt (PyQt6 and PySide6 are both working fine). The overall file size of the resulting folder is about 60-80 MB on Windows, mostly due to all the Qt DLLs/plugins you'll need to ship. By manually deleting non-necessary DLLs, you might save maybe up to 20 MB. Just considering the file size, this might not a huge gain compared to Electron, I suppose?

However, keep in mind that desktop apps have the major disadvantage of figuring out distribution (separately for each platform!!), which includes the following two steps: 1) packaging the application in some format (e.g. an MSI installer for Windows and a Disk Image Bundle for macOS), and 2) distributing that package (including auto-updates). I have written a number of articles about this topic, see https://www.augmentedmind.de/2021/05/30/distributing-windows... and https://www.augmentedmind.de/2021/06/13/distributing-macos-a... . You get rid of all that if you just built a PWA or other kind of web app.

In addition, if you use Python, you also need to choose a "freezing" solution, such as PyInstaller (more details at https://www.augmentedmind.de/2021/05/16/distribute-python-ap... ).

[+] mynegation|4 years ago|reply
https://tauri.studio/ - I haven’t used it myself but looks pretty interesting. They say they use existing browser engine shipped with OS and desktop integration layer written in Rust. The claim is that you get an application size under 1MB
[+] tlackemann|4 years ago|reply
Used this for a small linux GUI proof-of-concept.

I really liked it. It was awesome to use something I'm familiar with (Next.js) and have it drive the UI. Resulting application was indeed about 1MB after all said and done.

[+] gitgud|4 years ago|reply
Interesting, but say good by to consistency across platforms.

The whole reason electron was created is because using a random unknown browser on the OS has random results.

[+] sto_hristo|4 years ago|reply
Can you share any insight in the cross-os implementation inconsistencies of those browser engines?
[+] phkahler|4 years ago|reply
In Solvespace we use native GUI on Windows, MacOS, and Linux (GTK). This is probably not what you want to do, as we don't use any GUI widgets - only popup dialogs and menus. Everything in the app itself is rendered using OpenGL. Even our "text window" is drawn using OpenGL and GNU unifont (this is something that really needs to change BTW).

The platform abstraction code is here: https://github.com/solvespace/solvespace/tree/master/src/pla...

There is no other platform specific code anywhere in the app, but like I said above we don't support widgets.

There is also an emscripten port in a branch, but it doesn't want to build recently.

[+] riskneutral|4 years ago|reply
> our "text window" is drawn using OpenGL and GNU unifont (this is something that really needs to change BTW)

What would you change it to? I've implemented a GUI toolkit from scratch a couple times, and text editing was the hardest part by far.

[+] tomcam|4 years ago|reply
How’s accessibility?
[+] graynk|4 years ago|reply
I am making a simple image editor for myself to use on Linux, and honestly? After looking at different bindings for Qt and GTK on Go/Rust/Java and looking at other GUI frameworks (all of which are in beta state, it seems) I went back to Java+JavaFX.

There's a decent GUI markup editor (Scene Builder). There's no need to manually connect your handlers from XML markup to code - you can use annotations for that. There's HiDPI scaling that you can override if need be. There are Observable properties that you can bind to each other.

It's nice! Canvas and DrawingContext are a bit of a pain to use for my specific use-case, since it draws straight to buffer with no underlying Image, but I make do for now.

And you can take advantage of jlink to trim your JDK to modest sizes. There are also tools like Graal Native and Liberica Native Image Kit to compile your Java app down to binary, but I haven't toyed with those yet.

The cons are obvious: non-native look (you can try to style it with CSS, but there are no ready-made native looking solutions, I think, only different themes) and JVM startup time.

However, if you're willing to write C++, I'd argue Qt is the best choice right now. I just refuse to touch C/C++ with a ten-foot pole

[+] graynk|4 years ago|reply
UPD: I checked out Graal Native. It was somewhat painful to make JavaFX work with it, due to reflective nature of the framework (which does not work very well with Java Modules), but I managed to make a native image with Gluon plugin for Maven. And it starts up FAST, I like the result.

[0] - https://docs.gluonhq.com/#_gluonfx_plugin_for_maven

[+] amw-zero|4 years ago|reply
The trade off is always between cross-platform and native integration. For example, do you want to write an app that feels like a MacOS application? You have to use AppKit to really get that feel, and then it’s not cross platform.

There’s really 3 choices that I see, and have done all of them:

1) just build native UIs for each platform. This is the most time consuming, but the best end result in my opinion. The apps _feel_ the best on each platform

2) make a web app. Electron apps are still web apps.

3) hybrid approach, where part of your logic is shared across different native UIs, let’s say with a C++ / Rust / Java / Kotlin library. This is also a spectrum. Your library can just have common glue / networking code, all the way up to drawing its own graphics before turning a full screen over to the native UI framework.

I guess there’s also 4, which is Flutter, but that’s really just a pre-packaged #3.

If you ask me, web just has the best delivery model, and that trumps everything. Responsive web app plus a native option via Electron is the way to go.

[+] mikewarot|4 years ago|reply
I've decided to dust off my somewhat rusty Lazarus, GIT and GitHub skills to build a Lazarus application to follow this thread using the HN API hosted by firebase.

You mentioned getting data to a GUI application using the web, this seemed like an ideal small project that could give you a firmer idea of just how Lazarus might fit your needs.

Notes:

I've never done anything like this (https/json) before but I suspect I'll be done in a day or two. Once it works, I'll then focus on getting it to also run in Ubuntu. I don't have a Macintosh, so that's out.

I've GPL 3.0 licensed it.

I'm not near the MVP yet, but it does manage to fetch the data and count the JSON objects in it for the main body of this thread.

With Debug info, the windows executable is 25 megabytes, without it 3.1 megabytes.

Here's the github link: https://github.com/mikewarot/WatchHN

[+] mikewarot|4 years ago|reply
Update #1 - there is FAR far more going structure wise in threaded comments than I first realized, but I eventually managed to just read the raw text.

Formatting, adding dates, etc... will be a bit more still.

[+] occz|4 years ago|reply
The honest truth is that there is no good alternative here - there are only alternatives that are terrible in their own way.

Electron: Bloat, non-native, highly questionable language

Other cross-platform solutions: Obscure, (most often) non-native, undesirable language constraints, often far behind with regards to UI paradigms

Native UI for each platform with common code: requires deep knowledge of each platform, probably more time consuming than the other alternatives, the seam between common code and platform-specific code is often a source of errors

Fully separated native applications: Likely to produce the highest quality UIs, but requires the most diverse knowledge and time, more difficult to remain consistent across implementations, team size becomes an issue depending on how many platforms are supported

As much as I dislike Electron-applications, it's understandable why they became adopted so widely - the alternatives are just quite simply not great.

[+] joeld42|4 years ago|reply
It depends. I've built a lot of these. The best approach is to keep the UI very lightweight and just build it using native controls for each platform. Keep all the application logic in a common library and just rewrite the parts that are interactive. This isn't as much work as it seems, especially if you design it upfront, and there's no other way to get a native feel. There's also some "product management" advantages to this approach, such as building new features first on your smallest platform so you can test/iterate quickly with few users and then moving them to Windows when they are proven. Don't build new features on all three at once, take turns.

If the app has a whole lot of dense UI screens, or if you don't particularly care about it looking nice and feeling platform native, something like Qt or many of the other frameworks suggested here work well, but do be aware that you'll be making it harder to use platform features. For example, on MacOS you wouldn't support the TouchBar and would have some extra complexity to support Metal graphics vs GL (which Qt supports).

You can also do something similar to Electron but much more lightweight using a platform WebView. Then you can have common controls built in a htmlish way, and still have custom and native controls mixed in. One example of an app I worked on that was built this way and worked well was an app to browse/view 100s of video clips, we had a common html-based widget to filter and display search results and thumbnails (which had a bunch of interesting layout requirements) but the video playback itself was in a native panel (it needed to play custom formats so using web for everything wasn't appropriate).

Flutter looks promising but it still feels a little early. Try it out if you're willing to take some risks and maybe bend your thinking a bit. I found it too indirect and felt like I had to give up too much design responsibility to the toolkit when I last tried it but maybe that's an advantage.

If you're thinking about Electron, why not make it a purely web app? Then you'll save yourself lots of hassles distributing and downloading.

Also, for graphically intensive or in-house tools (like a game level editor) i use Dear ImGui, it's very fast to develop and great cross platform support, but I wouldn't ship it to a customer.

[+] prewett|4 years ago|reply
As far as I am aware Qt is the only cross-platform toolkit that has reasonable traction, and it has been successfully used by commercial applications. Other cross-platform applications are either so old that there was no other choice but to write their own toolkits, or they are web browsers where you might as well write your own toolkit since you already have to do much of the work to render the HTML.

Unfortunately, "well-integrated" and "cross-platform" are fairly mutually exclusive, kind of by definition. I'm not sure if the API model for Windows and macOS even have a generalizeable common model. (They might, they might not, I've not investigated, and it would depend on which of the many MS UI APIs you are using)

[+] ppetty|4 years ago|reply
So just for the sake of completeness, maybe, and since Electron seems to be the most popular solution; what about a website? Fairly ubiquitous across all platforms with the help of Chrome, Firefox, and even Safari or Edge. I don’t think should be dismissed as often as is, consider VS Code on Github.com (hit the period key in a repo and the repo’s code is presented with VS Code in a browser — and it supports syncing extensions — though not all, for example).

To me it makes sense from tne perspective of the work being done in HTML, CSS & JS to make an Electron app. Why not start as a website then desktop?

I get there are certain pieces of functionality not suited for a website; but based on the original post’s question and description it seems feasible.

[+] mariocesar|4 years ago|reply
I need to read/write to the filesystem, think the app is like a personal document manager. Also will like to associate filetypes with it, and for the most important thing is being able to send notifications and make sure my backend is syncing data all the time