This got me thinking: My own experience with desktop development dates back to the late 90s using Turbo Pascal 6 in Delphi, and I'm out of the loop on modern practices. With the evolving landscape, I'm curious about what tools and workflows developers are actually using today.
Some questions to spark discussion:
- What programming languages and frameworks are popular for desktop apps? - Are there any go-to IDEs, build tools, or libraries that make development easier? - Do the above answers change if you care about code performance or efficiency (whatever that means to you)? - Is native desktop app development still viable as a career, or are most greenfield projects shifting to web-based alternatives?
I'd love to hear from folks with recent experience—success stories, pitfalls, and recommendations would be great. Thanks in advance for sharing!
Before that, handling files in the browser was cumbersome. You had to offer download and upload links for users to manage files. And handling whole directories was impossible.
But now web apps are like native software tools that you can use to edit and manage files on the file system.
And the bonus point is that what you build this way is fully functional on mobile too. Right away, without any changes. At least on Android.
Looks like Firefox does not support it currently.
Outside of work, I'm out in left field using Common Lisp for most of my projects, so I'm not sure how helfpul this is, but...
In the past, I used Qt4 because there was an amazing Common Lisp binding and it worked well on Linux, FreeBSD and OSX. It's increasingly hard to use Qt4 any more, though, and changes in the Qt project made the technique used by the Qt4 bindings impractical for Qt5 or Qt6 - at least that was my understanding when I looked into it.
For newer things I've tried LTK but don't really like the looks of it and I wouldn't say it's "modern". It seems to work across platform well enough, though, and for simple stuff it's okay.
More often than not I'm using a combination of the Slime tools in Emacs in combination with an GLFW/OpenGL window. Often I'll use the inspector to display data and make changes that show up in an OpenGL window, or run some commands in the REPL and pop up an image in an external viewer or load something in a browser. It only works for certain types of applications, and I won't even pretend it's practical for end users, but it works pretty well, and it's flexible as a developer.
I'm curious to see what other people say. It's been a while since I madea full blown GUI application.
When I wrote a WPF app at my last job, I write a micro MVVM framework. Basically just an implement ion of INotifyPropertyChanged on the model side and some extension methods to bind the properties to UI elements. It was as strongly typed as possible in WPF.
It was hard to do reasonably with qt4 already. The best solution would be to support the C++ ABI natively, but that's never going to happen.
Internally the “UI” team is tiny (basically me, a UI/Designer and one or two other part time engineers) and the productivity is astounding tbh
Knowing Google, this happening is almost a guarantee. You should consider moving to another framework with a longer shelf life.
I've been using Visual Studio Code and Github Copilot together, and it seems to work ok. I've not used it heavily, though, as I'm retired.
Here's my attempt from 2021: https://github.com/QotoQot/Octospace
However, I find The Qt Group's commercial licensing (and their tactics as reported by various people on HN) a little scary. If I were to go commercial, I think I would stick with LGPL Qt and link dynamically or give customers my object files for re-linking, because I get the impression that accepting a commercial Qt license could restrict my ability to use open-source Qt elsewhere. I suppose there might be some other way to safely navigate those waters, but from what I've read, The Qt Group has a reputation for making this far from hassle-free. It's not an immediate problem because I currently use Qt only for open-source and personal tools.
I have grown tired of C++, so I've been using Python to drive Qt. The bindings are very good, mirroring the C++ API so closely that I just use the C++ docs when I need to look something up.
I've also been watching for Qt bindings to other compiled languages, mainly for distributing non-Linux GUI apps more simply than Python allows. Such bindings often turn out to expose only Qt Quick, which lacks functionality that I sometimes need, but there are a few that expose Qt Widgets. For example, these Go bindings:
https://github.com/mappu/miqt
I hope we'll eventually see a cross-platform GUI toolkit rivaling Qt in a language more pleasant than C++ (and ideally easier to bind to other languages). The one being developed for internal use by the Zed editor has some promising ideas about how to render native-looking text, which I think is a good start:
https://zed.dev/blog/videogame
https://www.gpui.rs/
Will come back next year :-(
https://akkartik.name/freewheeling
<3
1. Download LÖVE from its website.
2. Download my app (as Lua source code).
It's not going to lead to Instagram-level downloads, but that's not the aim. My goal is to teach people a little at a time to be thoughtful about whom they trust to run code on their devices. Forcing people to take 2 steps hopefully has 2 benefits:
1. You start from day 1 to take baby steps in being mindful of how software is put together for you to use. It's not just a single hermetically sealed box. This part comes from one supplier, this part from another. Both can be modified, and require different skills to modify.
2. You start from day 1 to take baby steps in thinking about whom to trust. Here there are 2 separate projects that would be very hard to collude together. That limits at least the level of malicious stuff I can do.
Summary: I don't want a bunch of people blindly trusting me. I want a few people choosing mindfully to trust me.
https://www.lazarus-ide.org/
In general, if you use a minority platform you have to assume it has a tiny minority testing it and so budget for there to be more bugs and so on. LÖVE itself is rock solid, but programs built on it may not be. So I try to minimize the number of layers of libraries I add atop it. So far that has meant I found it easier to just draw my own UI in all my programs.[1] I've only played with Slab a little bit myself.
If you use Slab, please do report bugs. I've done that in the past when I've used it. That's what it takes to make a minority platform more stable.
[1] Drawing all my own UI also keeps my download sizes small. For example, https://akkartik.itch.io/carousel is 400KB. If you take out 4 fonts and the extensive online help, the code itself is only 100KB. By comparison, Slab seems to be almost 1MB of code. But that's just me. I care a lot about being easy to download on slow internet connections, and less code seems more hackable. But I give up some creature comforts, and reasonable people will disagree with me about the value of a UI library.
Normally with the Windows DX12 backend, sometimes with the SDL+OpenGL backend if you want cross platform support.
Other frameworks are sort of disappearing. C++ all the way although some use it with C#.