top | item 32398181

Ask HN: How to make a native GUI with a modern language?

87 points| throwaddzuzxd | 3 years ago

HN has strong opinions against Electron so here are my requirements:

- I want to make a native looking GUI

- Cross platform (macOS, Windows, Linux)

- With a sane language (no C, C++ or Objective C)

- Ideally with a data flow looking like unidirectional data flow / Elm architecture

What options do I have?

140 comments

order

ceronman|3 years ago

Having a native looking GUI and being cross platform is almost contradictory. The only way to make truly native looking and feeling GUIs is to use native tools. That means Cocoa on macOS, Gtk or Qt on Linux, and Win32/Winforms/WPF/WinUI on Windows.

Most cross platform frameworks won't really look 100% native. The only exception I know is wxWidgets, which provides an abstraction layer over the native toolkits. It's written in C++ but there are bindings for Python, Ruby and other languages. But even using this, apps might not feel truly native. There is more to nativeness than looks. It's also about subtle conventions and ways to do things. You only achieve this when you use a native framework and pay a lot of attention to the HIG guidelines of the OS.

My personal (and perhaps a bit unpopular) opinion is that native looking is a bit overrated. And it's mostly macOS users who look for this. Linux and Windows users already get a lot of diversity in their looks and feel because there is no single framework for those OSes.

More important than native looking is to have a GUI that is fast, efficient and accesible. The best option that provides this in a cross platform way is QT. Java Swing and JavaFX are also good options.

The most productive tool to have cross platform GUIs right now is Electron. That's just a fact. And it's the reason why so many modern products are using it. But as we all know, there is a price in efficiency.

There are a bunch of new projects in the works to improve cross platform GUI for modern languages. JetPack Compose Desktop, Flutter, Slint and many more. But these are not yet fully mature.

bpye|3 years ago

> More important than native looking is to have a GUI that is fast, efficient and accesible. The best option that provides this in a cross platform way is QT. Java Swing and JavaFX are also good options.

I would echo this. Consider applications like Photoshop or Blender, these don't really have a 'native' feel anywhere but their UX is generally responsive. On the other hand you have Electron applications that don't feel native and are also sluggish...

marwis|3 years ago

Besides wxWidgets there's also SWT for Java which also wraps native widgets.

register|3 years ago

The other one is Eto.form for .Net and .Net core. Same concept as WxWidgets.

mattgreenrocks|3 years ago

> HN has strong opinions against Electron

Beware the bias of the loud minority. For every 1 noisy user, there may be 50 quiet users who are fine with the decision to use Electron.

Shipping beats not shipping every time, and if Electron is what you need, then do it. I say this as someone who does not like Electron, but also as someone who knows that writing comments on HN is 100x easier than actually shipping production software.

Gentil|3 years ago

I usually agree with this sentiment of shipping vs not shipping. But Electron is just really bloated. You cannot install 10 apps and regularly use it. Most systems will just hang or crawl. Systems with 8GB should not be hanging because you are using 10 apps.

I have 16GB RAM and even then I feel the hog with Discord, Slack, VS Code, A note app taking up too much memory. Then there is unnecessary security risk of bringing all the browser issues along with it.

People shouldn't have to buy an expensive Mac books to use normal apps. That should be for MLOPS or other processing heavy tasks.

Also, an Electron app uses anywhere around 150+MB to 400ishMB ram on normal cases. For one app.An app like QOwnNotes uses only a small portion of it. 50MB-100MB max. So when you you add just 10 electron apps, the number just blows up.

I feel like whatever progress with performance we are making with processor is just cancelled out with things like Electron. That is just sad.

So no. I don't think this is a good example of loud minority scenario.

dspillett|3 years ago

> HN has strong opinions against Electron

Beware the bias of the loud minority.

Hear hear.

Though depending on the application(s) in question, if JS and things that traspile to it are attractive to the developer then they could also consider an offline-first/-only web app. Not practical for everything and adds its own family of potential complications, but worth considering.

> but also as someone who knows that writing comments on HN is 100x easier than actually shipping

As someone who has a huge pile of projects just waiting to be started (and one or two languishing in a PoC state) I think your 100x factor is more than a little too small!

thrwawy74|3 years ago

Part of me wonders why someone hasn't tackled creating an Electron runtime service, so that each installed app doesn't load what could be a shared library into memory. There's a host of complicated problems there, but if the major issue is fat runtimes it can be pared down like Chrome workers.

garblegarble|3 years ago

I hate to say it, but I agree - I dislike the number of Electron apps I have to use, however...

