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.
As a middle of the road developer I think it’s difficult to find any consensus (besides electron being both simple and hated).
What resources are there for building quality, functional cross platform desktop application?
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://quark.sciter.com/
[2]: https://www.qt.io/
The application uses exactly same code on all platforms: https://github.com/c-smile/sciter-sdk/tree/master/notes
It even runs on Windows 2000: https://sciter.com/necromancing-sciter-on-windows-2000/
I couldn't tell, just from glancing at the website/github.
UI, application logic and data storage.
QML is far not enough for this I think.
It took me 3.5 months ( https://notes.sciter.com/2017/09/11/motivation-and-a-bit-of-... ). But I shall admit that this does not include architecture time as I knew internal architecture of EverNote upfront.
I do think Dart itself is a fine language, though.
I would actually say that it is perhaps the fastest in the list.
1.1k https://github.com/topics/pascal
Qt is good but it requires you to go fully into the Qt ecosystem (build tools, etc) not sure about QML though.
For wxWidgets, there is wxUniversal, which draws custom controls, thus easier to customize - not sure how well it is maintained though.
I'd argue that dev time is quite fast for all - Qt, wxWidgets, Lazarus.
What people initially miss about UI libraries is composition features. Which are over the top for QML and not so to put is softly for Sciter.
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!
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.
This is probably sound business advice, but it's also a bit sad to shift the goal from trying to create "great software" to "not horrible enough to make all potential users run away".
Webviews are okay on mobile though.
Do you have examples of that? I believe the majority of users will be running a quite recent version of Safari and Edge in these circumstances.
How will people notice if you are using Electon, but not if you are doing this? Is Electron doing something that makes it unnecessarily slow or are you saying that people are just conditioned to think Electron apps are slower?
A public example: Dwyrin is a YouTube streamer playing Go/Baduk. After most streams he reviews the game and likes an app called Sabaki. About 8:10 minutes in, he remarks on the performance of the app (https://youtu.be/vrX4qlbpQfU?t=492). Sabaki is an electron based app.
I do however disagree with removing right click / highlighting. That makes copy paste difficult or impossible for the typical user. I spent years working on Silverlight and UWP and one of the things I recall the team looking back on particularly with Silverlight and regretting was that TextBlocks by default didn't have highlightable text. Its too useful for users sharing error messages with you as the developer or data with each other to get their jobs done.
Electron likely helped Sabaki focus on other features with good enough performance, while being the best looking and most skinnable Go app by a country mile (I created a How to train your Dragon skin to temp my partner into learning Go :D)
Only so many hours to dedicate to a project, you have to pick what you value most. This comme T is partially because I'd hate for the people involved with Sabaki to not hear that at least some of their users "get it" and love it.
If you are making an application that you expect users to run as a background process, perhaps Electron isn't the best option.
If Electron is for an application users will open, use, and close, Electron is an excellent tool for the job.
My two electron applications as examples:
Video Hub App: https://github.com/whyboris/Video-Hub-App & https://videohubapp.com/
Simplest File Renamer: https://github.com/whyboris/Simplest-File-Renamer & https://yboris.dev/renamer/
I've never had good experiences with templates. They usually have too many dependencies or too many custom tweaks. There's one I'm using on a project at work (was chosen before I joined) and it's a huge mishmash of Bootstrap/Material Design and other stuff. Proper mess.
Much easier to just choose a style framework like Bootstrap and build it yourself.
2> Instead, use the native WebBrowser control in .NET for Windows
Use WebView2 instead. It uses the new Edge/Chromium rendering engine - https://docs.microsoft.com/en-us/microsoft-edge/webview2/
> The WebView2 Preview is intended for early prototyping and to gather feedback to help shape the API. You should not use the preview in your production apps because there may be breaking changes.
There's not much more to it than you can see, there's the BIM360 tab on the left that allows browsing through a cloud directory structure, and Civil3D also has a learning content tab.
Qt-based Software uses Qt WebEngine instead of the .NET stuff. The reason we're using HTML + JS is that we wanted to share the start page between different applications and HTML + JS is the lowest common denominator so to say, something that every team could integrate.
I suspect that the needed complexity of the UI factors in heavily as to how well this approach will work.
I wrote a little framework for this: https://github.com/jdarpinian/web-ui-skeleton
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.
See https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy
Exposing a HTTP port with application state is a million times worse for security
Why?
1. Cross platform - Mac OS, Linux and Window and Raspberry Pi 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
9. Lazarus has a built-in debugger which is quite powerful and the development environment has full integration with it.
To see a demo of the Lazarus IDE including the debugger functionality, please see the video in the page below: https://www.getlazarus.org/new/
10. Lazarus is 100% open source and is under active development with the last release in July 22, 2020.
Lazarus is not a new fad language. It has been in existence for decades and there are existing apps which are developed in it - example, the Transmission GUI client.
Other projects done in Lazarus: https://www.getlazarus.org/community/showcase/
Projects by category. This is not a full list: https://wiki.freepascal.org/Projects_using_Lazarus
A file manager has to plug into multiple native features, e.g. the list of app associations—and DC does that sorta half-assedly.
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/
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
Here is a write up on the advantages of Free Pascal: https://www.freepascal.org/advantage.var
A few months ago I developed a Kanban tool to organize my personal tasks. I use the tool under Windows and Linux, it works fine.
For me the big advantage of Lazarus/FreePascal is that you have to write the business logic only once and you compile the code for different environments to get native binary files (no interpreter used). In case of operating system specific code you can use conditional compilation (e.g. {$ifdef MSWINDOWS}) but in my case that wasn't really necessary.
Freepascal Runtime Library documentation: https://lazarus-ccr.sourceforge.io/docs/rtl/
Lazarus Component Library: https://lazarus-ccr.sourceforge.io/docs/lcl/
Freepascal Component Library: https://lazarus-ccr.sourceforge.io/docs/fcl/
Freepascal Wiki: https://wiki.freepascal.org/Lazarus_Documentation
Something else I should have added in my original comment: Lazarus has a very capable built-in debugger.
That is invaluable if you want to step through and understand how things work.
EDIT: Other sites:
Some demo projects here: https://www.getlazarus.org/
Lazarus project showcase: https://www.getlazarus.org/community/showcase/
The Transmission Bittorrent GUI client was done in Lazarus: https://sourceforge.net/projects/transgui/
Other apps done in Lazarus from the Lazarus website shown by category: https://wiki.freepascal.org/Projects_using_Lazarus
However packages (which includes your own widgets) are nothing more than native libraries that become part of the IDE, so any bugs in a package will cause the entire IDE to crash. This is a double edged sword since on one hand you can get a less stable IDE from your own bugs, but on the other hand when you work with a component or widget in the visual editors, you are really working with a "live" instance of that widget that is then serialized as part of the form or data module instead of a mock stand-in object that some other GUI-only designers will give you. Also this allows you to use any TComponent-derived object through a visual editor, not only visual/GUI objects.
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.
Where should I look? I’m willing to put in the work!
There are a few others here:
https://wiki.python.org/moin/PyQt/Tutorials
The 2020 one there may be what you're looking for, more than hello world but doesn't quite all the way get to the kitchen sink, just maybe the silverware drawer.
https://upload.wikimedia.org/wikipedia/commons/e/e8/Qt_Creat...
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.
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.
Now, don't let the screenshots color your impressions as to what kinds of UI designs are possible under Qt: Ripcord's UI is bare-bones on purpose; it's a selling feature. I bring up this application because it lets you do a more apples-to-apples comparison: IM clients these days are a poster child of an Electron app that uses orders of magnitude more resources than they should for the functionality provided. Ripcord lets you compare the experience and performance with a native app, implementing the same features but without overhead and gratuitous UI shine.
(And personally, I do use it for Slack/Discord instead of official clients.)
Autodesk Fusion 360 uses Qt[1]. (It's 3D CAD modeling software like Solidworks/Inventor). Some screenshots of its UI : https://www.google.com/search?q=%22autodesk+fusion+360%22+ui...
CAD/CAM modeling software is resource intensive and users always complain about slow performance when manipulating big files so writing that type of app in Electron/Chrome/Javascript browser engine would be worse than native C++/Qt.
That said, another competitor Onshape is browser-based and yes, people do complain about its performance.
Some other well-known desktops using Qt are Autodesk Maya and Wolfram Mathematica.[2]
[1] https://forums.autodesk.com/t5/fusion-360-api-and-scripts/wh...
[2] https://en.wikipedia.org/wiki/Category:Software_that_uses_Qt
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.
That said, what happened to the last couple of generations? When did freedom stop meaning "free" and start meaning "fair" or "the right thing"? How did our culture get things so tangled up that our urge to "not potentially offend anyone" started eroding the very principals we think we are upholding? You must be young. /rant
Suggesting accessible software is a human right? You have to know how silly that looks compared to the list of other things that qualify as human rights.
I'd argue that what's truly silly is refusing to recognise that software/the web is becoming (if not has already become) as much core global infrastructure as physical equivalents are. We can't push for and actively build an increasingly online world and then plug our ears and pretend that the accessibility of online spaces isn't as important as the accessibility of physical ones.
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?
You might miss or be unaware of accessibility concerns when developing, but it's easier to go back and fix what you missed than it is to build an entire ui and go back and add accessibility to begin with.
As to electron, if you want to leverage web skills to build a mobile app, it's a cromulent solution. I don't think big companies with resources should use it (slack), but for JS devs who want to build things, it's a great tool. Most people I work with don't realize slack and vscode are both electron apps.
In my opinion, this depends whether the software in question improves the lives of its users or makes the lives of non-users worse.
If it's just another media player we don't have to use, accessibility would be cool, but it's not really that important. If it's a chat solution for companies, accessibility is absolutely crucial, open-source or not. Not implementing accessibility means people could lose their jobs if their companies switch to it. Society would be better off if this software never existed in the first place.
For the record, the default choices for text size here on Hacker News are an example of ignoring basic accessibility.
Java on Linux/Mac is fine.
Never have to comply with the law if you never have any users to begin with
GTK user tapping head
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, 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.
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?
Clj-kondo is good to detect unintended passing, in terms of correctness there are sometimes minor fixes but not at the expense of backwards compatibility which is taken very seriously in core
In terms of doing idiomatic Clojure in Typescript, "good" Clojure is data driven Typescript is type driven
Universal data primitives Vs label everything with types aren't terribly compatible
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.)
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.
With native UI, eventually the development will stop. With cross-platform, you will, FOREVER, try to catch up.
P.D: i have used more than +12 main languages and as many or more UI toolkits.
The native UIs are running even close to a DECADE without nothing of significance on maintain. The rest? is rewrite, recode or workaround....
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
If you really, really want your app to use Gtk+ on Linux and be reasonable elsewhere, consider wxWidgets.
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.
How do you keep your native apps well behaved?
Even though the widget toolkit is designed to run on Electron, people still use Firefox to browse the internet.
As the young people say: "lmao gtfo"
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.
Because it looks ugly (i.e. non-native) on pretty much every platform. Qt has different levels of success at that, having most problems with macOS and Android.
Also, there's Qt Quick, which lies somewhere in the middle between classic Qt and 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
The reason why classic single-threaded GUI toolkit are the way they are is because you can perform a custom reactive drawing or just reactive UI update in a blink of the eye, so user won't notice any delay. I know there are some bad examples like java-based IDE bloatware, but there are good examples like... Chromium! However, you cannot develop Chromium with Chromium, but you can develop something similar to Chromium with Qt.
>Memory? It's 70MB
Haven't seen Electron application using less than 200 Mb of memory. For example, launching Skype plus chromium SPA takes 550 Mb of RAM on my system. JavaFX has similar problems.
>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
Like what? I'm not aware of any special Slack's features that could be hard to implement using classic GUI toolkits.
Like what?
I mean really. How would any of Slack's UI be impossible in QT? And conversely, if HTML is so good, why have we never actually written any applications with it, and instead rely on templating languages?
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.
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...
I still prefer Kotlin, but there have been very, very few occasions where I've not been able to do what I wanted with Dart.
Isn't WebView kind of work around for web browser being overbloated? I mean they made single instance of browser and interfaces for embedding that single instance, but do you really need that for desktop?
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...
[1] https://medium.com/swlh/what-makes-godot-engine-great-for-ad...
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.
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
- 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)
WxWidgets is no better than the other non-native GUI toolkits. It just looks, feels and acts like crap all the same. Great for development, bad for everything else.
Are there any other cross platform languages with bindings to native GUI frameworks?
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?
Also see Qt Creator.
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.
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.
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.
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 Still, Skia is not _that_ bad, maybe it’s fine there.
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/
[2] https://apps.apple.com/us/app/uno-calculator/id1464736591
[3] https://platform.uno/docs/articles/getting-started/requireme...
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.
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
Price seems to range from ~$2000 to ~$4500 to use it, which feels a bit steep.
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.
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.
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/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.
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.
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.
It has accessibility problems, excludinga certain group of users, including blind people. I'd urge you to reconsider.
So I'd start by asking yourself whether you really need your application to be cross platform.
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.
There’s also FuncUI, an elm-like layer over Avalonia written in F#.
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?
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)
[0]https://devblogs.microsoft.com/dotnet/introducing-net-multi-...
Although I've not yet tried it myself, there's AndroWish (https://www.androwish.org/home/home). Deploy your TCL/Tk code on Android with minimal changes.
Another option is to look into Flutter. There are many available iterations for desktop applications, one of them is the go-flutter[1].
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.
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.
They are using it to build Onivim 2[2] so they are _very_ committed to making improvements.
[1] https://www.outrunlabs.com/revery/ [2] https://onivim.github.io/
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.
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.
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.
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..
There’s also these tiny but high-quality frameworks for C++: https://github.com/andlabs/libui https://github.com/cycfi/elements
Needs a target machine to build the output executables, but other than that, it's great!
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?
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.
For example, [NetBeans 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) 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/) (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.
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... https://github.com/danap/lindyframe
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 $$$.
Have folks used it? Is it any good?
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.
https://www.red-lang.org/2016/03/060-red-gui-system.html
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?
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.
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.
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.
Sounds exciting, no idea how far along it is. Hadn't heard of it until today.
It looks like a good alternative to Electron but haven't tried. Anyone?
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.
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.
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.
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.
