So many sub-debates hidden in this "cross-platform native GUI":
1) I want to write a GUI code once
2) I want to ship something that works on Windows / Linux / MacOS
2.1) I want to ship something that looks the same on Windows / Linux / MacOS
3) I want to ship a binary that works on Windows, a binary that works on Linux, a binary that works
3.1) I want to ship a small and efficient binary
4) I want to ship something that looks like a Windows app on Windows, a Linux app on Linux, a MacOS app on MacOS, etc...
(By definition, "I want to ship something that looks the same everywhere and looks like an app of my host" is meaningless, right ?)
The "holy grail" seems to be:
5) "I want to write a GUI code once that generates small efficient binaries that looks exactly like an app of the host OS, and if possible looks the same everywhere, and let me go back to writing my business logic rather than agonize over drawing a button."
It's seems from the debate that nothing obvious fulfills 4 and 5.
Then it comes to which requirement you're ready to drop.
If you're ready to drop requirement 2) , I suspect you're doing MacOS specific, go for it ;)
If you're ready to drop requirement 1) , I suspect your managers / salespersons disagree.
I suspect your manager / salespersons do not care about requirement 3.1), but it's debatable. Use Qt/Electron, and ship something.
I suspect your manager / salespersons do not care about requirement 4), and I suspect they're esthetics, which can not be defended.
I gave up waiting for someone to make 5, and don't have the resources / skill / time to do it myself.
And maybe we should stop caring and watch the sky instead.
I hope someone is able to get to 1 + 2.1 + 3.1 someday.
> 2.1) I want to ship something that looks the same on Windows / Linux / MacOS
> 3.1) I want to ship a small and efficient binary
well, with Qt I write my code once, which looks the same on windows / linux / osx / $nicheos and the result is fairly performant - I've got tables with tens of thousands of elements which update at rates greater than 100hz and the UI does not bat an eye. I'm not even using the GPU-based scene graph (QtQuick) but instead uses the CPU-based raster engine. Here's the software I'm developing : https://github.com/OSSIA/score/
So what is missing ? For what it is, the binary is relatively small (and I also link against LLVM and a few other large libraries, and am not even doing global static linking + LTO...).
Great list and summary! So often these concerns get conflated.
We're working on a framework that address 1, 2, 2.1, 3, and 3.1 - Revery [0] - a React-like framework that compiles to native code, built with ReasonML [1]. I believe that the React pure-functional model of UI-as-a-function-of-state is such a powerful paradigm, and not leveraged on native today - ReasonML is a perfect fit for that.
Bullet point 4 is a non-goal for Revery, but our sister project, Brisk [2] is built on platform widgets.
I'd personally also add a couple of dev experience bullet points or ideas to the "holy grail":
6) Fast / instant compilation time
7) Hot-reload (see changes to the app instantly)
We're not there yet, but we hope we could also get to the point of including 6/7 - essentially bringing some of the great aspects of React/Redux to desktop application development, with native code.
Same idea as Electron but it wraps the OS webview instead of Chromium (Cocoa/Webkit, gtk-webkit2, MSHTML, and soon EdgeHTML). The minimal test app is 255kb in size, the static lib is just 48kb (MacOS).
And I get, "but Safari/IE/whatever are still different platforms!" I'd argue that the edge cases between browser rendering of HTML + CSS + JS is much better to deal with than the architectural and language differences between the native GUI APIs on each platform. As long as you're not pulling in an obscene amount of JS dependencies, webview is very sane.
> 2.1) I want to ship something that looks the same on Windows / Linux / MacOS
Why?
I want my macOS apps to use Mac-native UI elements, and Windows apps to use Windows-native UI elements. (There is no one native Linux UI, so we can leave that one aside...)
Hmmm... node+electron solved MacOS/Linux/Windows, but the snag was I implemented everything in JavaScript, probably not doable for most folks, but for the past 4 years support has been very easy and I have encountered zero platform issues (except for icons on MacOS). I guess I'm the one anecdote that succeeded.
MacOS support is experimental, but mostly working. Linux currently needs an Electron wrapper. Theoretically you could port one of the react-native-desktop projects to use GTK or Qt.
Then of course you have native iOS and Android components with Facebook's ReactNative and web support via React.
ReactXP wraps all of these projects allowing you to write React components and TypeScript code that is shared among every platform. It's the same workflow as Electron, even less so, with native UI.
This is a particularly good summary, thanks for that. At the end of the day, the only way for 5 to happen, is for a development project to architect the requirements and complexities way before even starting to code.
Aren't 2.1 and 5 pretty impossible to have at the same time? How can you look like Windows on Windows, Linux on Linux, and Mac on Mac, all while looking the same everywhere?
To date, the best solution to this problem that I have seen is to write all your core code in a shared library using something like C++, and then hooking it up to a thin layer of completely native, platform-specific code for the UI. It’s fast, lightweight, looks good, and requires minimal extra code if you do it right.
It is still a lot of work if you need advanced things then the basic widgets. Thinks where usually you need to extend existing widgets like you want an advanced datagrid/table with sortable/dragable columns, with custom item renders for some columns (like a chart widget for the Trends column).
In this advanced cases you will need to create custom widgets for each platform, hope that all platform have the advanced datagrid widget(if not you will have to create it) etc.
For simple apps your solution works, and you could also make a CLI app too.
MVP (Model View Presenter) is one approach to decouple the UI from the interaction logic to achieve that goal. Only the view implementation has to be platform specific. The viewmodel is also shared among platforms.
I think this is the best option but for most it's still a lot of work. I spend far more time on the UI code of my applications than I do on the model or domain specific parts.
I have the same question. There are many things that are problematic about Qt (personally, I loathe anything that feels the need to interject itself in the middle of the build process) but to completely ignore Qt without explanation - and subsequently post detailed experiences with libraries I've never even heard of - led me to believe the author exists in some uninteresting-to-me parallel plane of existence.
The first google hit for “qt nim” is [1] from 2017, so I think it’s safe to say it did not exist yet. The first hit for "wxwidgets nim" is [2], which has one open issue (since 2016): "Trouble building wxnim on win7".
Yes, time travel would solve most software development problems.
He does not like Qt because a simple window with a few buttons and sliders will end a big (in term of MB) application.
He did not realize that one but another reason not to like Qt is that fact that they recreate the native look on each platform it's highly inefficient on macOS.
exactly, unless he really has something super special, QT should fix all his jokes. I don't use QT, but I think QT rarely has competition as far as cross-platform desktop GUI is concerned.
the only true "cross-platform" alternative is electron, which is a bit bloated and slow, but vscode is built on it, along with many others and worked fine. I personally prefer electron these days.
It says: "WPE is the reference WebKit port for embedded and low-consumption computer devices. It has been designed from the ground-up with performance, small footprint, accelerated content rendering, and simplicity of deployment in mind, bringing the excellence of the WebKit engine to countless platforms and target devices."
For the Java bit, I imagine that with modern Java versions with modules the app would be a lot smaller. The new Java versions are modular so you can include just what you use and I think it can even create a native package for installation. It should bring NodeNox 3 down from that 220MB package.
One warning: if you try to implement your own gui widgets in opengl, unless you're really careful you're not going to support accessibility tools such as screenreaders or Japanese/Chinese text input at all.
We already have browsers installed that are designed to render arbitrary cross-platform GUIs based on HTML/CSS.
Why can't I write a desktop application that just asks the OS for the users preferred browser and provides it with HTML/CSS and UI interaction callbacks / events? Render it in a native looking window.
We shouldn't need Electron at all! It's like we all have this fantastic rail transport network but insist on riding in our own trains.
>Why can't I write a desktop application that just asks the OS for the users preferred browser and provides it with HTML/CSS and UI interaction callbacks / events? Render it in a native looking window.
Granted it's not "user's preferred browser" but it fits the bill. They all have issues, largely solved by Electron packaging the browser engine with the binary, and even that isn't perfect.
The most common reason I’ve heard is that devs want to be able to use cutting edge features and the update cycle for OS bundled browsers is too slow to accommodate that.
I find this argument a bit silly, because there are few applications that actually need said cutting edge features and even if you’re one of the handful there’s always polyfills, but maybe I’m missing something.
With Microsoft embracing Chromium as the built-in Windows rendering engine, enabling multiple Electron apps to run on a single instance, we're moving in the direction of Electron being the standard train your app can live in on any railroad.
I think he got it wrong when he quickly ruled out IMGUI, as you can use it to create a small app with next to no dependencies. He complains that you need to redraw your GUI at 60 FPS, but this is wrong, you should be able to draw with it only when needed.
I am a big fan of Nuklear. I can write a tiny C app that compiles on macOS, Windows, iOS, and Android with it. The look and feel of Nuklear can be something you don't like, however.
If you need HTML5 canvas-style drawing: I propose building an (abstract) SVG document and render with Skia. When part of the SVG document changes, that part will be redrawn by Skia, just like an interactive SVG in your browser. Disclaimer: I haven't tested this idea.
Andy Brice of successfulsoftware.net has a long-time product, Perfect Table Plan (computes seating plan for weddings, given various inputs) that used Qt (and C++), I've read, on his blog. PTP has been there for years now. Seems to be doing well, based on what he says about it. Don't know how good the Windows vs. Mac versions are, but at least they are there. His newer product HyperPlan may also be on the same stack.
This is exactly why I say Electron is going to “win” in the cross platform GUI toolkit space. I do not think this is good thing. Cross platform GUI dev has been a train wreck as far back as I can remember. Contrast that with the immense amount of human years invested in making the browser a cross platform GUI runtime.
I’m sorry folks, 198MB menu bar apps is what we’re going to have unless a cross platform GUI effort equivalent to that of Chromium comes about.
To add a little data on my experience last time I tried this, using UPX [0], you can get GTK+ 3 down to 9 MB. Most of the size of Qt comes from ICU, which can be feature selected to decrease its size [1]. With that and UPX, Qt can get down to 16 MB. And those can both be compressed another 30% with ZIP files for shipping.
While those aren't great numbers, I personally think it's tolerable for most usages.
I like the idea of having one c-sourcecode compiling on Linux, macOS and Windows. Hence, I have developed a platform independet GUI called Geeonx https://www.geeonx.org .
Versions for Linux and MacOS X are ready for download. The version for Windows will follow soon - I will speed up development if someone claps in his hands.
It can use native components (wxWidgets, android, html5) but you can fairly easily extend it to use other "backends" (like Qt for example - i havent written that backend yet, but its something ill almost certainly do)... It can also handle drawing the components in a variety of methods (so called "composite backends").
Im currently aiming to get it out of alpha asap, and most work goes into "new-component-method" branches (these will become master shortly). Documentation is pretty slim at the moment, but something im actively working on, two examples that i just wrote up today in fact are:
These days, Xamarin looks interesting. Can target windows, Linux, Mac, Android and IOS. I have not used it yet but if I get a project that needs full Cross platform distribution, I would probably use xamarin with a F# code base where possible.
Given the other applications you chose to look at, I'm surprised you didn't also look at Audacity. It uses wxWidgets, which is a nice C++ cross-platform GUI framework. It wraps native controls on each platform it supports, and also has a "Generic" variant where it draws its own. It's not very heavy as these things go, and has a nice python binding called wxPython.
By personal experience, wxWindows is "OK", but it's not a panacea. There are a ton of little quirks that will burn you when doing cross-platform development simply because native controls do not behave in the same way. HiDpi is a major pain with wxWindows (but then again, the way HiDpi is managed is a pain irrespective of the toolkit).
But if you do some forms and basic UI controls, wxWindows does the job egregiously. Looks the way it should be on all platforms.
It's funny an article from 2016 mentions issues about text rendering, because certainly we've been regressing in this area.
I can spot QML and Electron apps by the broken text rendering alone. FF60+ with quantum has incorrect subpixel hinting and does not correctly hint at all sometimes.
Many of the mentioned apps int the article are "broken" in my eyes: I don't have perfect vision, and I do expect apps to follow the system text scaling (and they don't). For a "broken by design" example, see Darktable, which is awesome, and should do this by default, but the authors hard-coded a theme where literally every widget is styled for looks and not for function.
Nobody speaks about how the widgets should feel and interact, but that's exactly what feels off about "GTK" on windows or macos. QML, Electron and partly GTK3 brings that feeling to all platforms. My biggest letdown is QML, as many QT developers see it as the future so it has a larger adoption than it should have.
It breaks just about any rule in the book: poor behavior on any platform, noticeably slower, style not consistent with the platform, broken scrolling, broken text editing, broken text rendering...
Since many years I made a few application using wxWidgets, and the macOS part can have issues. While it's ok regarding the size of the app (in term of MB) you still drag and extensive library.
[+] [-] phtrivier|6 years ago|reply
1) I want to write a GUI code once
2) I want to ship something that works on Windows / Linux / MacOS
2.1) I want to ship something that looks the same on Windows / Linux / MacOS
3) I want to ship a binary that works on Windows, a binary that works on Linux, a binary that works
3.1) I want to ship a small and efficient binary
4) I want to ship something that looks like a Windows app on Windows, a Linux app on Linux, a MacOS app on MacOS, etc...
(By definition, "I want to ship something that looks the same everywhere and looks like an app of my host" is meaningless, right ?)
The "holy grail" seems to be:
5) "I want to write a GUI code once that generates small efficient binaries that looks exactly like an app of the host OS, and if possible looks the same everywhere, and let me go back to writing my business logic rather than agonize over drawing a button."
It's seems from the debate that nothing obvious fulfills 4 and 5.
Then it comes to which requirement you're ready to drop.
If you're ready to drop requirement 2) , I suspect you're doing MacOS specific, go for it ;)
If you're ready to drop requirement 1) , I suspect your managers / salespersons disagree.
I suspect your manager / salespersons do not care about requirement 3.1), but it's debatable. Use Qt/Electron, and ship something.
I suspect your manager / salespersons do not care about requirement 4), and I suspect they're esthetics, which can not be defended.
I gave up waiting for someone to make 5, and don't have the resources / skill / time to do it myself. And maybe we should stop caring and watch the sky instead.
I hope someone is able to get to 1 + 2.1 + 3.1 someday.
I'll use that.
[+] [-] jcelerier|6 years ago|reply
> 2.1) I want to ship something that looks the same on Windows / Linux / MacOS
> 3.1) I want to ship a small and efficient binary
well, with Qt I write my code once, which looks the same on windows / linux / osx / $nicheos and the result is fairly performant - I've got tables with tens of thousands of elements which update at rates greater than 100hz and the UI does not bat an eye. I'm not even using the GPU-based scene graph (QtQuick) but instead uses the CPU-based raster engine. Here's the software I'm developing : https://github.com/OSSIA/score/
So what is missing ? For what it is, the binary is relatively small (and I also link against LLVM and a few other large libraries, and am not even doing global static linking + LTO...).
[+] [-] bryanphe|6 years ago|reply
We're working on a framework that address 1, 2, 2.1, 3, and 3.1 - Revery [0] - a React-like framework that compiles to native code, built with ReasonML [1]. I believe that the React pure-functional model of UI-as-a-function-of-state is such a powerful paradigm, and not leveraged on native today - ReasonML is a perfect fit for that.
Bullet point 4 is a non-goal for Revery, but our sister project, Brisk [2] is built on platform widgets.
I'd personally also add a couple of dev experience bullet points or ideas to the "holy grail":
6) Fast / instant compilation time
7) Hot-reload (see changes to the app instantly)
We're not there yet, but we hope we could also get to the point of including 6/7 - essentially bringing some of the great aspects of React/Redux to desktop application development, with native code.
- [0] Revery: https://github.com/revery-ui/revery
- [1] ReasonML: https://reasonml.github.io/
- [2] Brisk: https://github.com/briskml/brisk
[+] [-] amedvednikov|6 years ago|reply
https://vlang.io/#ui
An example of a small GUI app:
https://github.com/vlang/v/tree/master/examples/users_gui
The app is about 100 KB on all platforms with zero dependencies and uses native toolkits (WinAPI, Cocoa).
[+] [-] holy_city|6 years ago|reply
Same idea as Electron but it wraps the OS webview instead of Chromium (Cocoa/Webkit, gtk-webkit2, MSHTML, and soon EdgeHTML). The minimal test app is 255kb in size, the static lib is just 48kb (MacOS).
https://github.com/zserge/webview
And I get, "but Safari/IE/whatever are still different platforms!" I'd argue that the edge cases between browser rendering of HTML + CSS + JS is much better to deal with than the architectural and language differences between the native GUI APIs on each platform. As long as you're not pulling in an obscene amount of JS dependencies, webview is very sane.
[+] [-] Wowfunhappy|6 years ago|reply
Why?
I want my macOS apps to use Mac-native UI elements, and Windows apps to use Windows-native UI elements. (There is no one native Linux UI, so we can leave that one aside...)
[+] [-] iheartpotatoes|6 years ago|reply
[+] [-] jonfw|6 years ago|reply
Totally unrelated to your point, but I'm curious as to what this word means in this context.
[+] [-] s_y_n_t_a_x|6 years ago|reply
Windows support is implemented via https://github.com/Microsoft/react-native-windows and targets W10, Xbox, and Windows Mixed Reality.
MacOS support is experimental, but mostly working. Linux currently needs an Electron wrapper. Theoretically you could port one of the react-native-desktop projects to use GTK or Qt.
Then of course you have native iOS and Android components with Facebook's ReactNative and web support via React.
ReactXP wraps all of these projects allowing you to write React components and TypeScript code that is shared among every platform. It's the same workflow as Electron, even less so, with native UI.
[+] [-] afturner|6 years ago|reply
[+] [-] thosakwe|6 years ago|reply
[+] [-] kristianp|6 years ago|reply
6) Using my preferred programming language.
[+] [-] rohan1024|6 years ago|reply
[+] [-] saagarjha|6 years ago|reply
[+] [-] simion314|6 years ago|reply
In this advanced cases you will need to create custom widgets for each platform, hope that all platform have the advanced datagrid widget(if not you will have to create it) etc.
For simple apps your solution works, and you could also make a CLI app too.
[+] [-] ashsys|6 years ago|reply
[+] [-] happyweasel|6 years ago|reply
[+] [-] tonyedgecombe|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] deathtrader666|6 years ago|reply
[+] [-] glangdale|6 years ago|reply
[+] [-] ken|6 years ago|reply
Yes, time travel would solve most software development problems.
[1]: https://github.com/nim-lang/Nim/issues/6043 [2]: https://github.com/Araq/wxnim
[+] [-] ekingr|6 years ago|reply
I guess since he excludes GTK2 at the beginning for size concerns, wxWidgets and Qt would fall into the same category.
[+] [-] FraKtus|6 years ago|reply
[+] [-] DonHopkins|6 years ago|reply
http://www.ambiencia.com/overviewgalaxytd.php
[+] [-] ausjke|6 years ago|reply
the only true "cross-platform" alternative is electron, which is a bit bloated and slow, but vscode is built on it, along with many others and worked fine. I personally prefer electron these days.
[+] [-] hguhghuff|6 years ago|reply
Here it is in use on raspberry pi https://medium.com/@decrocksam/building-wpe-webkit-for-raspb...
A long video on it: https://m.youtube.com/watch?v=klfE6m1oCkg
A short video on it: https://m.youtube.com/watch?v=wVSwkj9McCU
It says: "WPE is the reference WebKit port for embedded and low-consumption computer devices. It has been designed from the ground-up with performance, small footprint, accelerated content rendering, and simplicity of deployment in mind, bringing the excellence of the WebKit engine to countless platforms and target devices."
I'd be interested to know how to use it.
[+] [-] awalton|6 years ago|reply
"Just use Java or Electron"
I'm sorry, I just can't reconcile the logic here.
[+] [-] oblio|6 years ago|reply
[+] [-] resoluteteeth|6 years ago|reply
[+] [-] almostarockstar|6 years ago|reply
Why can't I write a desktop application that just asks the OS for the users preferred browser and provides it with HTML/CSS and UI interaction callbacks / events? Render it in a native looking window.
We shouldn't need Electron at all! It's like we all have this fantastic rail transport network but insist on riding in our own trains.
[+] [-] monksy|6 years ago|reply
[+] [-] holy_city|6 years ago|reply
You can:
- webview (I mentioned it elsewhere) https://github.com/zserge/webview - sciter https://www.google.com/search?client=firefox-b-1-d&q=sciter - ultralight https://ultralig.ht/
Granted it's not "user's preferred browser" but it fits the bill. They all have issues, largely solved by Electron packaging the browser engine with the binary, and even that isn't perfect.
[+] [-] kitsunesoba|6 years ago|reply
I find this argument a bit silly, because there are few applications that actually need said cutting edge features and even if you’re one of the handful there’s always polyfills, but maybe I’m missing something.
[+] [-] simonh|6 years ago|reply
[+] [-] _bxg1|6 years ago|reply
[+] [-] FraKtus|6 years ago|reply
[+] [-] vortico|6 years ago|reply
If you need HTML5 canvas-style drawing: I propose building an (abstract) SVG document and render with Skia. When part of the SVG document changes, that part will be redrawn by Skia, just like an interactive SVG in your browser. Disclaimer: I haven't tested this idea.
[+] [-] vram22|6 years ago|reply
Andy Brice of successfulsoftware.net has a long-time product, Perfect Table Plan (computes seating plan for weddings, given various inputs) that used Qt (and C++), I've read, on his blog. PTP has been there for years now. Seems to be doing well, based on what he says about it. Don't know how good the Windows vs. Mac versions are, but at least they are there. His newer product HyperPlan may also be on the same stack.
https://www.perfecttableplan.com/html/about_us.html
No connection, just have followed the blog for long.
[+] [-] dysoco|6 years ago|reply
Sadly it's FreePascal, but it really does look like the less bullshit platform to make cross-platform desktop applications.
[+] [-] ryanmarsh|6 years ago|reply
I’m sorry folks, 198MB menu bar apps is what we’re going to have unless a cross platform GUI effort equivalent to that of Chromium comes about.
[+] [-] analognoise|6 years ago|reply
For the love of God, check it out.
[+] [-] TJSomething|6 years ago|reply
While those aren't great numbers, I personally think it's tolerable for most usages.
[0] https://upx.github.io/
[1] https://ssl.icu-project.org/datacustom/index.html
[+] [-] NikGeeonx|6 years ago|reply
Versions for Linux and MacOS X are ready for download. The version for Windows will follow soon - I will speed up development if someone claps in his hands.
[+] [-] ianharrigan|6 years ago|reply
Its essentially a UI abstraction that delegates certain things "backends"
site: http://haxeui.org/ github: https://github.com/haxeui/haxeui-core discourse: https://community.haxeui.org/
It uses the Haxe language (haxe.org), here is a very small/simple/dumb sample of it "in action": https://www.youtube.com/watch?v=cijUTbMKMHI
It can use native components (wxWidgets, android, html5) but you can fairly easily extend it to use other "backends" (like Qt for example - i havent written that backend yet, but its something ill almost certainly do)... It can also handle drawing the components in a variety of methods (so called "composite backends").
Im currently aiming to get it out of alpha asap, and most work goes into "new-component-method" branches (these will become master shortly). Documentation is pretty slim at the moment, but something im actively working on, two examples that i just wrote up today in fact are:
https://github.com/haxeui/haxeui-guides/blob/master/custom-c...
and
https://github.com/haxeui/haxeui-guides/blob/master/modules....
Let me know if you have any questions! Ian Harrigan
Heres some other links / screens that may be useful:
https://twitter.com/IanHarrigan1982/status/11113481164338503...
https://twitter.com/IanHarrigan1982/status/10905353905980416...
[+] [-] netrap|6 years ago|reply
[+] [-] Timothycquinn|6 years ago|reply
[+] [-] Wyndtroy2012|6 years ago|reply
I'd check it out before rolling my own :)
[+] [-] panemic|6 years ago|reply
But if you do some forms and basic UI controls, wxWindows does the job egregiously. Looks the way it should be on all platforms.
It's funny an article from 2016 mentions issues about text rendering, because certainly we've been regressing in this area. I can spot QML and Electron apps by the broken text rendering alone. FF60+ with quantum has incorrect subpixel hinting and does not correctly hint at all sometimes.
Many of the mentioned apps int the article are "broken" in my eyes: I don't have perfect vision, and I do expect apps to follow the system text scaling (and they don't). For a "broken by design" example, see Darktable, which is awesome, and should do this by default, but the authors hard-coded a theme where literally every widget is styled for looks and not for function.
Nobody speaks about how the widgets should feel and interact, but that's exactly what feels off about "GTK" on windows or macos. QML, Electron and partly GTK3 brings that feeling to all platforms. My biggest letdown is QML, as many QT developers see it as the future so it has a larger adoption than it should have.
It breaks just about any rule in the book: poor behavior on any platform, noticeably slower, style not consistent with the platform, broken scrolling, broken text editing, broken text rendering...
[+] [-] FraKtus|6 years ago|reply