I spent a few hours last night on a personal project trying to get something relatively simple working as a SwiftUI macOS app. I needed to customise a bunch of components to get it close to what I wanted.

I decided to give Electron a go, and had what I wanted up and running quite literally in 5 minutes, and it starts and is responsive within 500ms. It's taken longer to figure out how to ship it as a .app package than to write the code. That's nothing short of amazing.

lvass|3 years ago

Does the "native GUI" requirement not exclude Electron, though?

bool3max|3 years ago

The "minority" may be loud but their comments are usually heavily upvoted.

socialdemocrat|3 years ago

One unusual alternative you may not have thought about is using Godot Game Engine. Before dismissing it, consider this: Godot engine is shockingly small for what it does. The download is about 30-40 MB. The GUI designer tool is second to none, and you can make highly interactive advanced GUIs using a language that looks very much like Python called GDScript. It is very quick to learn.

It does make GUI which are native to the platform but you get a small native binary which renders OpenGL.

Is Making Advanced GUI Applications with Godot the Future? https://medium.com/swlh/what-makes-godot-engine-great-for-ad...

d--b|3 years ago

I really wanted to try this out, but the learning curve for godot was a little steep, cause there is all the game related stuff I don’t really care about. Any tutorial to create a simple app with a few controls?

withinboredom|3 years ago

Wouldn’t that seriously hurt laptop battery life to use a discrete gpu to render the UI? Or is there someway to tell the OS that a non-discrete gpu is fine?

ghishadow|3 years ago

How is accessibility? best thing about Electron is we get accessibility of Browser

socialdemocrat|3 years ago

I write native GUIs in GTK using Julia at the moment. Julia is one of the most modern languages you can use today. Multiple-dispatch, very functional, modern package management and virtual environments, high performance, modern sophisticated REPL environment. GTK is quite nice as Glade is one of the nicer GUI designers.

Here is a simple Julia GTK project on GitHub: https://github.com/ordovician/RocketBuilder.jl

Some articles I wrote related to GTK programming with Julia and GTK in general:

- Understanding GTK Layouts: https://itnext.io/understanding-gtk-layouts-13e5a36256fa

- Hiccups Writing GTK3 GUI Code in Julia: https://towardsdev.com/hiccups-writing-gtk3-gui-code-in-juli...

If Julia is not your cup of tea then GTK can be used with Go and Swift as well.

alhirzel|3 years ago

Have you tried / had good luck doing static compilation of Gtk applications?

Dracophoenix|3 years ago

The big problem with GTK is backwards compatibility or, more precisely, the lack of it. I don't know how it has or hasn't impacted your own work, but I would hold off on recommending GTK to OP unless he/she is aware of this caveat.

tomcam|3 years ago

Does GTK run on windows and macOS also?

okso|3 years ago

Qt for Python may be an option: https://doc.qt.io/qtforpython/

While the Qt API is imperative (`self.layout.addWidget(self.text)`, ...), focusing on declative Qml whenever possible helps with a more declarative approach.

lbriner|3 years ago

I hate to stick my neck up here but looking at this recently, I think that in trying to get cross-platform, you might end up with a lot of pain and not that great results. Instead, I would go for getting 3 devs and writing an app in a native language on each OS. You can refactor the business logic into a dll using some standard languages like C/C++ (they aren't that bad) and possibly Python and then just build the front-end in the native framework.

Why? The only way to get a truly native look and the ability to specialise for each OS. Maybe Windows does threading better than Linux and can be optimised in some way. Maybe Linux has some nicer native UI controls that could make that part better on Linux.

Otherwise cross-platform mostly means a UI that is not native looking on any platform. Haven't used QT recently but of all I used, that was the closest to what you are asking for (I was using C++ - sorry, it's not that bad!) but I think there are bindings in other languages, although they might well have some bugs compared to the basic C++ version.

apitman|3 years ago

If you go this route I would mention that I had a really good experience creating a C library in Rust. Lets you use a modern language for your shared logic but still be very portable. I believe you can do the same thing with Zig and maybe Nim as well. And there are probably others

ziftface|3 years ago

