So many sub-debates hidden in this "cross-platform native GUI":<p>1) I want to write a GUI code <i>once</i><p>2) I want to ship <i>something</i> that works on Windows / Linux / MacOS<p>2.1) I want to ship <i>something</i> that looks the <i>same</i> on Windows / Linux / MacOS<p>3) I want to ship a <i>binary</i> that works on Windows, a <i>binary</i> that works on Linux, a <i>binary</i> that works<p>3.1) I want to ship a <i>small</i> and <i>efficient</i> binary<p>4) I want to ship <i>something</i> that looks like a Windows app on Windows, a Linux app on Linux, a MacOS app on MacOS, etc...<p>(By definition, "I want to ship something that looks the same everywhere <i>and</i> looks like an app of my host" is meaningless, right ?)<p>The "holy grail" seems to be:<p>5) "I want to write a GUI code <i>once</i> 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."<p>It's seems from the debate that nothing obvious fulfills 4 and 5.<p>Then it comes to which requirement you're ready to drop.<p>If you're ready to drop requirement 2) , I suspect you're doing MacOS specific, go for it ;)<p>If you're ready to drop requirement 1) , I suspect your managers / salespersons disagree.<p>I suspect your manager / salespersons do not care about requirement 3.1), but it's debatable. Use Qt/Electron, and ship <i>something</i>.<p>I suspect your manager / salespersons do not care about requirement 4), and I suspect they're esthetics, which can not be defended.<p>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.<p>I hope someone is able to get to 1 + 2.1 + 3.1 someday.<p>I'll use that.
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.
Anyone got experience with this? <a href="https://webkit.org/wpe/" rel="nofollow">https://webkit.org/wpe/</a><p>Here it is in use on raspberry pi <a href="https://medium.com/@decrocksam/building-wpe-webkit-for-raspberry-pi-3-cdbd7b5cb362" rel="nofollow">https://medium.com/@decrocksam/building-wpe-webkit-for-raspb...</a><p>A long video on it: <a href="https://m.youtube.com/watch?v=klfE6m1oCkg" rel="nofollow">https://m.youtube.com/watch?v=klfE6m1oCkg</a><p>A short video on it: <a href="https://m.youtube.com/watch?v=wVSwkj9McCU" rel="nofollow">https://m.youtube.com/watch?v=wVSwkj9McCU</a><p>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."<p>I'd be interested to know how to use it.
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.<p>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.<p>We shouldn't <i>need</i> Electron at all! It's like we all have this fantastic rail transport network but insist on riding in our own trains.
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 native look and feel: <a href="https://github.com/andlabs/libui" rel="nofollow">https://github.com/andlabs/libui</a><p>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.
Adding my 2c (of anecdote) to this thread:<p>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.<p><a href="https://www.perfecttableplan.com/html/about_us.html" rel="nofollow">https://www.perfecttableplan.com/html/about_us.html</a><p>No connection, just have followed the blog for long.
I know the author focused on Nim, but I wonder how Lazarus (or Delphi I guess) would fare.<p>Sadly it's FreePascal, but it really does look like the less bullshit platform to make cross-platform desktop applications.
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.<p>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.<p>While those aren't great numbers, I personally think it's tolerable for most usages.<p>[0] <a href="https://upx.github.io/" rel="nofollow">https://upx.github.io/</a><p>[1] <a href="https://ssl.icu-project.org/datacustom/index.html" rel="nofollow">https://ssl.icu-project.org/datacustom/index.html</a>
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 <a href="https://www.geeonx.org" rel="nofollow">https://www.geeonx.org</a> .<p>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.
Hi all, one option might be HaxeUI (full disclosure, im the author!) :)<p>Its essentially a UI abstraction that delegates certain things "backends"<p>site: <a href="http://haxeui.org/" rel="nofollow">http://haxeui.org/</a>
github: <a href="https://github.com/haxeui/haxeui-core" rel="nofollow">https://github.com/haxeui/haxeui-core</a>
discourse: <a href="https://community.haxeui.org/" rel="nofollow">https://community.haxeui.org/</a><p>It uses the Haxe language (haxe.org), here is a very small/simple/dumb sample of it "in action": <a href="https://www.youtube.com/watch?v=cijUTbMKMHI" rel="nofollow">https://www.youtube.com/watch?v=cijUTbMKMHI</a><p>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").<p>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:<p><a href="https://github.com/haxeui/haxeui-guides/blob/master/custom-components.md" rel="nofollow">https://github.com/haxeui/haxeui-guides/blob/master/custom-c...</a><p>and<p><a href="https://github.com/haxeui/haxeui-guides/blob/master/modules.md" rel="nofollow">https://github.com/haxeui/haxeui-guides/blob/master/modules....</a><p>Let me know if you have any questions!
Ian Harrigan<p>Heres some other links / screens that may be useful:<p><a href="https://twitter.com/IanHarrigan1982/status/1111348116433850368" rel="nofollow">https://twitter.com/IanHarrigan1982/status/11113481164338503...</a><p><a href="https://twitter.com/IanHarrigan1982/status/1090535390598041600" rel="nofollow">https://twitter.com/IanHarrigan1982/status/10905353905980416...</a>
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.<p>I'd check it out before rolling my own :)
Mostly good article, but I don't appreciate the gratuitous dunking on web devs towards the bottom:<p>"so developers can use hipster technologies like HTML, CSS and JavaScript"<p>"the vast armies of newskool web developers who grew up on JavaScript and the DOM"<p>...especially when the author doesn't really appear to know what he's talking about in that space:<p>"And when things don’t quite work as expected, you can’t do much about it—short of maybe just switching to a different framework as a last attempt."<p>"and long-term maintenance will be a nightmare."<p>"web development technologies—which technically don’t provide any advantages over more traditional approaches"<p>There are legitimate criticisms of Electron as a choice for desktop apps, but that doesn't invalidate an entire domain's worth of developers.
What is this ridiculous obsession with executable size? How much time did this author spend chasing down alternatives to a measly 120MB? If they're working on art project then fair enough, but if they're working on a useful program then surely anything else they could have done with that time would have brought more value to end users than shaving off 3 cents' worth of disk space.