Now that Chromium supports the File System Access API on desktop and mobile, I am building every software I need as HTML+JS+CSS.
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.
What about FireFox, does/will it support file system access? I'm not an expert, just thinking this way and don't like Chromium. The idea is to use light web server in application + browser with JS. This makes it easier and more convenient as it can naturally run remote, on microprocessor. Also LLMs are good at generating such UIs.
This is how I develop all the software that I don't work on professionally. I have a variety of small web servers with various capabilities that I use. The latest is Copy Party, which I learned about from HN a couple of weeks ago. My apps are then single files that know how to write modified copies of themselves back to the server. The server is dumb, it doesn't really know that it's anything other than just a file upload. I then use SyncThing to replicate that folder structure across all my devices so I have offline access by default.
Copyparty[0] is amazing. I've noticed copyparty+webdav is a lot faster for browsing my NAS than smb or nfs from macOS.
I've been meaning to build a gallery application (or simple web page) that can browse pictures from a copyparty instance and sort/organise them with an UI fit for my purpose.
Any pointers how I could make one that self-saves to copyparty?
Sorry for taking so long to respond...I was out on vacation!
The general strategy is to figure out what state needs to be stored in your app, and combine that into one div in the page that can be grabbed via something like innerHTML. For a gallery app that is viewing pictures on copyparty, that will be the metadata, like the URL of the image, the tags you want to apply and/or what category it is in, the index within the album, the date info, etc.
Then, when your page loads, you can load all that and reason about how to arrange your photos, what to display, etc. Once that's done, the URLs can be swapped in to generate the appropriate view. I would give some thought to how to leverage WebDAV to create a directory that can store e.g. thumbnails. Copyparty does that itself, but your app should likely have its own disk-based cache accessible from a folder served by Copyparty.
The self-save part is mostly creating a something like a clone function that knows how to clone the static parts and inject updated sections for the data. I've written a little about about how to do this in my post years ago about a TiddlyWiki saver written for jart's Cosmopolitan.
It's even worse than that. If you click on the resources section, you can see that Mozilla considers the proposal harmful[1]. They say there's a subset of features that they may consider. Safari seems to be in the same boat, but I can't find an official standards position.
I have been evaluating and testing the Filesystem API for a local first web based CAD editor and having direct r/w access to the filesystem is a great way to make such a thing, couple with the FilesystemObserver[1] API this makes building proper editors on the web a breeze.
In place of this, Firefox recommends using the origin private file system (OPFS)[2] which is basically a sandboxed filesystem that the users cannot access. Though I agree from a security perspective it kind of makes sense (not particularly for my usecase), but it removes the ability for the user to have realtime changes on local files.
An example of this is using the web based tool as an intermediary step or a processing step in a bigger pipeline; I save it using my web tool and then native applications automatically handle file updates.
This just creates an extra step for Firefox/Safari to replicate changes locally by having to manually update local files.
Also neither Firefox nor Safari support showDirectoryPicker() which also creates blocks for building a web based editor.
I love Firefox and I hope they can add support for this. I have stopped caring about Safari/Webkit completely because it's hellish to try and maintain feature parity while NOT sacrificing innovation and ease of use.
At work we use C#, .Net, and WPF. I've only used it at this company, and I can't say for sure if my dislikes are with WPF, or how our codebase is using it. Overall it's not terrible, except for being proprietary and Windows only.
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.
There are defiantly better and worse ways to use WPF. Personally I dislike it when data binding is done in XAML, because there is no compile time error if you rename a property on the C# side.
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.
> 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.
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.
It had layoffs in 2024. And Google has emitted a bunch of words about their support for Flutter, but hasn't taken the most obvious step towards solidifying support: guarantee a minimal spend level on Flutter dev for a decade, either internally or by donating to an external foundation. eg we will spend $x on Flutter until 2036. :shrug: So they've carefully retained the option to cut support at will. Which is their choice, but I recently wasn't comfortable starting a greenfield project in it for that reason.
Everyone says this but personally it's been fine for me in 2025. It won't land you a job or funding because people are afraid of it. But if you're going to just build tools, it works.
Sure, but pointing even a single eng team at it is a multi-million dollar investment annually. I can't do that for sdks w/o firm support or enough industry adoption that the industry can shepherd ongoing development.
We shipped a project at work with Flutter recently, specifically using it on embedded Linux, basically a touch screen smart apartment tablet/thermostat combo.
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
Okay so we ended up using that too, it was really well done and documented.
But in hindsight I think flutter-pi or the Toyota one might have been a better investment. The lead engineer in Sony behind the elinux project left for Nvidia. The Toyota one uses Wayland, you can't make it directly hook into DRM. So you'd need a minimal compositor to get it running.
Flutter Pi had other issues. It required systemd as a dependency just for the event loop which we ended up having to hack out. The Sony embedded project is still being updated and active. And the code quality is much better
Ooof I had a short chat with a maintainer with one of the competing projects and they really hated on the code quality for the sony embedder.
I just didn't like the lack of control you got with the sony embedder, you couldn't specify which display you wanted to show on when using DRM and it was real pain to get it working.
I didn't know about the systemd dependency, but we actually needed it though even though we used Sony because of our dependency on DBus.
I do have to wonder if decoupling dart from flutter would boost flutter. Flutter and typescript, dart is fine but you know most people have another major language with tooling and what not
I am primarily an Elixir engineer so Dart was the exact opposite of what I’m usually working in, that said it’s not hard to get up to speed on Dart conventions- and other team members were able to get up and contributing in a couple weeks
Lazarus is the open source equivalent to Delphi these days, and for the most part it's awesome. (The documentation, on the other hand... just isn't fit for purpose)
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.
Still plain old Swift (or when the itch strikes, Objective-C) and AppKit. I don’t really build for platforms other than macOS because I haven’t found toolkits that feel right elsewhere. I would do just about anything for multiplatform AppKit.
One option would be using C# + AppKit on Mac and then WinUI on Windows, while sharing the view model and model layers between platforms with something like MvvmCross.
Topping my list of GUI toolkit requirements are cross-platform and native look & feel. As far as I know, Qt still beats everything else in these areas on the desktop. It's mostly excellent.
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:
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:
I’m hopeful that toga will be good for python dev cross platform including iOS and android. I haven’t tried it yet though. https://beeware.org/project/toga/
Gpui is not on crates.io. This is a problem with Rust UI in general that they are not stable and often change API.
The only exception here is Slint which seems stable in 1.x for some years.
Are you shipping apps bundled with LÖVE or just expecting users to obtain it and drag the files onto it? I know there are some scripts out there to produce stand-alone apps, but I wish it were more straight forward or that there were a 1st party tool that did it.
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.
Last time I wrote any LÖVE games was probably more than 10 years ago, so perhaps this has been lost since then, but from what I recall creating a single executable of your game could be done by just concatenating a zip file of your game to end the of the LÖVE binary.
Does LÖVE have support for widgets/ controls (such as labels, text boxes, combo boxes, etc.) for building GUI desktop apps, or is it only for 2D graphics? I could not make that out, on a quick look just now at the homepage and the various modules listed there.
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.
Qt with QML for a somewhat embedded use case. I think it hits a really nice intersection of native speed, GPU acceleration, interfacing with C++, and ease of development.
Qt used to be what I used as well, but the licensing has become so repulsive for professional use that I now refuse to touch it now (not even for my open source side projects where this wouldn't be an issue).
Too bad the hopes from the early Nokia adoption days got smashed by MS mole Elop and the later owners of Qt.
The licensing barely changed, the only change is the scare tactics of the Qt Company. The only thing to do is not to get scared by such legally meaningless noise.
We have no issues shipping both FOSS (LGPL) and proprietary solutions using Qt without having to pay any license fee... not sure what issues you're running into.
I think it's a little too niche, and as embedded processors get more and more powerful, we'll just see the same trend of doing all UI in a browser instead
You don't need powerful microprocessor for UI. Just some sort of connection. WiFi, network, file system. Then UI can run in browser on tablet, desktop...
Rust + egui, but it's a far cry from the convenience or iteration speed of the web. Wherever possible, I build webapps instead, just because it's so much faster to get results (especially with LLMs!)
With that being said, I'd like to try the modern .NET stack sometime. Shame that the UI side of things is still largely Windows-only, and even Microsoft themselves don't know which UI framework they're using this week.
Delphi is the easiest and most integrated way of writing cross platform
UIs and it has been for a lot of years.
It might not be sexy, but highly productive.
You can download and use a community edition of Delphi for free.
The downside is insane licensing costs if you are making commercial software.
I an not sure how far Lazarus has come but I believe it to have the same
or similar abilities and if free and libre.
I use Delphi at work quite a lot. The language is great, but the Embarcadero Studio is unfit for any non-trivial project and getting worse with every new version.
Delphi was so ahead of its time (a mandatory remark)... I've used Delphi 1 to 4 then moved on to other things. Using .NET since 1.0 beta, and it still remains my favorite stack. The project I am currently building is a software infra for building E2EE applications, and it requires a little bit of everything - mobile apps for key management, desktop/cli apps/client libraries for actually encrypting data, sometimes a web based app, and a zero trust backend. Using Xamarin/MAUI for mobile apps, Blazor WASM for Web, Blazor Hybrid / MAUI / Avalonia UI for Desktop. All of the frameworks have their quirks, so it may take a bit of time to learn your patterns, build your base classes, but after that you pretty much enjoy the productivity of a modern high level language.
- What programming languages and frameworks are popular for desktop apps?
- for me - Blazor Hybrid / MAUI / Avalonia UI / WinForms
- Are there any go-to IDEs, build tools, or libraries that make development easier?
- I use MSVS 2022, VSCode for .NET, IntelliJ for $$$ at work. There are of course UI control libraries, I am using MudBlazor for Blazor WASM / Hybrid, other than that I use built-in controls that come with each framework. I try to use as little as possible of 3rd party libraries b/c my apps are security-sensitive.
- Do the above answers change if you care about code performance or efficiency (whatever that means to you)?
- in my case no, I am able to find what I need in .NET ecosystem. Modern .NET supports ahead-of-time compilation compiling to native code, and that helps to reduce start-up time which is important for Desktop / CLI. Ironically, for a long running processes, like a web service, the just-in-time compilation sometimes produces code running faster than ahead-of-time compilation, b/c it learns most common execution paths at runtime, and is able to recompile on the fly, optimizing for most frequent execution paths, giving a non-trivial performance boost in some cases
- Is native desktop app development still viable as a career, or are most greenfield projects shifting to web-based alternatives
- depends on the app/use case. For my project, desktop is the first class citizen, but I am building E2EE apps, i.e. end-to-end-encryption apps, aka client-side encryption, and native / Desktop / CLI is a better fit for E2EE in most of the cases compared to web apps. For those Web apps that I have it is still E2EE but in the browser (still client side encryption)
Turbo C++/Borland C++ (with Object Windows library) was the best C++ IDE on MS-DOS in the early/mid 90's. All their tools were excellent. They were leading the industry in the usage of C++ on PCs and should have built upon that advantage; but then they lost it all to MS Visual C++ (with MFC library) when Windows came along.
It was one of the earliest and best textbook case of management screwing up a technical company.
I went to a talk by MS Visual C++ product manager, years ago. IIRC he said that Borland did all sorts of really difficult stuff to make their C++ compiler better and more standard compliant, whereas MS concentrated on easier and more marketable stuff like wizards.
To my dismay, my company uses JavaScript, HTML, CSS with a custom Chromium-based web browser installed on your PC. The performance is shit: GUI performance that should take milliseconds takes seconds to render with constant pinging of corporate servers and user activity logging. Development mostly done in IntelliJ or VS Code.
Those problems aren't JS/HTML/CSS problems, they are bad programmer problems. If the performance of your webapp sucks, then you did something wrong somewhere, but it wasn't choosing JS/HTML/CSS that caused the problem. There are plenty of very performant web applications.
At that point, what's the point in maintaining your own browser fork instead of just telling users to point their own (Blink, even) browser at localhost?
I’m using JUCE C++ which is very popular for audio software. But it can be used for more general purpose applications. The latest version has some kind of HTML based UI system but I’ve not migrated yet.
I’ve tried it in the latest plug-in I’ve worked on - it’s just a webview embedded in the window. It’s really great for faster development of more complex plug-ins but there’s some downsides when it comes to performance and integration with the DAW (I had to do some nasty hacks to get handle mouse clicks and keypresses properly).
I think it would be possible to have those advantages in JUCE/C++ without a webview tho. Maybe just moving to a declarative UI approach for positioning and styles with the ability to refresh (something like litehtml could be handy for that)?
I’m using this too. You get all the JUCE stuff with a web frontend, and it uses the system web view so no huge Chromium binary. The downside is there’s no OS bindings out of the box, you have to provide everything via your native bridge.
Tauri seems interesting. It combines a Rust core with the platform-native browser engine for presentation. Of course a potential downside is rendering incompatibilities between engines/platforms.
- Some mentions of Lazarus and FreePascal (so basically a cross-platform open source Delphi equivalent). And I'd agree with them.
- For C# I like AOT assemblies using Uno or Avalonia.
- For Go I like TCell (which does cross-platform console mode text GUIs [with cursor positioning, colours, mouse, etc]).
- If you're doing vibe coding I find it tends to work best with Electron.
- The big omission here is anything Python; I don't do desktop apps in Python so can offer nothing. Same for Ruby, though Hotwire Native looks interesting.
wxPython and PyQt are some options. PySide too. There are some other less-known ones too. I've not tried Kivy. There is also tkinter which comes built-in with Python.
IIRC, the Dropbox GUI client app was done with wxPython on both Linux and Windows.
A hearty +1 to using WinForms (as long as your desktop app targets Windows only, of course). The fact that WinForms has outlasted so many other UI toolkits is a testament to its simplicity and ease of use. I still use it in numerous personal projects, and I don't foresee Microsoft dropping support for it anytime in the near future.
I'm still using a few JScript.NET Windows forms applications I wrote over 10 years ago. Works great. jsc.exe is still on every Windows machine, and makes it easy to write Javascript and compile to .exe or even .dlls.
I'm personally aware and used few Desktop app building frameworks like Flutter, Tauri, Electron. I think you might have some luck with Electron support for LLMs since its early development and resources available. But I personally like to use Tauri recently, its backend is Rust but you can plug it in with any JS, CSS framework and develop your application.
On my projects [1][2], I use C# and Avalonia with Rider or Visual Studio. For extra performance, turn on AOT, which has the nice side-effect of making reversing your app to C# impossible.
I worked in WPF for a decade. I wouldn't go with it for a new project since it's Windows-only and doesn't support AOT.
At work we have a Blazor MAUI hybrid desktop app because it also has to run on the web. If we only needed a desktop app, I'd go with Avalonia.
I currently use Windows Forms, but I plan to use the Godot game engine in the future. Designing the GUI feels quite similar to WinForms, and I can use C++ or C# (and a bunch of other languages).
Electron. I think the hate is undeserved (at this point, they've come along way) and there are plenty of billion dollar companies running Electron apps.
Hey you can try NextBunny.co - It’s a Visual UI builder that exports real Next.js code.That means if you’re building a Nextjs desktop app you can design your UI visually in our builder, export clean code, and drop it right into your project. You own the code no hidden runtimes, no lock in. And It's free to use.
I wouldn't necessarily recommend it, but I was pleasantly surprised to find out recently that cross-platform TUIs are trivial in Go with packages like tview. [1]
For Windows only (because that's the most common platform in the world): C# and .Net. The UI is mostly either WPF or WindowsForms.
For Mac only: new apps use Swift, legacy ones use Objective-C, both with AppKit.
Linux only: these are quite rare and there is a broad mix of them: C++, Java, etc.
Cross-platform: C++ with Qt seems to be the standard. Go and Rust seem to be rising. Rising UI libraries are Tauri, Slint and Iced. There are other alternatives like cross-platform .Net, Java or Flutter. But they don't look very solid and widely adopted.
Then there are other UI frameworks for some specific use cases (games, scientific applications, etc).
This thread shows for itself the state of desktop app dev in 2025 :) The question was about "toolchains". For me, the word "toolchain" in the context of programming means compiler and linker stuff for some programming language(s) (e.g. LLVM toolchain, or MSVC++), not e.g. Chromium/HTML5 web environment, C#/Java managed languages, Flutter/Electron bloats, or Qt all-batteries-included library etc.
just stumbled across your post. i built two desktop apps a few weeks ago. well, vibe coded them. and i didnt think about it much. i used claude code and ask what lang/framework i should pick. "we" ended up with c/gtk. and this worked nicely for my cases. a pomodoro timer with ticking systray icon and screen darkening. and a vim-harpoon-style fzf window switcher with command mode.
but now i'm reading through all the comments here and am eager to try all these options. let's see how claude is doing with these.. :]
AI agents are making it really easy to develop in C/C++ and produce rock-solid memory safe code. Really looking forward to a new renaissance for desktop programming!
I support Java software using a Swing GUI. It's fairly performant, but requires a fair bit of boilerplate for setting up the GUI and can take longer than typical web development.
I'm retired now so I don't care what the market thinks. For applications I expect to be run locally by myself and/or a few other geeks, I use good old Tcl/Tk. For things where I'm aiming for a wider distribution I use plain html & javascript (no frameworks).
I have used Xojo before and it is great. It is REALbasic rebranded and has been around for three decades. I used it years ago to write a LIMS interface (pre-Web 2.0). You can download the IDE and use it for free for Linux and Raspberry Pi projects. https://xojo.com
Electron gets a lot of hate, but the web is the future and either a PWA or electron app are the easiest cross-platform way to deliver "installable" software.
Interesting, I think this is a good choice too if you want cross platform and to avoid potential future geopolitical issues that may crop up given the way the world is going.
If you don't mind me asking: Why not use a cross-platform GUI kit? I feel like using something OS-specific is setting up barriers that we don't need to do anymore.
Now that Chromium supports the File System Access API on desktop and mobile, I am building every software I need as HTML+JS+CSS.
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.
What about FireFox, does/will it support file system access? I'm not an expert, just thinking this way and don't like Chromium. The idea is to use light web server in application + browser with JS. This makes it easier and more convenient as it can naturally run remote, on microprocessor. Also LLMs are good at generating such UIs.
This is how I develop all the software that I don't work on professionally. I have a variety of small web servers with various capabilities that I use. The latest is Copy Party, which I learned about from HN a couple of weeks ago. My apps are then single files that know how to write modified copies of themselves back to the server. The server is dumb, it doesn't really know that it's anything other than just a file upload. I then use SyncThing to replicate that folder structure across all my devices so I have offline access by default.
Copyparty[0] is amazing. I've noticed copyparty+webdav is a lot faster for browsing my NAS than smb or nfs from macOS.
I've been meaning to build a gallery application (or simple web page) that can browse pictures from a copyparty instance and sort/organise them with an UI fit for my purpose.
Any pointers how I could make one that self-saves to copyparty?
[0] https://github.com/9001/copyparty/
Sorry for taking so long to respond...I was out on vacation!
The general strategy is to figure out what state needs to be stored in your app, and combine that into one div in the page that can be grabbed via something like innerHTML. For a gallery app that is viewing pictures on copyparty, that will be the metadata, like the URL of the image, the tags you want to apply and/or what category it is in, the index within the album, the date info, etc.
Then, when your page loads, you can load all that and reason about how to arrange your photos, what to display, etc. Once that's done, the URLs can be swapped in to generate the appropriate view. I would give some thought to how to leverage WebDAV to create a directory that can store e.g. thumbnails. Copyparty does that itself, but your app should likely have its own disk-based cache accessible from a folder served by Copyparty.
The self-save part is mostly creating a something like a clone function that knows how to clone the static parts and inject updated sections for the data. I've written a little about about how to do this in my post years ago about a TiddlyWiki saver written for jart's Cosmopolitan.
https://rpdillon.net/redbean-tiddlywiki-saver.html
I've iterated on it quite a bit since then, and haven't updated my site accordingly. It's probably worth documenting the progress I've made since.
https://caniuse.com/native-filesystem-api
Looks like Firefox does not support it currently.
It's even worse than that. If you click on the resources section, you can see that Mozilla considers the proposal harmful[1]. They say there's a subset of features that they may consider. Safari seems to be in the same boat, but I can't find an official standards position.
[1] https://github.com/mozilla/standards-positions/issues/154
I have been evaluating and testing the Filesystem API for a local first web based CAD editor and having direct r/w access to the filesystem is a great way to make such a thing, couple with the FilesystemObserver[1] API this makes building proper editors on the web a breeze.
In place of this, Firefox recommends using the origin private file system (OPFS)[2] which is basically a sandboxed filesystem that the users cannot access. Though I agree from a security perspective it kind of makes sense (not particularly for my usecase), but it removes the ability for the user to have realtime changes on local files.
An example of this is using the web based tool as an intermediary step or a processing step in a bigger pipeline; I save it using my web tool and then native applications automatically handle file updates. This just creates an extra step for Firefox/Safari to replicate changes locally by having to manually update local files.
Also neither Firefox nor Safari support showDirectoryPicker() which also creates blocks for building a web based editor.
I love Firefox and I hope they can add support for this. I have stopped caring about Safari/Webkit completely because it's hellish to try and maintain feature parity while NOT sacrificing innovation and ease of use.
[1] https://developer.mozilla.org/en-US/docs/Web/API/FileSystemO...
[2] https://developer.mozilla.org/en-US/docs/Web/API/File_System...
+1 Another bonus is that it's properly sandboxed, you only give access to the files/directories and other resources it needs.
Except you lose native document UI features. Especially frustrating in Electron "apps".
At work we use C#, .Net, and WPF. I've only used it at this company, and I can't say for sure if my dislikes are with WPF, or how our codebase is using it. Overall it's not terrible, except for being proprietary and Windows only.
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.
There are defiantly better and worse ways to use WPF. Personally I dislike it when data binding is done in XAML, because there is no compile time error if you rename a property on the C# side.
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.
> 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.
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.
Flutter is a super compelling framework (https://flutter.dev/multi-platform/desktop), but I’d live in fear of it randomly being sent to the Google graveyard.
It had layoffs in 2024. And Google has emitted a bunch of words about their support for Flutter, but hasn't taken the most obvious step towards solidifying support: guarantee a minimal spend level on Flutter dev for a decade, either internally or by donating to an external foundation. eg we will spend $x on Flutter until 2036. :shrug: So they've carefully retained the option to cut support at will. Which is their choice, but I recently wasn't comfortable starting a greenfield project in it for that reason.
Everyone says this but personally it's been fine for me in 2025. It won't land you a job or funding because people are afraid of it. But if you're going to just build tools, it works.
Sure, but pointing even a single eng team at it is a multi-million dollar investment annually. I can't do that for sdks w/o firm support or enough industry adoption that the industry can shepherd ongoing development.
We shipped a project at work with Flutter recently, specifically using it on embedded Linux, basically a touch screen smart apartment tablet/thermostat combo.
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
Which embedder did you guys end up using, Toyota or flutter-elinux
flutter-elinux -- By the Sony guys yea? We use that one!
Okay so we ended up using that too, it was really well done and documented.
But in hindsight I think flutter-pi or the Toyota one might have been a better investment. The lead engineer in Sony behind the elinux project left for Nvidia. The Toyota one uses Wayland, you can't make it directly hook into DRM. So you'd need a minimal compositor to get it running.
Flutter Pi had other issues. It required systemd as a dependency just for the event loop which we ended up having to hack out. The Sony embedded project is still being updated and active. And the code quality is much better
Ooof I had a short chat with a maintainer with one of the competing projects and they really hated on the code quality for the sony embedder.
I just didn't like the lack of control you got with the sony embedder, you couldn't specify which display you wanted to show on when using DRM and it was real pain to get it working.
I didn't know about the systemd dependency, but we actually needed it though even though we used Sony because of our dependency on DBus.
does it support webview?
Unknown, we don’t use web views at all in our app but I assume it’s possible with some work to get the plugin working
> I’d live in fear of it randomly being sent to the Google graveyard.
Knowing Google, this happening is almost a guarantee. You should consider moving to another framework with a longer shelf life.
Go is still going strong after 15 years. Dart, the language of Flutter, is 13 years old.
I do have to wonder if decoupling dart from flutter would boost flutter. Flutter and typescript, dart is fine but you know most people have another major language with tooling and what not
I am primarily an Elixir engineer so Dart was the exact opposite of what I’m usually working in, that said it’s not hard to get up to speed on Dart conventions- and other team members were able to get up and contributing in a couple weeks
Lazarus is the open source equivalent to Delphi these days, and for the most part it's awesome. (The documentation, on the other hand... just isn't fit for purpose)
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.
Lazarus currently works very poorly on the Mac, alas. Everything from installing to actually building a simple form was broken in various ways.
Yes, Lazarus + FreePascal is great and imo preferable to Embarcadero Delphi nowadays.
I've found that you can mostly just use old Delphi books as a starting point for learning Lazarus.
Still plain old Swift (or when the itch strikes, Objective-C) and AppKit. I don’t really build for platforms other than macOS because I haven’t found toolkits that feel right elsewhere. I would do just about anything for multiplatform AppKit.
AppKit is indeed great. Pity Apple doesn’t give it much love anymore.
I've built stuff in Qt before and it's great, but it's super expensive if you want to use it for proprietary work.
One option would be using C# + AppKit on Mac and then WinUI on Windows, while sharing the view model and model layers between platforms with something like MvvmCross.
Here's my attempt from 2021: https://github.com/QotoQot/Octospace
Topping my list of GUI toolkit requirements are cross-platform and native look & feel. As far as I know, Qt still beats everything else in these areas on the desktop. It's mostly excellent.
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/
I’m hopeful that toga will be good for python dev cross platform including iOS and android. I haven’t tried it yet though. https://beeware.org/project/toga/
Gpui is not on crates.io. This is a problem with Rust UI in general that they are not stable and often change API. The only exception here is Slint which seems stable in 1.x for some years.
I've been reading these threads litteraly for decades, hopping that someone would finally bring to light a better deal than Qt.
Will come back next year :-(
As someone who loved Turbo Pascal, for the past 3 years I use Lua and LÖVE.
https://akkartik.name/freewheeling
Just chiming in to say that akkartik is doing really interesting stuff and it’s worth diving deep on this site.
<3
Wow, thank you! <3
Are you shipping apps bundled with LÖVE or just expecting users to obtain it and drag the files onto it? I know there are some scripts out there to produce stand-alone apps, but I wish it were more straight forward or that there were a 1st party tool that did it.
Yeah, my install instructions are consistently:
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.
Last time I wrote any LÖVE games was probably more than 10 years ago, so perhaps this has been lost since then, but from what I recall creating a single executable of your game could be done by just concatenating a zip file of your game to end the of the LÖVE binary.
Have you looked at Free Pascal and Lazarus? It's an excellent open source and cross-platform implementation of Object Pascal and Delphi.
https://www.lazarus-ide.org/
Does LÖVE have support for widgets/ controls (such as labels, text boxes, combo boxes, etc.) for building GUI desktop apps, or is it only for 2D graphics? I could not make that out, on a quick look just now at the homepage and the various modules listed there.
There's a GUI library: https://github.com/flamendless/Slab
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.
thanks
Within game development it's Dear ImGui. https://github.com/ocornut/imgui
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#.
Qt with QML for a somewhat embedded use case. I think it hits a really nice intersection of native speed, GPU acceleration, interfacing with C++, and ease of development.
I wouldn't really recommend a career out of it.
Qt used to be what I used as well, but the licensing has become so repulsive for professional use that I now refuse to touch it now (not even for my open source side projects where this wouldn't be an issue).
Too bad the hopes from the early Nokia adoption days got smashed by MS mole Elop and the later owners of Qt.
Yeah, it's quite sad to see Qt on the N9 and, now, on SailfishOS.
We were robbed of a future with lightweight and responsive native apps. Android pales in comparison.
I have a small business license which I use for developing 3 commercial application. It is ~$1000 per year and the licensing seems quite reasonable.
why are you paying for a license? are there non-LGPL features you're using?
Yes. I use the charts. But also my business is built on Qt, so it feels right to support them financially.
The licensing barely changed, the only change is the scare tactics of the Qt Company. The only thing to do is not to get scared by such legally meaningless noise.
We have no issues shipping both FOSS (LGPL) and proprietary solutions using Qt without having to pay any license fee... not sure what issues you're running into.
> using Qt without having to pay any license fee...
Would you mind elaborating which Qt editions, linking etc. you use?
We have been using the LGPL opensource version since the 4.x days including the latest 6.x, both static and dynamic linking.
That's good to know. I'll have to look up those licenses another time.
> I wouldn't really recommend a career out of it.
Care to say why? I ask because that's what I use at work: C++ and Qt
Yes, I'd prefer Rust and Slint/Tauri.
But like a prostitute I don't do what I love, I do what pays the bills.
> Yes, I'd prefer Rust and Slint/Tauri.
Ah, you like masochism I see. I bet you use it for your personal projects, but not at all for commercial projects. It’s just not there yet.
Talking about Slint or Tauri? AFAICT they aren't complements but alternatives.
I think it's a little too niche, and as embedded processors get more and more powerful, we'll just see the same trend of doing all UI in a browser instead
I do like working in it, though!
You don't need powerful microprocessor for UI. Just some sort of connection. WiFi, network, file system. Then UI can run in browser on tablet, desktop...
Rust + egui, but it's a far cry from the convenience or iteration speed of the web. Wherever possible, I build webapps instead, just because it's so much faster to get results (especially with LLMs!)
With that being said, I'd like to try the modern .NET stack sometime. Shame that the UI side of things is still largely Windows-only, and even Microsoft themselves don't know which UI framework they're using this week.
See Avalonia, cross-platform .net core.
Delphi is the easiest and most integrated way of writing cross platform UIs and it has been for a lot of years. It might not be sexy, but highly productive.
You can download and use a community edition of Delphi for free. The downside is insane licensing costs if you are making commercial software.
I an not sure how far Lazarus has come but I believe it to have the same or similar abilities and if free and libre.
I use Delphi at work quite a lot. The language is great, but the Embarcadero Studio is unfit for any non-trivial project and getting worse with every new version.
Nowadays I definitely prefer Lazarus.
Delphi was so ahead of its time (a mandatory remark)... I've used Delphi 1 to 4 then moved on to other things. Using .NET since 1.0 beta, and it still remains my favorite stack. The project I am currently building is a software infra for building E2EE applications, and it requires a little bit of everything - mobile apps for key management, desktop/cli apps/client libraries for actually encrypting data, sometimes a web based app, and a zero trust backend. Using Xamarin/MAUI for mobile apps, Blazor WASM for Web, Blazor Hybrid / MAUI / Avalonia UI for Desktop. All of the frameworks have their quirks, so it may take a bit of time to learn your patterns, build your base classes, but after that you pretty much enjoy the productivity of a modern high level language.
- What programming languages and frameworks are popular for desktop apps? - for me - Blazor Hybrid / MAUI / Avalonia UI / WinForms
- Are there any go-to IDEs, build tools, or libraries that make development easier? - I use MSVS 2022, VSCode for .NET, IntelliJ for $$$ at work. There are of course UI control libraries, I am using MudBlazor for Blazor WASM / Hybrid, other than that I use built-in controls that come with each framework. I try to use as little as possible of 3rd party libraries b/c my apps are security-sensitive.
- Do the above answers change if you care about code performance or efficiency (whatever that means to you)? - in my case no, I am able to find what I need in .NET ecosystem. Modern .NET supports ahead-of-time compilation compiling to native code, and that helps to reduce start-up time which is important for Desktop / CLI. Ironically, for a long running processes, like a web service, the just-in-time compilation sometimes produces code running faster than ahead-of-time compilation, b/c it learns most common execution paths at runtime, and is able to recompile on the fly, optimizing for most frequent execution paths, giving a non-trivial performance boost in some cases
- Is native desktop app development still viable as a career, or are most greenfield projects shifting to web-based alternatives - depends on the app/use case. For my project, desktop is the first class citizen, but I am building E2EE apps, i.e. end-to-end-encryption apps, aka client-side encryption, and native / Desktop / CLI is a better fit for E2EE in most of the cases compared to web apps. For those Web apps that I have it is still E2EE but in the browser (still client side encryption)
>Delphi was so ahead of its time
Borland had an amazing knack of snatching defeat from the jaws of victory.
Turbo C++/Borland C++ (with Object Windows library) was the best C++ IDE on MS-DOS in the early/mid 90's. All their tools were excellent. They were leading the industry in the usage of C++ on PCs and should have built upon that advantage; but then they lost it all to MS Visual C++ (with MFC library) when Windows came along.
It was one of the earliest and best textbook case of management screwing up a technical company.
I went to a talk by MS Visual C++ product manager, years ago. IIRC he said that Borland did all sorts of really difficult stuff to make their C++ compiler better and more standard compliant, whereas MS concentrated on easier and more marketable stuff like wizards.
To my dismay, my company uses JavaScript, HTML, CSS with a custom Chromium-based web browser installed on your PC. The performance is shit: GUI performance that should take milliseconds takes seconds to render with constant pinging of corporate servers and user activity logging. Development mostly done in IntelliJ or VS Code.
Those problems aren't JS/HTML/CSS problems, they are bad programmer problems. If the performance of your webapp sucks, then you did something wrong somewhere, but it wasn't choosing JS/HTML/CSS that caused the problem. There are plenty of very performant web applications.
At that point, what's the point in maintaining your own browser fork instead of just telling users to point their own (Blink, even) browser at localhost?
Control of the chrome around the browser page I guess.
I’m using JUCE C++ which is very popular for audio software. But it can be used for more general purpose applications. The latest version has some kind of HTML based UI system but I’ve not migrated yet.
I’ve tried it in the latest plug-in I’ve worked on - it’s just a webview embedded in the window. It’s really great for faster development of more complex plug-ins but there’s some downsides when it comes to performance and integration with the DAW (I had to do some nasty hacks to get handle mouse clicks and keypresses properly).
I think it would be possible to have those advantages in JUCE/C++ without a webview tho. Maybe just moving to a declarative UI approach for positioning and styles with the ability to refresh (something like litehtml could be handy for that)?
I’m using this too. You get all the JUCE stuff with a web frontend, and it uses the system web view so no huge Chromium binary. The downside is there’s no OS bindings out of the box, you have to provide everything via your native bridge.
Tauri seems interesting. It combines a Rust core with the platform-native browser engine for presentation. Of course a potential downside is rendering incompatibilities between engines/platforms.
IME Tauri performance sucks on Linux so thats something worth keeping in mind if you go that route (https://github.com/tauri-apps/tauri/issues/3988)
- Some mentions of Lazarus and FreePascal (so basically a cross-platform open source Delphi equivalent). And I'd agree with them.
- For C# I like AOT assemblies using Uno or Avalonia.
- For Go I like TCell (which does cross-platform console mode text GUIs [with cursor positioning, colours, mouse, etc]).
- If you're doing vibe coding I find it tends to work best with Electron.
- The big omission here is anything Python; I don't do desktop apps in Python so can offer nothing. Same for Ruby, though Hotwire Native looks interesting.
>The big omission here is anything Python
wxPython and PyQt are some options. PySide too. There are some other less-known ones too. I've not tried Kivy. There is also tkinter which comes built-in with Python.
IIRC, the Dropbox GUI client app was done with wxPython on both Linux and Windows.
Slint-ui with rust (they have bindings for cpp, Python and js).
Quite good, I've been building this Pomodoro:
https://github.com/reciperium/temporis/
I've also used nix to build the packages when possible.
One of the things I like about slint is that it has native components. They also have experimental support for Android and iOS.
The language is quite simple as well. Though it could benefit from something like flex
Windows Forms are alive and well.
Still supported in latest .net versions.
A hearty +1 to using WinForms (as long as your desktop app targets Windows only, of course). The fact that WinForms has outlasted so many other UI toolkits is a testament to its simplicity and ease of use. I still use it in numerous personal projects, and I don't foresee Microsoft dropping support for it anytime in the near future.
I'm still using a few JScript.NET Windows forms applications I wrote over 10 years ago. Works great. jsc.exe is still on every Windows machine, and makes it easy to write Javascript and compile to .exe or even .dlls.
Avalonia is my go-to on .net. It's not too far from WPF.
Same. Claude is good at it. Plenty of training material and the way we design Windows Forms apps hasn't changed in 20+ years.
I'm personally aware and used few Desktop app building frameworks like Flutter, Tauri, Electron. I think you might have some luck with Electron support for LLMs since its early development and resources available. But I personally like to use Tauri recently, its backend is Rust but you can plug it in with any JS, CSS framework and develop your application.
For Go, I've been using Wails [1] and Fyne [2]. The former uses a web view for the UI, the latter is Go only.
[1] https://github.com/wailsapp/wails
[2] https://github.com/fyne-io/fyne
On my projects [1][2], I use C# and Avalonia with Rider or Visual Studio. For extra performance, turn on AOT, which has the nice side-effect of making reversing your app to C# impossible.
I worked in WPF for a decade. I wouldn't go with it for a new project since it's Windows-only and doesn't support AOT.
At work we have a Blazor MAUI hybrid desktop app because it also has to run on the web. If we only needed a desktop app, I'd go with Avalonia.
[1] https://linklever.net/ [2] https://github.com/endurabyte/FitEdit
I currently use Windows Forms, but I plan to use the Godot game engine in the future. Designing the GUI feels quite similar to WinForms, and I can use C++ or C# (and a bunch of other languages).
Electron. I think the hate is undeserved (at this point, they've come along way) and there are plenty of billion dollar companies running Electron apps.
Hey you can try NextBunny.co - It’s a Visual UI builder that exports real Next.js code.That means if you’re building a Nextjs desktop app you can design your UI visually in our builder, export clean code, and drop it right into your project. You own the code no hidden runtimes, no lock in. And It's free to use.
Avalonia - https://avaloniaui.net/
I use Qt + QML (with C++) for my note-taking app[1] and my Ollama client[2] and it’s absolutely great.
[1] https://www.get-notes.com/
[2] https://www.get-vox.com/
C#, dotnet core and Avalonia. Its awesome
.NET and whatever gui framework is appropriate (WPF, Avalonia, WinForms).
Rust + Egui for special cases like DAW plugins.
For both iOS and Android app: - Xcode - SwiftUI - Supabase - Claude CLI - Skip.tools (converts SwiftUI to native Katlin code)
Been developing mobile apps for over 15 years. This is by far the best stack for developing mobile apps. Speed, total control, native UI's. Love it.
Is there a cross plaform desktop option for that?
I wouldn't necessarily recommend it, but I was pleasantly surprised to find out recently that cross-platform TUIs are trivial in Go with packages like tview. [1]
[1]: https://til.andrew-quinn.me/posts/cross-platform-tuis-are-ea...
For Windows only (because that's the most common platform in the world): C# and .Net. The UI is mostly either WPF or WindowsForms.
For Mac only: new apps use Swift, legacy ones use Objective-C, both with AppKit.
Linux only: these are quite rare and there is a broad mix of them: C++, Java, etc.
Cross-platform: C++ with Qt seems to be the standard. Go and Rust seem to be rising. Rising UI libraries are Tauri, Slint and Iced. There are other alternatives like cross-platform .Net, Java or Flutter. But they don't look very solid and widely adopted.
Then there are other UI frameworks for some specific use cases (games, scientific applications, etc).
This thread shows for itself the state of desktop app dev in 2025 :) The question was about "toolchains". For me, the word "toolchain" in the context of programming means compiler and linker stuff for some programming language(s) (e.g. LLVM toolchain, or MSVC++), not e.g. Chromium/HTML5 web environment, C#/Java managed languages, Flutter/Electron bloats, or Qt all-batteries-included library etc.
just stumbled across your post. i built two desktop apps a few weeks ago. well, vibe coded them. and i didnt think about it much. i used claude code and ask what lang/framework i should pick. "we" ended up with c/gtk. and this worked nicely for my cases. a pomodoro timer with ticking systray icon and screen darkening. and a vim-harpoon-style fzf window switcher with command mode.
but now i'm reading through all the comments here and am eager to try all these options. let's see how claude is doing with these.. :]
AI agents are making it really easy to develop in C/C++ and produce rock-solid memory safe code. Really looking forward to a new renaissance for desktop programming!
I support Java software using a Swing GUI. It's fairly performant, but requires a fair bit of boilerplate for setting up the GUI and can take longer than typical web development.
Flutter builds pretty decent desktop apps these days.
I'm retired now so I don't care what the market thinks. For applications I expect to be run locally by myself and/or a few other geeks, I use good old Tcl/Tk. For things where I'm aiming for a wider distribution I use plain html & javascript (no frameworks).
I have used Xojo before and it is great. It is REALbasic rebranded and has been around for three decades. I used it years ago to write a LIMS interface (pre-Web 2.0). You can download the IDE and use it for free for Linux and Raspberry Pi projects. https://xojo.com
Because I mainly work with python, I am using Kivy (https://kivy.org/).
Earlier I was HTMX, Jinja templates, Flask, Tailwind and little vanilla JS. It was too inelegant for my taste.
I am considering moving to either Swift, or JS/Svelete
For my own uses I do Python with PySide6, most Qt features in a bit easier environment
Electron gets a lot of hate, but the web is the future and either a PWA or electron app are the easiest cross-platform way to deliver "installable" software.
Quickshell was discussed earlier on HN today: https://news.ycombinator.com/item?id=44800048
I have been recently playing with Dioxus and I kinda like it. I too am dismayed that we are using browser to target desktop but here we are I guess.
Thanks, I wasn't aware of it.
What would you think are the pros and cons over various alternatives (like Flutter, Avalonia, Lazarus, etc.)
Thanks.
C++ and Qt.
Rust as a statically linked library where it makes sense.
Python & Gtk (& sometimes Glade)
Interesting, I think this is a good choice too if you want cross platform and to avoid potential future geopolitical issues that may crop up given the way the world is going.
To be fair I haven't had reason to care about shipping for Windows yet (though I believe it's reasonably simple), only MacOS and Linux, and no mobile.
Rust/EGUI/WGPU
Caveat: This is immediate mode, so not suitable for all applications and preferences.
Rust for backend + Qt via cxx-qt bindings.
Would consider flutter for smaller apps as I had a great experience before.
My current stack: Cocoa + Metal + imgui + CEF
Rust bindings for GTK4 on Linux are full-fledged
If you don't mind me asking: Why not use a cross-platform GUI kit? I feel like using something OS-specific is setting up barriers that we don't need to do anymore.
MFC all the way!
Zte the hack
want to hack