I agree with this (except for the bit about C++ but that's neither here nor there) but what I landed on was that maybe a native look isn't as important as I thought. Some of the nicest apps I've used just have their own look. They're still native and very quick, but they use their own UI toolkit that doesn't fit the system. For example nheko, ripcord, blender, sublime merge, etc.

PaulHoule|3 years ago

Personally I like JavaFX.

I made something pretty complicated with tkinter and Python. It's not that hard to do but the result looks awful, it doesn't support many features people expect in 2022, and the documentation for using tk in Python is poor. You probably need to refer to the tcl/tk documentation and translate it in your head to apply to Python.

As much as people hate Electron, the rendering engine in a web browser is head and shoulders better than any other cross-platform system and I think it's a sane model for programming. The main trouble w/ Electron is that you have 30MB of runtime for any application, even if it something that could be coded in a 25k .EXE file based on Win32.

invalidname|3 years ago

JavaFX is terrible and I'm a Java fanboy. It isn't native looking so it doesn't satisfy the requirements outlined above. You can get a facsimile of "native" but at a lot of effort and for specific cases.

But the problem is the deployment story. It requires native libraries so you need to package it somehow. Ideally, one day GraalVM will support JavaFX. That day isn't here. So you need JavaPackager which is one of the more awful ways to deploy anything at scale.

It pains me to say it as a Java fan, but most people will be better off with Electron.

thiht|3 years ago

I used JavaFX a while ago and hated it. It was insanely slow, fonts were awful and the lib of components was non existent.

It really felt like something created by someone but never used in the real world. Is it even used anywhere?

codeptualize|3 years ago

I haven't used it myself (yet), but https://tauri.app/ looks very promising as Electron alternative.

It uses the OS's browser so it doesn't have the bundle size issue you describe.

TrianguloY|3 years ago

I'm mainly a java developer, but I hate the built-in Swing gui. I tried once JavaFX for a medium project and quite liked it, specially since you can use Kotlin with it and also because you can compile it to a portable executable easily (with a built-in jre, not an exe but at least you don't need to install anything).

rr808|3 years ago

> trouble w/ Electron is that you have 30MB of runtime for any application

JavaFX has the same problem? Or you rely on user's JREs already installed? I'd think 30MB really isn't much any more.

awinter-py|3 years ago

quark / sciter isn't OSS, and I've never used it, but they claim they can bundle something like electron (JS backend, web frontend) into a 5mb binary

cosmotic|3 years ago

JavaFX is not native, nor can it be made to look native like Swing can be made.

Apreche|3 years ago

Depending on your application, write as much of the core functionality as possible into a cross platform library and/or server in your language of choice. Expose all functionality through a strong API.

Now you can build completely native GUIs in the appropriate language for each platform. Start with the platform which will likely have the most users for the application. Bonus if the application is open source, other developers will build all kinds of native GUIs for you. Just look at how many GUIs are out there for things like PostgreSQL, Git, IRC, etc.

I know this doesn't exactly meet your requirements, but I think this is the way to go if starting something in August 2022.

crabbygrabby|3 years ago

Hate to say it but, this is one of the biggest tragedies of modern CS. Best bet is to use gtk, or qt, and hope the language bindings for your lang of choice aren't horrible (depending on the language you might be in tears)

kweingar|3 years ago

Most computer scientists I know barely care about anything graphical or user-facing. I don’t think this is a huge tragedy to them, at least when compared to software developers.

immigrantheart|3 years ago

Can you elaborate more? I actually don't quite understand this statement.

desireco42|3 years ago

Strange nobody mentioned Tauri, it is really pleasant experience to use and good solution. It works really well for what it does, it is still not covering all features and everything, but it is more performant and more secure alternative to Electron.

I was considering using it for some app that otherwise would be PWA. While I didn't use in-depth features and didn't run into any serious problems, it is likely that not everything will be perfect, but it is also likely that overall experience will be more pleasant.

https://tauri.app/

Check it out.

bodge5000|3 years ago

Flutter seems like the strongest option right now

Though overall, its not an uncommon issue. I've found myself in the same place multiple times, I've even considered using a lightweight game engine just for their UI features. But next time I run into it, I imagine Flutter will be what I go with

Edit: Just realising you said "native-looking". Not so sure about Flutter for that, I'm not sure such a thing exists.

Morthor|3 years ago

There are UI packages for desktop OSes with the native designs.

neverartful|3 years ago

Objective-C is not sane? Have you ever tried it for anything non-trivial? I know that it's not perfect and it's syntax is unappealing to some. I did iOS development for a few years (pre-Swift) and I really enjoyed using Objective C. I found it to be efficient, intuitive (once you get acclimated), and very pragmatic.

There are some very powerful capabilities in Objective C (like swizzling) that can be of tremendous help when you have some oddball functionality to implement. This would be conceptually very similar to the monkey-patching that folks do with Python. Perhaps this is the sort of thing that makes it not sane to you?

