
Ask HN: How to do cross platform GUI? - anang
In essentially every discussion about desktop applications there are a lot of comments about how not to build desktop apps, but very little sharing of resources showing how to do it right.<p>I’ve seen people defend electron, talk about core logic in a cross platform language and native gui code and any number of other options.<p>As a middle of the road developer I think it’s difficult to find any consensus (besides electron being both simple and hated).<p>What resources are there for building quality, functional cross platform desktop application?
======
fbelzile
If you require a UI that is pretty heavy, here is my pro* tip to save time
when developing for both Windows and macOS.

1) Buy a basic HTML template online for your app's dashboard.

2) Don't use Electon. Your users WILL notice and complain about performance.
Instead, use the native WebBrowser control in .NET for Windows and WebView
using macOS to display your UI. Disable right clicking and highlighting using
HTML/JS. To the user, it'll feel like any other native app. Add this meta tag
to the HTML file to ensure the WebBrowser control knows to use new versions of
IE to render the UI: <meta http-equiv="x-ua-compatible" content="ie=edge">
(and/or look up how to add the FEATURE_BROWSER_EMULATION registry key)

3) Use the built in script calling functions to transfer settings back and
forth between the UI and main app in JSON. Do the back end stuff in native
code.

4) You can then re-use most of the UI code you wrote to easily port over to
macOS. Use the same functions and logic you wrote on Windows to make your
Swift functions.

* I've been making a living from building/maintaining my desktop application for about 5 years and had no regrets setting it up this way. I've also seen a number of other expensive, high-end, "professional" software using the FEATURE_BROWSER_EMULATION registry key trick.

Good luck!

~~~
bgdam
> 2) Don't use Electon. Your users WILL notice and complain about performance.
> Instead, use the native WebBrowser control in .NET for Windows and WebView
> using macOS to display your UI. Disable right clicking and highlighting
> using HTML/JS. To the user, it'll feel like any other native app. Add this
> meta tag to the HTML file to ensure the WebBrowser control knows to use new
> versions of IE to render the UI: <meta http-equiv="x-ua-compatible"
> content="ie=edge"> (and/or look up how to add the FEATURE_BROWSER_EMULATION
> registry key)

Going to heavily disagree here. Whether or not your user's will notice is
debatable in itself, but you shouldn't really factor that into your decision
making.

Instead you should ask if your users would care that it uses Electron, and
more whether they would be sufficiently put off to look for alternatives. And
in a vast majority of cases the response to that question is going to be 'No'.

But the second part of this comment, I disagree with even further. DO NOT USE
A NATIVE WEBBROWSER CONTROL FOR YOUR DESKTOP APP's UI.

Sorry for yelling, but that really is that terrible an idea. Most native
webview components lag behind the embedded chromium instance Electron uses by
a lot. Basic things that would work in IE10 are known to break on desktop
webviews. Primary reason for this is that these webviews are only updated with
OS updates.

End result is you will have to bend over backwards to get your UI working as
expected on all these native webviews. This is just too much work and will end
up diverting attention from developing core features of your app to fixing
rendering bugs instead.

~~~
zelly
I seem to remember a lot of Windows programs back in the day were webviews
(backed by IE of course) and it was the most horrible unprofessional looking
thing, especially when an Alert would pop up which revealed it was just an IE
page.

Webviews are okay on mobile though.

~~~
dexterous
> I seem to remember a lot of Windows programs back in the day were webviews
> (backed by IE of course)

Just how far "back in the day are we talking? 'Cause I've see stuff ranging
from VB (just VB, no .NET or WinForms) all the way back to MFC based UIs back
in _my_ day. :)

I just feel like we should get our timescales calibrated.

------
UnnoTed
The stable options for native cross-platform GUI are:

1\. Sciter

\- Languages: C++/Python/Go/Rust/Pascal (optional: HTML/CSS/tiscript)

\- Development time: fast

\- Resource usage: light (space and performance)

\- Visual customization: easy, doesn't use native widgets.

2\. Qt

\- Languages: C++/Python (optional: CSS/JS/QML)

\- Development time: slow

\- Resource usage: quite heavy (space), but well performant

\- Visual customization: QtWidgets: hard, QML: easy, doesn't use native
widgets.

3\. WxWidgets

\- Languages: C++/Python

\- Development time: slow

\- Resource usage: light (space and performance)

\- Visual customization: hard, uses native widgets.

4\. Lazarus

\- Languages: Pascal

\- Development time: slow

\- Resource usage: light (space and performance)

\- Visual customization: hard, uses native widgets.

