> 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...).
But sure, qt seems to hit 1,2,3 , although 3.1 will fuel flamme wars that we dont realky care about as long as you can ship code. Good for you !
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
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).
i.e. you don't actually write comparable code. Instead, you just lambast how slow the compiler is.
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.
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...)
Most of the users of the FOSS software I'm developing also switch platforms depending on the project they're in, but they want the software to be the same everywhere for instance.
As annoying as it is to switch form cmd+C to ctrl+C when I go from Mac to Windows, it's even worse when a Mac app uses ctrl+C.
Branding teams are in my experience very picky about lots of stuff. For example, my employer's brand design team recently released a rule that when our logo is included alongside others logos in a list of companies involved in a partnership, it may not be included in a vertical list, only a horizontal list.
Using the standard background colour for the platform on your app when it's not one of the brand design team approved colours? Also out.
etc. etc.
It's a common concern to avoid confusing users who switch OS often (eg when demoing on someone else's machine.)
The fact that it contradicts the other requirement ("but it does not look like the other apps") is lost on no one.
See VSCode, Discord, Spotify...
It's easier to get a single code-base that 'just works' across platforms if you have an abstraction that is truly cross-platform. One of the major value propositions of developing with Electron is this ability to develop cross-platform 'with confidence' - I can build an app on Windows and be 99% sure it's going to look function the same on OSX / Linux.
> I want my macOS apps to use Mac-native UI elements, and Windows apps to use Windows-native UI elements
That's a fine goal but it means you end up needing more platform-specific code. It's a trade-off, and there isn't a one-size-fits-all solution.
To take Discord as an example, I don't know that people actually can't live without the UI slavishly copied for every platform; I think people rather want light and dark themes on all platforms, message formatting to look basically the same, and for everything to be found in roughly the same place.
This idea that users expect apps to look the same is, I feel sure, something someone said and everybody has gone along with. In my experience, people want things to behave consistently — so if Discord had a native Windows client and a native macOS client, people would be more interested in whether or not they could still find the little microphone and headphone buttons at the lower-left of the screen, sod if the icons and colours are identical.
But I suspect lots of software companies would think that describes them, when in reality there's probably fewer than 10 products that meet that bar.
Totally unrelated to your point, but I'm curious as to what this word means in this context.
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.
6) Using my preferred programming language.
https://github.com/flutter/flutter/wiki/Desktop-shells
they say -
"Work is ongoing to extend Flutter to support desktop as a target environment, allowing developers to create macOS, Windows, and Linux applications with Flutter"
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.