WorldMaker|3 years ago

MAUI in .NET 7 checks many of the boxes you have here:

- Native looking: MAUI supports native controls as much as possible

- Cross platform: Nearly everything but Linux today (and there are forks out there trying to bridge that gap); macOS (Catalyst), Windows, iOS, and Android

- C# as the default .NET option is a very sane language. Other options may be possible with more effort. (Some people are still working on that.)

- MAUI's focus is still on declarative XAML UI with databinding (MVVM), but there's a growing community for MVU (vaguely Elm-like) architecture including some official out-of-the-box support now.

zerr|3 years ago

It doesn't support the second most popular OS (Win7) which still holds the quarter of the market share.

taumoeba|3 years ago

I just spent the past three months building a custom GUI framework in C# using OpenTK, which is basically just a C# wrapper for OpenGL. It's inherently cross-platform because of .NET. [1]

After finishing, I regret spending so much time on it. For my use case, I think it would have been a better use of time to just use Electron. At least until .NET MAUI has Linux support, which is looking very promising.

[1] I haven't tried MacOS because I don't have a Mac and I believe it has OpenGL compatibility problems. It works great on Windows and Linux though.

prewett|3 years ago

All the well-known cross-platform toolkits are C/C++, so you'll have to find bindings for whatever "sane" language you want to use. Your options are basically:

- Qt: the most widely used, but is a little janky on macOS and they've been going down the JS route recently

- wxWidgets: is a possibility, I haven't used it in a long time.

- GTK: "native" for Linux, but technically cross-platform. However the experience is lousy (and it is C, not even C++)

- JUCE: another long-standing, somewhat niche toolkit, but I've never used it or anything written in it.

- Flutter: must use Dart as the language, as far as I'm aware. Also, not sure how native-looking it is.

There are also Java and C#, but I've never used a Java UI that looked or felt remotely native (or even "good" for that matter). Haven't used any C# apps but I assume some toolkits exist.

mikewarot|3 years ago

Why the emphasis on "unidirectional data flow"?

I happen to think Lazarus (based on Free Pascal) is great, but it's not a functional language at all.

gorjusborg|3 years ago

Do you have any examples of apps that use that tech?

thiht|3 years ago

I find it easier to reason about.

dexterlagan|3 years ago

If money is no object, Xojo fits the bill. Native UI, cross-platform Win/Linux/MacOS/iOS/Web and soon Android. Simple language, LLVM performance and lots of libraries.

In the free world, I'd say Racket is the next best thing. Native UI, runs on anything. But you have to fall in love with Scheme. It's easy for me, I'm already sold.

I haven't found anything else that a) doesn't break in production, or 2) turns out to be a giant pain in the.

Gentil|3 years ago

Curious why Kivy framework which uses Python is not even mentioned. Is there something that I should be worried about? I am planning to learn Kivy soon.

Ancapistani|3 years ago

Well, that set me on a side track :). I thought I'd share my experience here.

I've looked at Kivy in the past, but it didn't seem mature enough to rely on, especially for deploying to iOS/iPadOS. I just spent a couple of hours going through their documentation, building their example "Pong" app, and deploying it to macOS, iPadOS, and Android. All went off without a hitch, though I didn't mess with signing or trying to release them to the various app stores.

I'm going to say Kivy is more than capable of the things I'd want it to do. Looks like the roguelike I've had in my head may make it onto the screen in the near future!

poulsbohemian|3 years ago

Why do you want this app you are building to be cross-platform?

You've shared technical requirements, but you haven't shared business requirements. You should ask yourself whether you can actually achieve your business / user ends with a cross-platform approach. The three platforms are unique and users across the three have different expectations. For example as a Mac user, unless the software is super specialized such that there isn't any competition, a native Mac-focused solution will always be preferable to something that "kinda sorta" looks and acts like Mac software.

Without knowing the purpose of the software you are building, one has to really wonder if it needs to be native or should rather be a web app (for example), or even mobile first or tablet preferred.

Just some thoughts.

ydnaclementine|3 years ago

GTK or QT with python. Electron is probably fine if you want to use web technologies/JS ecosystem instead

andrewmcwatters|3 years ago

I mean, how native are we talking? Cross-platform native? Or platform native? Platform native UIs require you to actually read things like the Apple HIG, or the Windows Design Guidelines, and then create language-specific bindings to those operating system controls.

If you don't actually care about creating platform native UIs, you'll always be creating something that is a second-class design while putting in first-class effort. Why?