[1]: [https://sciter.com/](https://sciter.com/) \-
[https://quark.sciter.com/](https://quark.sciter.com/)

[2]: [https://www.qt.io/](https://www.qt.io/)

[3]: [https://www.wxwidgets.org/](https://www.wxwidgets.org/)

[4]: [https://www.lazarus-ide.org/](https://www.lazarus-ide.org/)

~~~
pkphilip
I am not sure what you mean when you say that the development time on Lazarus
is slow.

I would actually say that it is perhaps the fastest in the list.

~~~
UnnoTed
Lazarus allows you to design the UI quickly, but theres a lack of third party
libraries when compared to the mainstream programming languages.

1.1k [https://github.com/topics/pascal](https://github.com/topics/pascal)

27k [https://github.com/topics/cpp](https://github.com/topics/cpp)

161k [https://github.com/topics/python](https://github.com/topics/python)

~~~
pkphilip
Lazarus already comes with tonnes of components (over 200) and lots of
libraries but yes, it is still possible that you want to access some
functionality which is not provided natively by the built-in components. But
then, you may not.

------
miki123211
Whatever library you decide to use, you should definitely look at its
accessibility.

Even if you're not legally required to implement it now, and even if you don't
think this is a basic human right (which you should), there are legal changes
coming, and you never know when you will be forced to implement it.

If you choose a library with great accessibility support, even though your app
might not be accessible initially, fixing this won't be that hard. If you
choose a library without one, though, when the time comes, you will either
need to completely rewrite your app using a different library, or dig deep
into native OS code and figure out how to interface with accessibility APIs,
which is not an easy task.

This is a risk/reward scenario. The downside of choosing a library that
supports accessibility usually isn't that bad, putting personal feelings about
Electron aside. However, if you need accessibility someday, however unlikely
that might now seem, you really don't want to be forced to drop everything and
focus on rewriting that GUI layer fast, before the regulators catch you.

It seemed very unlikely that game developers would ever need accessibility, so
no one cared. Then, the US government mandated that all chat systems must be
accessible, and a lot of games include chat systems. That was not a pleasant
experience for anyone. You never know what is coming, and you don't want to
shoot yourself in the foot.

Now for some pointers. Electron is fine. No, really, Electron, is, fine.
There's nothing wrong with it. QT is fine too. GTK works, as long as all your
users are on Linux, as accessibility for other platforms is nonexistent. Java
works on Windows, not sure about Linux and Mac. Anything that uses native
widgets, so WX and native OS frameworks are the best, but not everyone can
afford the luxury of choosing those. Game frameworks and small, minimal
libraries are a no go.

~~~
fileeditview
While I of course do not oppose accessibility or Electron per se I think this
is bad advice.

0) All advice depends a lot on the product. Most general advice is just
useless.

1) Preparing for potential changes in legislation is most of the time not a
good idea. As you said you never know what is coming and so you should not try
to prepare for everything. Also said games you mention could probably disable
the chat if implementing accessibility features was to costly. Also these
changes don't come over night.

2) I really dislike what people try to cramp into basic human rights.. Do you
also expect this from open source software? Do you really think if people
spend their free time they are obligated to implement accessibility or
whatever else? In my opinion the user of open source is entitled too nothing.

3) Electron, is, not, fine, just, like, that. There are tons of Electron apps
out there which have no right to carry hundreds of megabyte with them and
consume that many resources. I am pro choosing whatever you want. But please
don't advert Electron as "is-always-fine".. If you even want to force
accessibility.. what about energy consumption?

~~~
cratermoon
As someone with presbyopia, _and_ light myopia that first developed around the
time I hit 30, who used to have _excellent_ vision, I promise you that sooner
or later you'll regret not thinking about accessibility.

For the record, the default choices for text size here on Hacker News are an
example of ignoring basic accessibility.

~~~
badsectoracula
You can change the text size on Hacker News, or any other site, without really
affecting everyone else though. Ctrl+Wheel is a common way.

Personally i have strong myopia yet i heavily dislike how large fonts are
everywhere and i prefer Hacker News' font size.

~~~
cratermoon
> You can change the text size on Hacker News

This I know. However, better-designed sites allow the user to customize the
default font size.

------
pkphilip
Please do test out FreePascal and the Lazarus IDE.

Why?

1\. Cross platform - Mac OS, Linux and Window and Raspberry Pi
[https://www.lazarus-ide.org/](https://www.lazarus-ide.org/)

2\. VERY fast development and compile-run cycles. You are talking about
WYSIWYG designer and compilation in seconds.

3\. Fully native binaries which are very small and very fast.

4\. It is a full fledged RAD environment with full support for GUI development
using a very powerful designer.

5\. There are GUI as well as non-GUI components - example: Database
components, Database-aware grids, database aware-listboxes, search filters
etc.

6\. Very diverse set of components. And very easy to develop new components
from scratch or customise and existing component.

7\. The object structure is very powerful - with support for read & write
properties, composite components, property setting pages, internationalisation
etc.

8\. It is possible to interface with C/C++ libraries as well and that isn't
complicated

~~~
Lammy
Could you please explain the relationship between FreePascal and Delphi? Is
there one besides common ancestry? The page here makes it sound like it's just
a class library and not a separate environment:
[https://wiki.freepascal.org/Delphi](https://wiki.freepascal.org/Delphi)

I ask because I'm a big fan of PowerArchiver as my go-to archive manager on
Windows over the usual 7-Zip/WinZip/WinRAR/etc, it's a Delphi app, and it has
a nice GUI: [https://www.powerarchiver.com/](https://www.powerarchiver.com/)

~~~
pkphilip
Free Pascal is the language and Lazarus is the IDE. In the case of Delphi,
Object Pascal is the language and Delphi is the IDE.

So it is best to see Free Pascal & Lazarus as the free and open source
alternative to Object Pascal & Delphi respectively.

Of course, now the term Object Pascal is not used at all. Delphi is used to
refer to both the language and the IDE now.

About Free Pascal, it is largely compatible with Delphi/Object Pascal but
there are minor differences.
[https://wiki.freepascal.org/Lazarus_For_Delphi_Users](https://wiki.freepascal.org/Lazarus_For_Delphi_Users)

Here is a write up on the advantages of Free Pascal:
[https://www.freepascal.org/advantage.var](https://www.freepascal.org/advantage.var)

~~~
Lammy
Thank you! That makes much more sense.

~~~
pkphilip
You are welcome! Please do give it a shot.

I am not associated with the Lazarus project at all but I did develop in
Delphi over 22 years ago and I still do some development using Lazarus. I hope
to do some tutorial videos on this to help those new to the environment.

~~~
Lammy
Were you a 68k-era Mac dev, by chance? That's my biggest mental association
with "Object Pascal". I was only old enough to be a beginner-level user in
those days and never got to ('had to'?) program anything on them, but it
always seemed like it would be fun to revisit and see that Other Side of my
childhood System 7 :)

~~~
pkphilip
No, I started with Turbo Pascal in the late 80s and early 90s and then moved
onto Delphi, Turbo C etc later. I programmed in Delphi till about version 7/8
when Borland decided to implode by going after "Application Lifecycle
Management" etc.

------
modeless
An underused option is to include a local HTTP server in your native app and
open it in the user's default browser. This avoids some of the resource
consumption and security issues that make Electron bad, but still lets you
integrate native code with a web UI.

I wrote a little framework for this: [https://github.com/jdarpinian/web-ui-
skeleton](https://github.com/jdarpinian/web-ui-skeleton)

~~~
takluyver
I've worked on some applications like this, and it works pretty well. But be
aware that a port on localhost is accessible to any local user - depending on
the application you may need to prevent other users accessing it.

Running inside a real browser also limits the keyboard shortcuts you can use,
because you don't want to clash with the browser's own shortcuts.

~~~
stragies
Can't this concern be easily alleviated by the backend requiring credentials,
and sending them along from the frontend? Getting around this as an attacker
means already possessing enough rights to not need sniffing the traffic to the
backend. Or is there more required?

~~~
takluyver
It can, but getting the credentials to the browser & storing them there isn't
entirely simple. If you launch a browser process to a URL containing a token,
an unprivileged local attacker can see it in the command line arguments (at
least on some platforms) and copy it. That can be mitigated by launching the
browser with a file:// URL which uses an HTML meta redirect to give the
browser the token.

The obvious way to keep the browser authenticated is a session cookie. But
cookies are shared between all ports on a domain, so a local attacker who
tricks you into visiting another localhost service in the same browser can
steal the cookie. localStorage doesn't have that issue, but it's not so
convenient for authenticating requests.

------
tlack
It all depends on the nature of your application. A video editor and a command
line utility are so different!

Sounds like you already know the big players so I won't repeat them. Instead,
here are some off-kilter ideas:

1\. Casual use, general interest, notification-requiring, simple single-file
data requirements, tolerant of desktop / mobile split sessions? Try making a
chat bot for Telegram, FB, Discord, Slack..

2\. Dynamic, visualization-focused UI with simple options that need to be
tweaked interactively? Try Imgui[0] or Godot[1]

3\. Scientific or data-centric stuff pulling in data from here and there, but
meant for interactive exploration? Try Wolfram / Mathematica or an IPython
notebook / GoogleColab

[0] [https://github.com/ocornut/imgui/wiki/Software-using-dear-
im...](https://github.com/ocornut/imgui/wiki/Software-using-dear-imgui)

[1] [https://medium.com/swlh/what-makes-godot-engine-great-for-
ad...](https://medium.com/swlh/what-makes-godot-engine-great-for-advance-gui-
applications-b1cfb941df3b)

~~~
anang
You’re right, I definitely could have been more specific. Something along the
lines of an office app.

Cool recommendations, thanks!

------
JamesSwift
The "best" way to do it is like you said, "core logic in a cross platform
language and native gui code". The general path is this:

1\. design things using an MVVM pattern and share all your business logic

2\. write all your native gui code manually as you tease out the patterns

3\. over time, you can start moving the UI generation into the shared code by
writing a custom DSL

The problem with platforms like React.Native and Elecron is that they are
based on having a JS runtime, which is a de-facto performance hit and forces
an async communication flow to the "native" side (flutter also has this
issue). Xamarin does not have that same restriction, and is my preferred
framework for this. Xamarin.Native (aka Xamarin.iOS/Xamarin.Android aka
Xamarin.Traditional aka Xamarin) has a very minimal performance overhead for
what it gives you in terms of native bindings and a shared codebase.
Xamarin.Forms is a higher level abstraction that sits on top of Xamarin.Native
and lets you theoretically write 100% shared code (by essentially being a
community developed UI DSL like I outline in step 3 above), but it is buggy
and has much worse performance.

The hardest problems you will have to solve using this approach are navigation
and lifecycle. For the most part these are well understood issues and you will
find lots of postings with different strategies on how to approach them.

~~~
jamil7
This was my approach most recently although I swapped out MVVM for a Redux /
Elm style shared architecture and wrote platform specific views.

------
pbsurf
For my cross-platform app, I was originally using Qt for desktop platforms and
Android. I was fairly happy with Qt on the desktop, but less so on Android, in
part because I was using Qt Widgets - Qt Quick is the newer, preferred way to
build GUIs in Qt, at least for mobile. Around 2016 I started looking into an
iOS port - at the time, Qt for iOS was fairly immature and there was (is?)
some uncertainty about licensing requirements for statically linking Qt on
iOS. Having already spent more time than I wanted fighting various problems
with Qt on Android, I decided to consider alternatives and ended up creating
my own SVG-based GUI library that I now use across desktop and mobile:

[https://github.com/styluslabs/ugui](https://github.com/styluslabs/ugui)

~~~
vertex-four
Can a screenreader user use an app written with this library? That’s a major
thing Qt and pretty much no other cross-platform UI system get right.

------
clartaq
Clojure is a very pleasant language to develop in. I have found it easier to
develop a JavaFX-UI program in Clojure than in Java.

If you want to go the route of running a server on the user's machine and
serving it through the user's browser, ClojureScript and Reagent/Re-Frame are
excellent choices. Re-Frame, [https://github.com/Day8/re-
frame](https://github.com/Day8/re-frame), in particular has very nice
documentation.

Clojure lets you use anything in the Java universe while ClojureScript gives
you access to all the JavaScript stuff, including Node.

There is a lot of tutorial information for both languages.

~~~
eyelidlessness
Clojure is a fantastic language, as far as dynamically typed languages go.
ClojureScript turned me off to both languages however. I routinely encountered
scenarios where accidentally passing values of the wrong type to core standard
lib functions produced wildly unexpected behavior that would take hours or
even days to debug. Reporting these issues almost always resulted in “don’t do
that WONTFIX”, and often very hostile responses if I pressed the issue or even
offered to contribute a fix. Ultimately I decided I’d be more productive in a
language that embraces correctness as a core feature. And ultimately that led
me to take the great FP techniques and philosophy I learnt in clojure and
apply them as idiomatically as I could in a statically types language. Now
most of my work is in TypeScript, and while I miss a lot of what Clojure has
to offer, I would never go back

~~~
byko3y
>I routinely encountered scenarios where accidentally passing values of the
wrong type to core standard lib functions produced wildly unexpected behavior
that would take hours or even days to debug

Could you provide a concrete example?

Intuitively I do understand ClojureScript is not as seamless as some people
say. First of all, Clojure is kind of a database-programming language with
fundamental data types built around concurrency, while JavaScript was single-
threaded until recently (and web workers used shared-nothing model). Second,
Clojure is build around Java specifically, not any other language. Java has
some strict type system with immutable complex objects being pretty much
native way of doing things, thus Java is great for implementing dynamic types
on top of it.

But I feel like not having undeniable proofs of fundamental flaw in
ClojureScript. For example, JavaScript fundamentally lacks copy-on-write
complex structures. Thus development of copy-on-write libraries is painful
e.g. ProseMirror which can become completely broken until page reload which is
bad for Single Page Application. However, could it be that ClojureScript...
just works?

~~~
eyelidlessness
> Could you provide a concrete example?

I wish I could, it's been years since I've actually written or even read any
ClojureScript. But I can offer something more general. Many core functions
expecting a collection type would blow up deep in the call stack, usually in
helper functions not exposed or documented in the core API, when passed a
value which provides no iteration. I would encounter these scenarios
frequently when recursing over a nested structure (e.g. oops I passed a
keyword or a function to `map`), or when I simply got argument order wrong.

Like I said, this eventually drove me to static typing, and I wouldn't ever
consider a language without it again. Most dynamic languages have too large a
core interface to commit it to memory, and even "small" languages reproduce
that in the libraries we build.

------
cpach
Have you considered Qt?

As a Mac user I prefer native applications if available. But still, I would
consider a well-written Qt application.

For example, qBittorrent is quite alright.

[https://en.m.wikipedia.org/wiki/Qt_(software)](https://en.m.wikipedia.org/wiki/Qt_\(software\))

[https://www.qbittorrent.org/](https://www.qbittorrent.org/)

~~~
making3
Are there any modern applications / examples built with Qt? This is the
screenshot from the Wikipedia article:

[https://upload.wikimedia.org/wikipedia/commons/e/e8/Qt_Creat...](https://upload.wikimedia.org/wikipedia/commons/e/e8/Qt_Creator_3.1.1_editing_a_sample_UI_file_from_Qt_5.3_using_Designer.png)

I always see Qt mentioned, so I'm definitely not trying to discredit it. I
just never seem to see common examples with it compared to something written
in Electron.

~~~
genezeta
Maya, Krita, Octave, OBS, Scribus, Virtualbox, Wireshark. These all have
fairly modern Qt GUIs and you can find screenshots around easily enough.

The comparison to Electron is _somewhat_ flawed though. I mean, the GUI in an
Electron application owes much more to whatever library they choose than to
the fact that it runs inside Electron. Electron provides no particular GUI
elements to the developer.

~~~
mkoubaa
Besides, QtWebEngine allows you to embed chromium into a QT app which means
you can effectively get a similar stack as electron but also have the option
to use desktop native widgets

------
zelly
Chromium is the best UI toolkit ever created. What exactly are the arguments
against Electron?

It's slow to render? Wrong, Electron (Chromium) renders faster than Qt. The
Skia engine is optimized to an extent that these other toolkits cannot compete
with. It even has a Vulkan backend now.

Single threaded? The render process is--you can use any native multithreaded
code you want in another process.

Memory? It's 70MB. That's nothing nowadays. Modern OSes can page it in and out
when the application is idling. A lot of these other toolkits are quite heavy
too, especially JavaFX in my experience. Also what happens when you need a
webview in one of these other toolkits? In Qt you get an embedded instance of
Chromium[1] so not only do you have the 70MB of Chromium, you also have the Qt
runtime (!).

The reason the Electron app you're using is slow or hogs giants amount of
memory is the Javascript code itself is slow. Yes, Slack is a slow monster,
but it's a giant codebase that does things that would be simply impossible in
Qt, GTK, Swing and others. There's a reason we never saw these types of apps
when the only frameworks were Qt and others.

[1] [https://doc.qt.io/qt-5/qtwebengine-
overview.html](https://doc.qt.io/qt-5/qtwebengine-overview.html)

~~~
roel_v
"but it's a giant codebase that does things that would be simply impossible in
Qt, GTK, Swing and others. "

Like what?

~~~
zelly
Dynamic, server-side rendered views

HTML snippets rendered for free (no need for an external HTML renderer)

Lots of little things like <video> being enough to embed a video into the view
versus subclassing a C++ Qt class or whatever song and dance it is in other
frameworks. It's productivity that's the killer feature. You can theoretically
do everything Electron does in Java Swing, but it would require reimplementing
most of the web platform.

~~~
roel_v
Not sure what the point is on the first two - you wouldn't even need that with
a non crap ui framework.

Video - I drag and dropped video players onto UI forms 20+ years ago. <video>
is a joke - you need something like video.js to make it functional in the real
world and at that point, good luck on 'simplicity'. Adult sites have entire
teams working on their video players, how messed up is that?

The problem today (old fart mode on) is that when all you have is a hammer,
everything looks like a nail. And it seems that people don't even just only
have a hammer, they don't even know what things that are not hammers look
like.

~~~
zelly
> Not sure what the point is on the first two - you wouldn't even need that
> with a non crap ui framework.

Server-side rendering is a business need not a programming need. A company
like Spotify may want to change the UI without updating the installation. To
do this on the web platform is a well-supported pattern. To do this with Qt
you'd have to implement your own HTML- or JSX-like framework on top of Qt
(like Hyperview does for mobile).

Companies that use Electron can just move faster and crush competition. That's
why there are billion dollar companies based on Electron programs and Qt
people get excited about it being the software behind the radio volume button
on the latest model fishing boat.

~~~
byko3y
>Server-side rendering is a business need not a programming need. A company
like Spotify may want to change the UI without updating the installation

The topic is about general desktop GUI applications. Some users of desktop
applications don't even have internet connection e.g for security
considerations. Tell me more about changing application UI without internet
connection.

------
libx
There's Tk ([https://tkdocs.com](https://tkdocs.com)) with bindings to several
languages. The simplest and the original one being TCL. What a great language
to program in!

Although I've not yet tried it myself, there's AndroWish
([https://www.androwish.org/home/home](https://www.androwish.org/home/home)).
Deploy your TCL/Tk code on Android with minimal changes.

~~~
endlessvoid94
I used the Tk ruby bindings several years ago and it was easy and looked
decent.

------
devwastaken
Flutter looks nice, but it's dart.

In a sane world we would already have webviews on all platforms and the
problem mostly solved for client applications. But there's a lot of forces at
work that want to artificially suppress web UI. Chromium doesn't have webview
on desktop platforms, but Microsoft's chromium edge does. Apple puts in their
special restrictions making up rules for any app that uses wkwebview.

Nobody with the power wants to make webUI universally deployable.

At the end of the day you choose one that you'll actually deploy something
with. There's no more right or wrong in UI, it's can you get to the goal of
deploying a functional app or not.

~~~
axegon_
In all fairness I think Dart is Flutter's strength, not it's weakness. It is a
very well thought out language, unlike javascript(in the spirit of discussing
electron).

There is undeniably a problem with flutter however: while it can be used for
desktop applications, it's mobile-first, desktop-sec.. well... desktop-kinda-
sorta-works...

~~~
moksly
I don’t mind dart, but typescript and electron have the full weight of
Microsoft behind them while dart and flutter remain mostly hobby projects.

We did the business case for cross platform, as we’re a non-tech enterprise
organisation with 10.000 employees but few developers. We wanted flutter to
win, but react native came out like the sound choice.

~~~
axegon_
You'd be surprised how many top-downloaded apps are made with flutter.
Electron and typescrypt may have some potential but they have a horrible
genetic desease - javascript. That alone makes flutter a clear winner.

~~~
moksly
Can you Name some?

~~~
stephenhuey
I don't know download rankings, but some I expect get significant traffic
include Hamilton, eBay Motors, Google Ads, Grab, Nubank, Dream11, and Alibaba.

[https://flutter.dev/showcase](https://flutter.dev/showcase)

------
fmxexpress
Delphi's FireMonkey framework offers cross platform on Android, iOS, Windows,
macOS, and Linux with a single codebase and single UI. It works similar to how
Flutter works in that it uses DirectX, OpenGL, OpenGL ES, and Metal API to
draw the native like controls. Plus offers access to some native controls
(mixed together) On Linux it uses GTK+.

There are thousands of hours of video tutorials on how to build cross platform
apps with FireMonkey on YouTube. But really it is just all built into the IDE.
Select the platform. Compile. A Linux machine and a macOS machine are required
to compile for those platforms. Because it is an integrated IDE everyone is
together so there is less tooling to fight to compile for all platforms.

Plus Delphi has staying power and plenty of history (25 years) behind it just
like Python and PHP (verses newer languages and frameworks which may not be
around later).

There are other libraries available for Delphi that let you build apps like
Electron (webview based apps) or entirely using native controls on iOS using
Storyboards if you prefer that way.

If I can self promote for a second here are 100 cross platform sample apps
built in Delphi: [https://github.com/FMXExpress/Cross-Platform-
Samples](https://github.com/FMXExpress/Cross-Platform-Samples)

~~~
capableweb
Sounds good but... Is this what's needed to use FireMonkey?
[https://www.embarcadero.com/products/rad-
studio](https://www.embarcadero.com/products/rad-studio)

Price seems to range from ~$2000 to ~$4500 to use it, which feels a bit steep.

~~~
fmxexpress
There is a free Community Edition.

[https://www.embarcadero.com/products/delphi/starter/free-
dow...](https://www.embarcadero.com/products/delphi/starter/free-download)

------
cjbprime
The way I see it: if you had infinite time and money then you would build a
native app for each platform you care about, and when you choose e.g. Electron
instead you're making a tradeoff because of your available resources.

When people criticize Electron, I don't think they're saying "given your
capacity, you should have picked a different and better point on the tradeoff
curve". I think they're just mad that you had the requirements you had and
didn't get to apply more resources than you had access to.

So, at first it sounds like they're making a technical argument against anyone
who would choose to use Electron, but I think what they're actually doing is
instead expressing some kind of economic disappointment in your situation.

(I would probably use Electron on a small budget, Qt on a medium budget, and
native apps on a large budget.)

~~~
dvfjsdhgfv
> So, at first it sounds like they're making a technical argument against
> anyone who would choose to use Electron, but I think what they're actually
> doing is instead expressing some kind of economic disappointment in your
> situation.

This is a fair assessment. Still, this disappoinment is worth expressing as it
makes it clear the current situation (lack of high-quality, mature, cross-
platform toolkit using native widgets) is frustrating. You shouldn't be
choosing between spending a lot of resources doing things right and spending a
reasonable amount producing an inneficient monster that drains your users'
system resources.

~~~
pizza234
> lack of high-quality, mature, cross-platform toolkit using native widgets

AFAIK, this is not correct, as WxWidgets fits the requirements (it's almost 30
years old, cross-platform and native).

I'm curious though, since I haven't extensively developded GUI applications,
which are the pratical tradeoffs against a non-native toolkit like Qt.

~~~
bmn__
> WxWidgets … native

I don't buy it, something doesn't add up. The look and feel is somewhat out of
place, one can tell with one glance it's not native.
[https://i.imgur.com/LjDhPOv.png](https://i.imgur.com/LjDhPOv.png)

• The scrollbars are too narrow and have only a down arrow at the bottom
instead of a combined up and down arrow.

• The font size is wrong in some places in the hex editor.

• The tab in the tab bar is crooked, not rectangular, and lacks a close
button.

• The text has too cramped kerning, most noticable in the word "File".

• The underline for key shortcuts is placed too high.

• The ribbing in the lower-right corner is larger.

• Contrast around the menu bar is too harsh.

• The icon bar does not lock (context menu), and always displays a grabber.

• Menu bar and icon bar do not have a context menu.

• The ribbing on the left-right split bar is different.

• The MDI panel only has a close button but not a detach button. There's a
obtrusive gradient in the panel title.

• The progress bar does not have the stripe pattern.

I submit that Wx implements its own non-native widgets.

~~~
VZ
> I submit that Wx implements its own non-native widgets.

It does for the widgets that have no native equivalent, such as
draggable/dockable tabs/panels that you show. You can't say they differ from
native ones because there is just no native version, on any platform.

OTOH all the standard UI elements (buttons, checkboxes, text controls, date
pickers, ...) are native and not only they look natively, but also behave
natively, which is pretty important and different from Qt.

~~~
bscphil
Not the person you responded to, but can you explain why if they're using
native widgets, every single example application here [1] looks _horribly_
integrated into the desktop? Is wx just really hard to use and every developer
screws it up? Does wx use the native widgets correctly but screw up things
like padding and highlights? Is the subset of widgets that are supported on
every platform too limited, so everyone is forced to use non-native widgets
(which apparently always look bad in wx)?

PoEdit comes the closest to looking genuinely native, but the MacOS
implementation is clearly flawed.

[1]
[https://www.wxwidgets.org/about/screenshots/](https://www.wxwidgets.org/about/screenshots/)

~~~
VZ
There are many screenshots here, I'm not sure which one do you mean. But do
keep in mind that some of these screenshots (maybe even most of them) are 10,
or 20, years old, so what seems non-native to you today might be just the way
things used to look.

~~~
bscphil
I really do mean basically every screenshot. But take ECMerge for example. If
you switch back and forth between Linux (GTK?) and Win7, you'll see that for
example the toolbar is exactly the same color on each. It doesn't integrate
with the Windows environment at all. But surely Windows has a native toolbar
widget? And possibly even a native icon theme that you could use instead of
the GTK icons. And even if not, surely wxWidgets could choose the color of the
toolbar based on the desktop theme, and not just fall back to the same default
colors?

Or check "Game Develop". The primary interface is a kind of weird rip-off of
the MS Office ribbon, but I assume this is a custom widget. There's also a tab
interface though, and this doesn't work on either the Windows or GTK versions:
it's weird and has a gradient background.

In general, small details like the padding, coloration, and borders drawn
around widgets seem to be slightly off on most platforms with just about very
wx based GUI I've seen.

~~~
VZ
ECMerge seems to use standard wxToolBar which is definitely a native control,
so I don't know why it has the same background on all the screenshots. Perhaps
they've explicitly changed it to make them more similar, I really can't say.
But if you create a toolbar out of the box, it will look exactly the same as
in any other native application. As for the icons, wx does provide a limited
set of stock icons, but this will almost never be enough, so you need to
either get high quality icons in the style of each platform you support, which
is obviously difficult for an open source/free program, or use the same,
typically Linux-style, icons everywhere just because this is what is there,
for free.

The rest of the controls (ribbon, tabs) are indeed non-native and there are no
native equivalents for them, so there is not much to say here.

Generally speaking, there shouldn't be any problem with the colours unless you
change them explicitly, which is a bad idea for the native controls. Not sure
what is wrong with the padding and borders.

------
madhadron
I've been trying to figure this out as well. The simple answer is that there
is no consensus and no obviously right solution.

My constraints were:

\- I'm not starting a desktop application project in C++ today.

\- I don't want to do the heavy lifting for complicated widgets myself.

\- I want to have the performance of compiled code without concurrency
limitations (so no Python or Ruby).

\- I want at least a reasonable facsimile of native look'n'feel on the three
major desktop platforms.

\- I want accessibility as at least an option.

If I don't want to buy dev tools like LispWorks or Delphi, then I'm left
looking at Java + Swing or a backend in Java or .NET and a web frontend.

Then I look at Dolphin Smalltalk or Corman Lisp which are now open source on
Windows, and they're phenomenal development environments that target Win32
directly instead of the layers added above it. macOS has excellent dev tools
for just macOS. On Linux, GNOME and KDE both provide excellent environments.
And I wonder if I should just forget about it and pick a platform.

~~~
klerpi
Which one would you pick if you had to?

------
raz32dust
You should give JavaFX a shot. It's not considered cool here, but does the job
well IMO. I have built desktop apps that work seamlessly between MacOS,
Windows and Linux using JavaFX with minimal pain. I was already quite familiar
with Java and the Java way of doing things though. That probably helps.

~~~
baglunch
I recently finished a project in JavaFX and am looking to build another
application. I've been unsure of whether to continue using Java or use native
widgets.

I'm very comfortable with Java, but one of the issues I've had is the size of
the resulting binary with the JRE included (it's possible to not include a JRE
of course, but it's much easier to have it bundled from a user perspective).
You can use jlink to reduce the size of the bundled JRE so that it only
includes relevant modules, but does it actually reduce the binary size by a
significant amount?

Also, JavaFX doesn't seem to have backing from larger organizations like
Electron does. Are there any well-known apps created with JavaFX. I know
IntelliJ was created with Java but using Swing if I recall correctly.

~~~
brabel
I ship a JavaFX app build with jlink. It includes many JDK modules beyond
JavaFX, like `javafx.swing` and `jdk.unsupported` in order to access some
features that unfortunately are not available in the standard modules, but
even then the download size (zipped) is around 35MB, more like 65MB unzipped.

I would say that's pretty acceptable for a real app.

------
fxj
wxWidgets

[https://github.com/wxWidgets/wxWidgets](https://github.com/wxWidgets/wxWidgets)

runs native on the following platforms:

\- wxGTK: The recommended port for Linux and other Unix variants, using GTK+
version 2.6 or higher.

\- wxMSW: The port for 32-bit and 64-bit Windows variants including Windows
XP, Vista, 7, 8 and 10.

\- wxOSX/Cocoa: For delivering 32-bit and 64-bit Cocoa-based applications on
macOS 10.7 and above.

\- wxQt: wxQt is a port of wxWidgets using Qt libraries. It requires Qt 5 or
later.

\- wxX11: A port for Linux and Unix variants targetting X11 displays using a
generic widget set.

\- wxMotif: A port for Linux and Unix variants using OpenMotif or Lesstif
widget sets.

Bindings are available for C++ and python

Window Layout Using Sizers

Device Contexts (along with pens, brushes and fonts)

Comprehensive Event Handling System

HTML Help Viewer

Sound and Video Playback

Unicode and Internationalization Support

Document/View Architecture

Printing Archiecture

Sockets

Multithreading

File and Directory Manipulation

Online and Context-Sensitive Help

HTML Rendering

Basic Containers

Image Loading, Saving, Drawing and Manipulation

Date-Time Library and Timers

Error Handling

Clipboard and Drag-and-Drop

~~~
leeman2016
I recently (5 months ago) went this way targeting Windows and Linux and was
very satisfied in the end. I might add:

\- Very small executable (I shipped around 10 MB executable)

\- No dependencies

\- Handling HiDPI screens (4k+) was OK

\- Very fast (Opening felt like restoring a minimized application)

------
dastx
I see a lot of people suggesting Qt, is there a reason GTK isn't being
suggested at all?

I'm in a position where I'd like to develop a better client for Bitwarden that
includes autofill to the point of 1Password, and while I did start with GTK
(learning for the first time), seeing no one recommend GTK here (compared to
multiple people recommending Qt) isn't filling me with confidence

~~~
miki123211
> I'm in a position where I'd like to develop a better client for Bitwarden

Beware that, if you use GTK, you exclude a certain segment of the population
who need Accessibility and aren't on Linux. This definitely includes screen
reader users, but probably also users of voice recognition, switch control
etc. QT works much better here. This is yet another tradeoff to make.

~~~
awalton
What kind of misinformation are you trying to spread here? GTK+ has
accessibility built into the toolkit itself - it's not optional, and it's
always on. In fact, GTK+ had it _before_ Qt did - ATK was written back in 2001
to be a part of GTK+, and the screen reader Orca is written to use GTK+ and
the platform agnostic AT-SPI layer. It would take a full _ten years_ for Qt to
add an implementation here.

~~~
cycloptic
The parent post is saying it doesn't plug into the native a11y, which is true.
Running the at-spi daemon on windows/mac would work for some things but it is
obviously not ideal.

------
zelphirkalt
Racket has a cross platform GUI library.

I've seen some tutorial some time ago, where someone used libwebkit from Rust,
but I could not find it again recently, so the point is: There could be
libraries allowing you to talk to a rendering engine and this could be a more
mInimalistic approach than Electron.

~~~
evdubs
To add to this, OP, there is an interesting blog with many examples of
graphics development in Racket:

[https://alex-hhh.github.io/](https://alex-hhh.github.io/)

I have written a couple GUI applications in Racket; maybe they can serve as
motivation to discover Racket's GUI capabilities:

[https://github.com/evdubs/chart-simulator](https://github.com/evdubs/chart-
simulator)

[https://github.com/evdubs/renegade-way](https://github.com/evdubs/renegade-
way)

There are limitations to Racket's GUI toolkit compared to writing a native
Qt/GTK/WPF/Cocoa application. You may find it easy to express simple/not-so-
complex interfaces and then find it much more difficult to do other things.
There's also the fact that Racket's real threads story isn't so great.

If I needed to write a cross-platform GUI application for the masses, I'd
probably pick JavaFX over Racket, but Racket has been very impressive if your
initial impression is to not expect much.

------
sys_64738
I only want to run native apps where possible. I certainly refuse to use
anything java based as I hate the whole eco-system due to how horrible and
generic java apps look. I say that as a former java developer. I dislike
Electron apps on the Mac as they’re just massive memory hogs. That’s probably
a Mac issue given the whole macOS is bloated. But on Linux I don’t mind what I
run, except java. Maybe it’s the red cloak that terrorizes that platform I
dislike most.

~~~
aasasd
It's at least _possible_ to do Java apps decently, as IntelliJ proves. Dunno
about the effort involved.

~~~
scarface74
IntelliJ still has the same “Java stench” that GUI Java programs have had from
the beginning. It just doesn’t feel right. I can’t put my finger on it.

------
pjmlp
Common logic in a language like C or C++, and bindings to the native widgets.

~~~
anang
I think this is a really attractive answer, but I’ve never programmed in c or
c++. I’m a little scared off by a lot of warning about how easy it is to write
unsafe code.

Are there any other cross platform languages with bindings to native GUI
frameworks?

~~~
pjmlp
FreePascal comes to mind.

And is also doable with Go, D, Rust, Java, .NET, just someone does need to
write the FFI code.

------
anang
Thanks for the responses! I’m sort of aware of specific products/projects for
cross platform desktop app development, and it’s fairly easy to just google
and get a lot of the same answers here.

What I’m more looking for are specific resources on how to do it. Like say I
choose qt, what then? How do I go from an idea to a cross platform app with a
reasonable build pipeline and a clear method for installation?

~~~
Gibbon1
I don't have direct experience but I know that Codelite and Code::Blocks IDE's
use qt and both run on Windows, Linux, and MacOS. You could look at how they
do it. Both projects eat their own dogfood, so you can with a little work
build and install them yourself. And I 99% certain codelite has a wizard that
can create a basic qt or wxwidgets project.

Also see Qt Creator.

~~~
VZ
Both Codelite and Code::Blocks are written using wxWidgets.

~~~
Gibbon1
You are correct.

------
m_sahaf
If you're comfortable with the web stack and still want to stay lightweight,
you can look into webview library[0]. I've used it with Go, and it also has
bindings for other languages. It loads the platform's native browser with
chroma-less window, just like an Electron app except perhaps lighter.

Another option is to look into Flutter. There are many available iterations
for desktop applications, one of them is the go-flutter[1].

[0] [https://github.com/webview](https://github.com/webview)

[1] [https://github.com/go-flutter-desktop/go-flutter](https://github.com/go-
flutter-desktop/go-flutter)

------
sxp
If you need a lightweight solution, Dear ImGui is a tiny cross platform GUI
library: [https://github.com/ocornut/imgui](https://github.com/ocornut/imgui)

~~~
formerly_proven
Dear ImGui is a great library, and immediate mode GUIs work really well for
"data-centric applications" that don't want to replicate their primary data
model in the terms of a UI framework.

But for a standalone app you'll need _much more_. You probably need file
dialogs, you might need working menus (ImGui can draw menus, but provides
nothing in the way of keyboard shortcuts), you might need translations, you
might need accessibility -- in terms of accessibility ImGui apps are literally
just a framebuffer. Nothing, nada.

------
INTPenis
This is 100% speculation; but I strongly believe in web based and I also
understand that some apps require hw access web based apps can't provide.

So imho I would compromise and make an app that bundles a web server. So you
separate out the hw logic from the GUI with an internal API and then bundle a
web server to host the apps web GUI, and have it talk directly to the HW using
the apps internal API.

That way you get the wide range of ecosystems available for building web based
apps, while also talking directly to hw with your internal API components.

------
gigel82
There's React Native for Windows and Mac now. Still pretty early on, but worth
a shot especially if you're also targeting mobile platforms (you can share a
lot of logic and some UI).

------
xgenecloud
In last few months, we built[1] a cross platform GUI app that generates
automatic APIs over any SQL database.

Here are our key learnings :

* Building desktop apps is made up of an ecosystem which has sub optimal tools and it is very likely that it will never get better. On one end there is Electron which makes it easy to build but then if its a trivial app and your users are not likely to 've faster machines - your users are likely to suffer. Chrome the culprit is pretty much a joke. And on the other end there is QT, GTK which are awful to say the least.

* More than building, it is the publishing these apps that is painful which gets rarely discussed here. It costs you both time and money. By time, on how bureaucratic the process is involved in procuring the SSL from a licensed vendor, its verification and so on. And money to get the code signing licenses which are separate for both MAC and windows. And good luck publishing them without code signing - apss will be treated like malware by OS. However popular apps still go ahead and do this (notepad++ etc)

I would say use electron if you do not have sufficient resources to build
natively for every OS. With some webpack optimizations you can squeeze in the
app size to less than 300 MB but many electron apps without these
optimizations go upto 650+ MB. Or else build it for MAC/Windows - release and
see your adoption and take the next step.

[1] :
[https://github.com/xgenecloud/xgenecloud](https://github.com/xgenecloud/xgenecloud)

------
lukevp
People dislike electron because they are using apps where it is not
implemented well. Javascript is single threaded and blocks rendering when it’s
executing, just like most major UI frameworks. You have to run everything
outside the main UI thread and marshal data back to the renderer. In JS the
furthest most go is using promises with async/await, which lets you not block
during a long-running request, but the continuation callback is still
executing within the same thread. If you implemented an app using a web worker
internally and kept the main thread just dispatching events and doing quick
render updates, it would perform amazingly well. CSS and JS are crazy
efficient, there is no reason that an electron app can’t refresh at 144hz. The
limitations are purely architectural. Most other UI frameworks put all
deferred callbacks into a separate execution context and force martialing (eg
in WPF, having to use dispatcher.BeginInvoke). JS doesn’t force this but is
possible.

The ram usage is going to be higher than a native app, and so is the exe size.
Those issues can’t be comparable. but the performance of the electron itself
is not so poor as people believe. And a well written electron app can easily
use under 200mb of ram, which is not an outrageous amount on modern systems.

~~~
valuearb
Web based user interface is always compromised over native UI, Electron is
just a little less compromised.

------
miguelrochefort
Take a look at Uno

[https://platform.uno/](https://platform.uno/)

It basically lets you compile WinUI (Windows 10, C#, XAML) apps to run
natively on all platforms (Windows, MacOS, Linux, Web, iOS, Android).

Disclaimer: I was part of that project for 3 years.

~~~
jitl
Feels slow in the browser on my iPhone X

------
cshenton
Left of field, but game engines have figured out translating a single set of
UI APIs to multiple graphics backends already.

Alternatively you could use a compatibility version of OpenGL, like 3.3 which
will run on any desktop OS, then use a windowing lib like glfw and UI
framework like Dear ImGui which is graphics API agnostic. I use this
particular combination all the time and it never lets me down. Sokol is
another options which is a very thin layer over many graphics APIs.

~~~
krapp
> Left of field, but game engines have figured out translating a single set of
> UI APIs to multiple graphics backends already.

I can't speak for Unity, but as far as Godot is concerned, the workflow for
certain things like layout and text styling leave a lot to be desired if
you're not making games.

Really, that just means waiting until more suitable plugins are available.

------
dsincl12
I searched but couldn't see that anyone had suggested Revery[1] by Outrun
Labs. Fast, native, cross-platform UI.

They are using it to build Onivim 2[2] so they are _very_ committed to making
improvements.

[1] [https://www.outrunlabs.com/revery/](https://www.outrunlabs.com/revery/)
[2] [https://onivim.github.io/](https://onivim.github.io/)

------
odshoifsdhfs
It really depends on the type of application.

A Drawing application, where the 'core' is the drawing/filter/etc code, should
probably be done in a shared library (C/C++/Rust?) and then have a native UI
as the UI won't be the complicated thing.

A Video editing app (where the UI for timelines, etc etc) where the UI is
quite important, should probably be a mix where generic stuff (menus, buttons)
use the native libs, but then have most of their controls rendered
independently of the native UI lib (timeline, custom controls, etc).

A audio mixer where the UI is mostly all custom, you can even do it in Unity
(or Gogot/OpenGL/whatever) as 95% of it will be custom.

A 'show data' ui filled with tables and lists and the likes, while I don't
like, probably something like Electron would work. Or QT/wxWidgets

A game pretty much doesn't matter and use a game engine that is supported in
all platforms.

I would recommend to use something like QT/wxWidgets/Xamarin Forms/etc as a
generic take all, and depending on the app, adapt it to your needs.

------
lenkite
Google's flutter [https://flutter.io/](https://flutter.io/) is the best at the
moment - even if I dislike dartlang, I have to admit the product is amazing.

~~~
geoffpado
Note: OP is looking for solutions for the desktop, and the Flutter site[0]
warns that desktop support is in an alpha state, with Windows still under
development.

[0]: [https://flutter.dev/desktop](https://flutter.dev/desktop)

------
pansa2
I’d agree with the other comments that Qt seems to be the most popular option
if you exclude web technologies.

However I’m currently planning a project that has a game in a main window and
separate debug windows. The main window will be OpenGL, but I don’t know
whether there’s an advantage to using Qt for the debug windows, compared to
using OpenGL throughout with Dear ImGui on top.

------
ryandrake
Here's an alternative to the various toolkits and HTML hacks people are
posting: How to do a cross platform GUI? _DON 'T_.

As a user I expect applications to stylistically conform well to the native UI
rules. I _want_ a Mac application to look and feel like a Mac application, and
an Android app to look and feel like an Android app. When an application uses
one of these "cross-platform toolkits" I can tell instantly by using the
application for a few seconds. Odd things around scrolling, menus, mouse
hovering, how things re-draw when you resize the window, etc. They make your
toolkit-built app stick out like a sore thumb. Yuck! Some toolkits are better
than others, but I'm pretty sure I can always tell!

Sacrifice a little to do your users a favor: Build all the business logic
cross-platform, with an API layer callable by whatever the best native
language is, and do the UI portions of your application with the platform-
recommended native tools.

------
musicale
> core logic in a cross platform language and native gui code

This produces a superior (often vastly superior) result, and it's also very
hard and time-consuming.

As an example: for Apple platforms only, SwiftUI can enable you to write a
high-quality macOS/iOS/iPadOS app, but the devil is in the platform-specific
details and exceptions to the generic behavior. Even Apple doesn't do a great
job with some of its own cross-platform apps, and that should tell you that it
isn't easy and doesn't come for free.

Now consider the effort to get that level of performance, usability, and
platform integration in a "non-native" framework that also targets
Linux/Windows/Android/etc..

------
fito
wxWidgets, of course!

There’s also these tiny but high-quality frameworks for C++:
[https://github.com/andlabs/libui](https://github.com/andlabs/libui)
[https://github.com/cycfi/elements](https://github.com/cycfi/elements)

------
cushychicken
For light, simple GUIs, I've been using python's PySimpleGUI package. Actively
developed and supported, and easy to work with.

Needs a target machine to build the output executables, but other than that,
it's great!

------
munawwar
I've used python, pywebview and html/css on a (super) simple application
recently. pywebview will use system installed web browser, rather than ship
entire chromium. So maybe check that out.

~~~
unnouinceput
System installed web browser sounds like a common mistake. Easy to deploy and
develop for it, hard to maintain. In the end you'll end-up with frustrated
customers when it comes to security nightmare. Better ship that Chromium, it
will save you a lot of negative karma.

------
rattray
There's a lot of discussion here about ways to use web technologies for
performant desktop applications.

A PWA that opens as its own Chrome "window", but shares resources, and runs
any non-ui code in a web worker or localhost server, might make sense. But I
don't know how to have a nice "install" experience that doesn't make it feel
like a second-class-citizen Chrome app.

Is there a way for a desktop installer to install a chrome app, such that to a
typical user it just feels like Any Other Desktop App?

------
obarthelemy
Not a dev, just a user. I've got a 16GB, 7yo Core i5 desktop that was working
fine for me. Then it started freezing up. Right after I installed the desktop
Discord client. Yep, that thing can freeze it all for up to 2 mins. Also make
it unusably jerky until it gets focus back. And lag so much when I type that I
can't use cursor keys, only the mouse really. So I dug into what it's made of:
Electron. Sp on behalf of all users: dev with whatever you want, just please
not Electron.

~~~
azangru
Have you used VSCode or Atom at all?

~~~
Scapeghost
[https://news.ycombinator.com/item?id=13940014](https://news.ycombinator.com/item?id=13940014)

"VS Code uses 13% CPU when idle due to blinking cursor rendering"

~~~
mceachen
ICYMI: This bug from 2017 was triaged, fixed _and in the insider build_ in
less than 2 weeks (!!)

[https://github.com/Microsoft/vscode/issues/22900](https://github.com/Microsoft/vscode/issues/22900)

------
Jaruzel
I recently dipped my toe in cross platform desktop dev with C# via Visual
Studio on Windows and then the Mono runtime on Linux.

Mono renders the app UI really well, but it's not pixel accurate - in fact, I
found all the widgets to be stretched horizontally by an extra 10%. To confirm
it, I put a circular image on the form, compiled it, and ran it in Mono
(Rasbian distro) and the circular image was rendered by Mono as a squished
oval. Otherwise it's a fairly good solution.

------
clartaq
There have been lots of good suggestions here, but I haven't seen any
discussion of using an IDE platform.

For example, [NetBeans
platform]([https://netbeans.org/features/platform/](https://netbeans.org/features/platform/))
provides a very high quality platform to build Swing-based applications on top
of.
[Eclipse]([https://projects.eclipse.org/projects/eclipse.platform](https://projects.eclipse.org/projects/eclipse.platform))
offers something similar. Both of those use Java.

If you would prefer something more "lispy", you can do just about anything on
top of
[Emacs]([https://www.gnu.org/software/emacs/](https://www.gnu.org/software/emacs/))
(with the possible exception of making it pretty.)

Depending on your application and familiarity with the IDE, using the base
under one of these (or other) IDEs could save you tons of time.

------
chuckmcknight
For native apps, I've had success using:

wxWidgets (C++) / wxPython (Python) Qt (C++) / PyQT (Python)

Mike Driscoll has a recent ebook on wxPython that is a good jumpstart if you
are familiar with Python. There are a host of other resources for Qt/PyQt
available via Google.

You can, of course, use any of the NodeJS frameworks as well. In the absence
of any clear requirements, any of these will work.

------
danap
For a native application for the desktop Java fits the need for cross
platform. Yea its GUI is rather plain, but it has all the components required.

I have a Java application that was built in 1999, still works on Mac, Linux,
and Windows. I have built some JavaFX apps, but they have had problems
rendering on some machines, so I have abandon that avenue. Besides it appears
to be designed for the web, and was just a pain for layouts.

For years I have been working a Java framework that allows for quick building
of basic applications. The framework comes with database access, SQLite
included, and a deployments and what is now called package management.

lindyFrame
[http://dandymadeproductions.com/projects/lindyFrame/lindyFra...](http://dandymadeproductions.com/projects/lindyFrame/lindyFrame.html)
[https://github.com/danap/lindyframe](https://github.com/danap/lindyframe)

------
edfletcher_t137
There are a few comments advocating Godot as a solution here and while it is
indeed promising, its domain-specific nature hampers it for general
application development in certain key ways, namely terrible host-filesystem
support. Investigate it deeply before committing to avoid painting yourself
into a corner later on.

------
Arathorn
We’re experimenting with using a rust core library (matrix-rust-sdk) for next
gen Matrix clients for code reuse/maintainability/performance/safety, but then
doing platform native UI on top for optimal UX (via swiftui, web, android,
gtk, etc). It remains to be seem how well this will work :)

~~~
miki123211
Hey, are you absolutely set on GTK for non-linux systems?

It has accessibility problems, excludinga certain group of users, including
blind people. I'd urge you to reconsider.

~~~
cycloptic
Please file bugs in GTK for the accessibility issues you're having, there is
interest in getting those fixed.

------
beamatronic
I’ve been looking for the best solution to this since the 1990s. The best
solutions I’ve seen are commercial solutions ($$$) or Java (i.e. Eclipse)

In the 1990s there used to be something called Visix Galaxy. The GUI builder
was the best I’ve ever seen. It was amazing but cost $$$.

------
rattray
I haven't seen React Native for Windows and MacOS mentioned much -
[https://microsoft.github.io/react-native-
windows/](https://microsoft.github.io/react-native-windows/)

Have folks used it? Is it any good?

------
goffi
If you're doing Python, you may have a look at Kivy, it's not native UI, but
it's quite nice, and can be run on all major platforms. On Android it's not
perfect though, as you have to deal with bigger starting time (Python
interpreter needs to be launched), and there is an impact on performances. On
desktop it's working really well (again, if you're OK with non native UI).

The Kivy ecosystem offers many neat things like PyJNIus to access Java class
(and thus Android API) from Python, or Plyer for high level cross platform
access to features like notification, vibration or GPS.

An other uncommon choice which can be interesting (and has been discussed
recently here), is using Godot for UI.

------
tonyedgecombe
Cross platform is always going to be a compromise. You will never achieve a
fully native feel for each platform and in trying to do so will soak up a huge
amount of time.

So I'd start by asking yourself whether you really need your application to be
cross platform.

~~~
JamesSwift
The question is not whether you want your application to be cross platform.
After ~10 years of app development I can say that in almost every case I do
want to share codebases.

The real question is "where do you draw the line for cross platform code?". In
other words, do you want everything to be potentially shared or do you only
want the "business logic" to be shared? Unless theres a real constraint on
time, I've found the best option to be starting with shared core + native
views and migrating the view logic into the shared core over time as you
discover the UI patterns.

You can have native feel by using a framework that binds to the native
directly. In my opinion Xamarin is the best option currently, but Kotlin
Multiplatform is a possibility once they mature.

------
9214
For moderately small apps, Red language offers a cross-platform (Win32, Cocoa
and GTK) graphical engine with an embedded DSL for declarative GUI
specification. As a baseline comparison, 7GUIs task implemented with it clock
under 300 LOC.

[https://www.red-lang.org/2016/03/060-red-gui-system.html](https://www.red-
lang.org/2016/03/060-red-gui-system.html)

[https://eugenkiss.github.io/7guis/](https://eugenkiss.github.io/7guis/)

[https://github.com/9214/7guis-red](https://github.com/9214/7guis-red)

------
raitucarp
Maybe you interested combine QT with react?

\- [https://docs.nodegui.org/](https://docs.nodegui.org/)

\- [https://react.nodegui.org/](https://react.nodegui.org/)

~~~
austinjp
Indeed. I'm currently experimenting with NodeGUI and React Native as a means
to write React components shared by web, Android, iOS, Windows, Mac, Linux.
Early days, but it broadly seems to work. I can even swap in Preact for web,
RN for mobile, and NodeGUI for desktop builds with enough webpack config
fiddling.

------
aww_dang
It has been awhile, but I had good results with embedding the Avian JVM,
removing all unused classes via proguard and using Eclipse SWT for native GUI
widgets. In the end I was left with nice small self contained binaries.

------
Const-me
If I were to start a new project today, I’d look at this library:
[https://platform.uno/](https://platform.uno/)

Can’t say I like all technical decision they made. I would prefer them to use
a purposely-built GPU-centric renderer instead of Skia, it’s not terribly
complex, here’s a proof of concept: [https://github.com/const-
me/Vrmac/#2d-graphics](https://github.com/const-me/Vrmac/#2d-graphics) Still,
Skia is not _that_ bad, maybe it’s fine there.

~~~
bscphil
An irritating thing about Uno is that I heard about it for the first time in
this thread, and I'm finding it basically impossible to figure out how well it
meets the requirement of this thread: cross-platform GUI.

Their main page says that it's cross-platform, but doesn't have any
screenshots of a simple application running on every platform. If you go to
[1] you'll see that most of the programs they feature are Android + iOS only,
not even desktop platforms. Of the few that do, most seem to be Windows only,
and a few run on the Mac, but look _horrific_ on that platform. [2] Not a
single one of their showcase programs runs on Linux. What's up with this,
shouldn't the whole point of a showcase for a cross-platform UI framework be
to show off applications that run on every supported platform?

If you start digging into the docs [3], you immediately find pages that
mention only iOS, Android, UWP, and WebAssembly as supported platforms. The
"developers" dropdown on the main page has Android, iOS, Web, macOS and
Windows 7?? Even their code samples [4], hilariously, only run on a few
platforms and don't seem to link to any actual code?

[1] [https://platform.uno/showcases/](https://platform.uno/showcases/)

[2] [https://apps.apple.com/us/app/uno-
calculator/id1464736591](https://apps.apple.com/us/app/uno-
calculator/id1464736591)

[3] [https://platform.uno/docs/articles/getting-
started/requireme...](https://platform.uno/docs/articles/getting-
started/requirements.html)

[4] [https://platform.uno/code-samples/](https://platform.uno/code-samples/)

~~~
JamesSwift
I do a lot of app dev and recently looked into Uno to see what it was because
I was also confused.

Uno is sort of an alternative to Xamarin.Forms aimed at windows developers
that aren't happy that Xamarin.Forms uses a non-standard XAML. Uno uses UWP
XAML, which is preferred by these users.

The way I like to think of the two frameworks is that Uno is a cross-platform
framework that aims to align systems to the Windows way of doing things, while
Xamarin.Forms is more of a "do iOS/Android" in same codebase and just happens
to also support windows. There is unique value props in each framework (e.g.
Uno also targets WASM and Xamarin.Forms targets Samsung Tizen).

Here is a good high level of Uno:
[https://www.youtube.com/watch?v=fyo2BI4rn0g](https://www.youtube.com/watch?v=fyo2BI4rn0g)

------
AtlasBarfed
It's been a while since I did any UI dev, and this thread has been very
informative, thanks to everyone giving advice.

But man, the balkanization of OS GUIs and widgets should have been subjected
to the same very public shame that IE6 was subjected to, and a standards body.

No wonder electron is so appealing.

There is no technical excuse for modern OS's to have converged on a very well
designed crossplatform UI toolkit. It really does underlie so much of why
people are fleeing desktop OSs for phones and tablets.

Does Microsoft Office still bake their entire own Windows UI/Widget stack?

------
grblovrflowerrr
Revery is a compelling option, being used to build a commercial text editor:

[https://github.com/revery-ui/revery](https://github.com/revery-ui/revery)

------
adamnemecek
I'm in the same sitch. Right now I'm working on building my own UI toolkit,
it's annoying that I have to do it, but I like the control. I'm using Rust
with
[https://github.com/cytecbg/gpucanvas](https://github.com/cytecbg/gpucanvas)
for rendering and I'm porting parts and pieces of nanogui
[https://github.com/wjakob/nanogui](https://github.com/wjakob/nanogui).

------
jarek-foksa
I'm developing a cross-platform widget toolkit for Electron and Chromium-based
browser called Xel [1]. The next major version of the toolkit (to be released
later this year) is going to support dark mode and several new themes [2].

[1] [https://xel-toolkit.org/](https://xel-toolkit.org/)

[2] [https://boxy-svg.com/ideas/90/preferences-theme-setting](https://boxy-
svg.com/ideas/90/preferences-theme-setting)

~~~
1_player
I really hate the fact that I can't even view your landing page on anything
that's not running a Chromium engine.

Even though the widget toolkit is designed to run on Electron, people still
use Firefox to browse the internet.

------
rscho
Smalltalk is stellar for precisely that.

If you want all the bells and whistles, go for Pharo. If you are planning for
something functional but simple, cuis smalltalk is the way to go.

------
TurboHaskal
Racket and LispWorks ($).

If you want a RAD IDE I recommend you to take a look at Lazarus and Xojo ($).

You can try them all and think for yourself. Xojo and LispWorks in particular
come with plenty of example apps.

------
ddek
Avalonia is a cross platform port of XAML, that is ready for app development.
I’m waiting for it to move to .Net 5 though.

There’s also FuncUI, an elm-like layer over Avalonia written in F#.

~~~
Nginx487
We develop on Avalonia, it provides very limited control set and
functionality, and 3rd party libraries/controls do not exist yet. Cross-
platform framework requires some time to become mature and create ecosystem
around.

~~~
pknopf
Checkout [https://GitHub.com/qmlnet/qmlnet](https://GitHub.com/qmlnet/qmlnet)

It leverages the entire Qt system with the power of .NET. We use it on
embedded medical devices.

~~~
Nginx487
And how's it on production? I remember, we considered it, and rejected because
the framework visibly far from release. Maybe, we were wrong.

------
shimonamit
I was examining Zoom's bin directory looking for a cross-platform GUI library
they might be using, and found a library called DirectUI, also duilib.
DirectUI was originally developed by Bjarke Viksoe. Looks like this here:
[https://www.codeproject.com/Articles/372559/DirectUI](https://www.codeproject.com/Articles/372559/DirectUI).
Maybe someone else can add some insight?

~~~
aninteger
Maybe it uses this on Windows but on Linux it's definitely using Qt widgets/Qt
Quick.

------
gravypod
I've been looking to build a UI recently too. I want to rewrite BloomRPC to be
reflection-only and native.

Something I've been struggling with is choosing a UI platform with a drag-and-
drop editor for most UI frameworks. This available in Lazarus and Visual
Studios but that's about it. Nothing works well in the Java/C/Python space
with a visual editor.

Why is that? Do people not find visual editors useful?

~~~
innocenat
IntelliJ has GUI builder. I believe Eclipse has it too, but I last use Eclipse
more than 8 years ago.

~~~
brabel
IntelliJ only embeds JavaFX's Scene Builder[1] which can also be used stand-
alone.

[1]
[https://www.oracle.com/java/technologies/javase/javafxsceneb...](https://www.oracle.com/java/technologies/javase/javafxscenebuilder-
info.html)

~~~
innocenat
I never knew that, but I have used their Swing GUI tool before:

[https://www.jetbrains.com/help/idea/gui-designer-
basics.html](https://www.jetbrains.com/help/idea/gui-designer-basics.html)

------
BuckRogers
Crossplatform will never be "right", always a compromise. I'd consider if you
truly need to be crossplatform or not.

If I need it, I'd go with a webapp, preferably Blazor for wasm. For native,
I'd want to use one of my preferred platforms. Windows10 for desktop, iOS for
mobile.

I'd work my way down, starting with what I'd prefer to work with most.

1\. Blazor WebAssembly (webapp)

2\. Blazor Server (webapp)

4\. WinUI/UWP (native)

3\. ASP.NET MVC (webapp)

5\. iOS (native)

~~~
BuckRogers
My post is referring to today. It's worth adding that for the future, .NET
MAUI[0] may be what people are looking for. It's an evolution and expansion of
Xamarin.Forms. I'd have a hard time believing you will be able to do better
for a native, crossplatform GUI than .NET MAUI when it's ready.

[0][https://devblogs.microsoft.com/dotnet/introducing-net-
multi-...](https://devblogs.microsoft.com/dotnet/introducing-net-multi-
platform-app-ui/)

------
rattray
Proton Native claims to be working on a wxWidgets-based native component
backend for its React-syntax desktop engine: [https://proton-
native.js.org/#/?id=native-components](https://proton-
native.js.org/#/?id=native-components)

Sounds exciting, no idea how far along it is. Hadn't heard of it until today.

------
pengo
Yes, you can create great interfaces using embedded browser panes; check out
the Forex Smart Tools suite for some I've helped author. But don't discount a
solution like Lazarus: sure, Object Pascal is old school now, but it's easy to
create fully native applications that can be cross-compiled for Linux, MacOS
and Windows.

------
jesperlang
I just recently discovered [https://github.com/tauri-
apps/tauri](https://github.com/tauri-apps/tauri)

It looks like a good alternative to Electron but haven't tried. Anyone?

------
philix001
You might want to follow the Rust developments in this area:
[https://areweguiyet.com/](https://areweguiyet.com/)

------
sidcool
I have heard some good things about JavaFX. Worth a spike.

------
IshKebab
You should definitely start with Qt and choose something different if you have
a good reason to (e.g. really don't want to use C++ or Python).

------
antihero
Has anyone used Proton-Native or the Microsoft React Native? Are they any
good? That would be my first thing to look at.

~~~
scarlac
Yes, I have. "Microsoft React Native" aka React Native for Windows is not that
great for the public yet. There are basic layout bugs that need to be
addressed before it's good enough that I'd recommend it. But if you are
feeling experimental, you would eventually get good iOS, Android, Windows, and
macOS support all in 1 app.

------
knotz
Purebasic. Cross platform (Windows, Mac, Linux), native widgets. Not fancy but
gets the job done and is reliable.

------
agarzenm
I like to keep things simple so Tkinter.

------
Foober223
> building quality

For top tier heirloom quality, use the native GUI widgets of the platforms you
are targeting. The rest written in portable C.

If the app is literally just GUI widgets, then then the cross platform nature
falls apart. But for something like a 3D video game where a window widget is
just a little bootstrap to your game, it's nice.

------
zubairq
You could also try appshare.co. Free , open source and cross platform

------
darkhorn
You can use ExtJS. Works in all modern browsers, both on desktop and smart
phones.

------
TeeWEE
For the platforms web, iOS and Android flutter is a clear winner.

------
rock_artist
One factor not asked is pricing... This might apply to some frameworks.

There are 3 general approaches:

* Web technologies (Electron or any WebView) * Wrappers (eg. react-native, Xamarin) * Using a cross platform framework with some UI code (or additional UI renderer). (eg. cpp: QT, JUCE; java: swing or the newer ui toolkits).

In terms of performance, The major question is the impact of the UI.

Are you in need for video? do you need super-awesome FPS with custom GPU
shaders?

If you need super-fine control on the entire UI, meaning, the app IS the UI :)
(or at least it's a major part of it) - then writing close to metal (OpenGL
--> Vulkan/Metal) might be the best starting point.

If your app can also run in a web-browser without compromises then starting a
web-based development would be best.

TL;DR - I feel that there's need to scope the UI needs to decide which is
best.

------
tawayfree
Flutter will die, Kotlin native with compose is the future.

------
acvny
Java swing or javafx

------
betimsl
Maybe this:
[https://git.sr.ht/~eliasnaur/gio](https://git.sr.ht/~eliasnaur/gio)

------
axilmar
Qt is by far the best choice for me.

------
tuananh
for cross-platform apps, from my own experience, I find Qt often deliver the
highest quality.

------
arkanciscan
Web.

------
lap43
Sciter

------
tus88
PyQT

------
tuckerpo
wxWidgets is a lot less scuffed now than it used to be.

------
dekhn
qt

------
coleifer
I love using tcl/tk and Python's tkinter module.

The complaint that it looks old-fashioned is addressed partly by using ttk
(themed tk) but also just about every aspect of the widgets can be styled
using a simple xresources-style config.

It's fast and lightweight, free forever, stable as hell, and there's lots of
resources online.

------
probinso
Build a web site

~~~
anang
I’m assuming you mean a web application, however I am looking specifically for
resources regarding desktop app development, I’m a pretty confident web dev,
so that as an option is pretty clear to me.

~~~
Gibbon1
qt and wxwidgets are cross platform.

------
forgotmypw17
You're using it right now...

If you're careful, you could build something which works on every desktop
starting with mid-1990s.

For newer platforms, if you want it to be a "true desktop app", you could
bundle the HTTP server. Whatever your platform, there are many options.

~~~
anang
Interestingly enough I’m actually posting from an iOS app :)

I am talking about a true desktop app, not a web app.

Are desktop apps dead?

~~~
unnouinceput
No they aren't. And they'll never be, unless a new operating system will be
used by everybody. In current situation desktop apps will solve problems that
are impossible to solve by web apps (access to hardware being the main one,
performance is the next)

