Quest for the Ultimate GUI Framework
Shamelessly copied the title
I’m on a quest.
The quest is to find the best way to produce desktop applications. I’m sick of all the mobile garbage and want to create a functional, fast desktop app. To my absolute horror, it proved to be an almost impossible task.
I loved working with Win32 Graphic User Interface Advanced Programming Interface. That’s a mouthful and is usually shortened to Win32 GUI API. Win32 is old.
It often feels as though Microsoft has been trapped in a cycle of repeatedly reinventing the wheel whenever it comes to Windows GUI development, and it looks like I'm not alone in this. Pavel Yosifovich from Sysinternals (a very useful set of tools for anyone wanting to dig a little deeper into Windows, especially Process Explorer) has a blog post I stumbled upon titled The Quest for the Ultimate GUI Framework, from which I stole the title. As my college teacher once said, if you're gonna copy, copy with pride.
Back in the day, every control was its own little window (an HWND), laid out by pixel-perfect coordinates. Buttons, list views, and tree views—all had to be manually positioned, sized, and even drawn if you needed a custom color or style. Want a green button? Better subclass, override WM_PAINT, and hope you didn’t break something else: no panels, no automatic layouts, zero visual flair—just raw, unvarnished API power.
I remember creating custom-shaped windows, which was all the craze in the early 2000’s especially among media players. Just use SetWindowRgn() :)
Mr. Yosifovich In his post, he goes over different ways graphic user interfaces have historically been built in Windows, so I will not rehash his post in detail, but let’s go through it in tl;dr style.
To wrangle Win32’s complexity, Microsoft unleashed MFC (Microsoft Foundation Classes). Suddenly, you had C++ classes, wizards, and docking windows, but at the cost of a hefty DLL and a steep learning curve.
The early 2000s saw everyone gushing over Visual Basic’s drag-and-drop glory and me enjoying Delphi 7. Then WinForms arrived under .NET, keeping that designer magic but adding generics, events, and the full power of C#. It still leaned on HWNDs, but customizing controls got easier: images on buttons, colored menus, and the familiar toolbox of components.
Then came the shit show. .NET 3.0, XAMLs, Templates and styles that let you skin controls WPF , “Metro” (later UWP) and a fresh XAML dialect. Full-screen, monochrome icons, single-instance apps. And all it did was introduce more and more complexity with the stated goal of reducing the complexity of the Win32 API. The only result was a slower and more complex way to build User Interfaces.
Windows 10 and 11 story splintered across UWP, WinUI, .NET MAUI, and more. None feels quite right for a serious desktop app.
Then there are third party controls like Qt, wxWidgets, GTK, UNO, ImGui, and many more UI frameworks with their own quirks and ideas about how things should work.
A decade ago, I gave up on making desktop apps and focused on web, but there was always an itch. I like desktop apps, the speed, direct access to hardware (more or less), and far fever restrictions and permission management compared to apps that run in the browser. And, I also like my apps working if I don’t have Internet connection.
Dame you Microsoft, and Windows for isolating the user from their mistakes when doing low level hardware access.
I really, really would like to recreate my old Samurize applet that plays with keyboard LEDs without actually changing the status of those keys, but Papa Bill won’t let me.
A year or two ago, I bit the bullet and went looking for a way to do desktop apps that is modern, web like as I liked the ability to express design in CSS, structure in HTML, and functionality using JavaScript.
So I found Electron. It is basically a Chromium and Node.js bundle. It uses JavaScript on the front end and at the back end, which made it a simple switch, as all the technologies that work for online apps work with it, except that you are using InterProcess communication channels (IPC) to send data from the backend to the frontend. This at first does not look bad, but really quickly becomes a huge mess if you are not careful. I had an app that sent a lot of graph data back and forth, and it turned into a slog fest really fast.
For low-intensity apps, which most web apps are, this is fine. Not for me, though.
Then I tried Tauri, it’s the same as Electron, but instead of JavaScript, it uses Rust as a backend language. Everything else is the same, with different naming. Tauri also does not bundle a browser with it and relies on the system's default browser. This makes the app much smaller, but it has other issues. The least of them is the use of Rust, the most verbose, boilerplated language I have come across.
I know a lot of people love it, but I just don’t see the benefit compared to proper usage of C. Just stick with the NASA C guide or The Power of Ten – Rules for Developing Safety Critical Code, and you will be fine. Call it a skill issue, but I don’t care. Using MUT over and over is just not my cup of tea.
Then I found out that the issue is more the speed of the frontend than it was the backend’s issue. The rendering and update speed of web browsers is not that great unless they use canvas to render everything.
Disillusioned, I tried a different approach.
So, Python to the rescue. I know, not the fastest language out there, but it’s fast enough for almost anything I plan to do, and is excellent for fast prototyping, and if you keep an eye on how you structure your code from the outset, you can actually make a pretty large app. The app I’m currently working on has over 20k lines, and it’s still manageable.
For creating the User Interface, I tried tkinter, Qt, PyGame, and dearPyGui.
Tkinter is too basic, Qt is too corporate, and if you want to be “legit,” you will need to pay thousands. PyGame is a game engine, and then there is dearPyGui. DearPyGUI is built upon imGUI. A “Bloat-free Graphical User interface for C++ with minimal dependencies”. Nice!
A good showcase of some apps that were built using DearPyGui can be seen here.
DearPyGui renders all of its widgets itself on the GPU rather than delegating to your operating system’s native controls. This means you won’t get default button shapes, menu bars, or font rendering from Windows, macOS, or Linux. Every slider, checkbox, and window is drawn pixel by pixel by dearPyGui’s imGUI powered backend and have a basic or minimal look that I like. The upside is perfect consistency and extreme performance across platforms; the downside is that if you want native look-and-feel or built-in accessibility support, you’ll need to implement theming and accessibility hooks yourself.
Underneath the hood, it uses dearImGui’s immediate-mode rendering engine, but dearPyGui exposes a “retained-mode” API. That is, you create widgets once and they persist in a scene graph until you delete them. You don’t redraw every element manually each frame; instead, you call high level functions like `add_button()` or `add_slider_float()` to build a persistent UI hierarchy, and dearPyGui handles the draw loop and event dispatch for you. This combination gives you the familiarity of retained mode toolkits, where widgets remember their state together with the raw speed of GPU accelerated, immediate mode rendering.
Currently, I’m using dearpyGUI to render several thousand datapoints that are processed in realtime from a connected device, and those datapoints are plotted on several graphs at the same time, and it’s working perfectly.
I have one file where I design the layout, another that holds all themes and they all connect to the main app, not unlike HTML/CSS, with the ability to add code within the layouts to make them even more responsive.
So, I’m satisfied with where I ended up. The only thing that could improve it is if it had a What You See Is What You Get editor.