Frankly, you're better off just learning the operating system platform native UI programming language and get over yourself if you want to create something that looks like it was actually designed for the OS you're using.

And really, it's immature and insulting to call languages insane. Suck it up, these are peoples' professions here. No one wants to read that.

taffit|3 years ago

Another unusual alternative could be the V-language [1], depending on if you consider this a "sane language" ;-). Not having used it myself and obviously you have to consider other arguments as well (community, developers, development activity, documentation etc.), but I was caught on all the features it promises, e. g. a "Native cross-platform GUI library": "V has a ui module that uses native GUI toolkits: WinAPI/GDI+ on Windows, Cocoa on macOS. On Linux custom drawing is used."

[1] https://vlang.io/

tored|3 years ago

Writing cross platform desktop applications is series of compromises in the technical requirements you may have. You should prioritize each requirement from top to bottom. Then start removing requirements from the bottom and compare against available technologies, iterate this process you will find out what is truly important and what compromises you are willing to make.

Personally I searched for many years for the perfect GUI system, the unicorn, but never found any. By doing a stricter prioritization I came to the conclusion that writing in a modern language is overrated.

pipeline_peak|3 years ago

Not quite sure what your definition of a “sane language” is. Pretty much all guis in the industry involve one of those three to some extent.

Maybe look into Skia, it’s Googles abstraction layer for multiple graphics libraries on multiple platforms.

But if you are just learning, I wouldn’t concern yourself with any of those sort of environment conditions, just figure out how to make something that works on your preferred OS.

For example, if you use Windows, learn 2d rendering with direct x. Learn about event handlers for controller interaction. And of course read about MVC.

pull_my_finger|3 years ago

How much do consumers really care about the native feel? Is this even an issue? There are so many graphic libraries that can create all the needed components, I wonder if people even _want_ those OS-centric styles on the buttons/window borders etc etc. Maybe it's the web developer in me that has been pressured to do the opposite: consistent styles across all browsers. Platform quirks are a headache, not the goal.

rschachte|3 years ago

Go is fantastic and also has a native UI framework called Wails. Not connected to the standard lib, but I believe it started in Google

86J8oyZv|3 years ago

I’m shocked to not see Flutter supported here. It’s not truly truly native I guess. But Dart is very modern and capable and the Flutter framework is better for building native UIs than nearly anything else out there. It’s also ridiculously developer-friendly to get builds going for all your target platforms quickly.

1ark|3 years ago

Many answers here are not well researched. There is not much of a selection of options for your requirement. I also imagine you want the app to be accessible then because of the three platforms? The only option then is Qt with whatever binding to your "sane language".

Cross platform GUI toolkit is a very underdeveloped area.

moasda|3 years ago

Maybe not modern enough but I like to use Lazarus to create native desktop applications. It compiles to several platforms with a small footprint. It's based on Free Pascal.

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

cmacleod4|3 years ago

Not everyone considers Tcl to be a same language, but if you are willing to approach things a little differently Tcl/Tk can be very effective in the space you are looking at.

cmacleod4|3 years ago

Sorry, s/same/sane/.

Also "modern" is in the eye of the beholder. There are many features that Tcl had long before some of the supposedly more modern languages. In some areas like single-file deployment of applications it's arguably still ahead of its newer competitors.

Crungus|3 years ago

So you want to make a native GUI without a native language? Rust might be "a sane language" but it is not the best at GUI, the best tool I've tried is Qt.

jimbob45|3 years ago

Are C# WinForms or VB.NET not the right answers here for some reason?

WorldMaker|3 years ago

WinForms will only look native on Windows. On cross-platform it generally looks like a mess. Also, even on Windows it may look native but it also looks "dated" generally.

ElemenoPicuares|3 years ago

I don't believe mono supports winforms on linux and I wouldn't classify VB.net as having a elm-like architecture with a unidirectional data flow... so yes?

hnthrowaway0315|3 years ago

Does it still make sense to use GDI or WinAPI to build GUI if the app is not large? I wonder what library did Bioware use to build the Aurora Toolset for NWN.

waspight|3 years ago

I think electron is great. It is easy to get auto updates to work and it is a fast way to get an initial release out.

aalhafoudh|3 years ago

Definitely Flutter. https://flutter.dev

samarthr1|3 years ago

Though, your milage may vary, as you still need to

1. Take care to ensure that you follow platform guidelines

2. Ensure that the view and controller are not tightly coupled

3. Ensure that whatever libraries you want to use have support for all platforms you want to support

4. Pray that you don't need something very platform specific (or need to use Bluetooth, which I am told is a huge pain)