I build software in a variety of mediums. Most commonly, I'd say I work on distributed backend applications but I've also maintained a lot of SaaS in both a frontend and backend capacity. No software medium, however, touches the joy my favorite medium brings me: desktop.
Desktop software is getting a bit of a revival after a long dearth. For many years software companies would immediately turn to multi-tenant software as a service (SaaS) web-based architectures to support their products. The thinking goes that SaaS is just a much simpler and easier to drive model than other mediums. With SaaS you don't have to worry about issuing licenses and having them get cracked, updates can be rolled out quickly and precisely across tenants or by tenant, and there's historically been plenty of compute to meet the insatiable needs of your customers should your growth chart turn into a hockey stick.
The biggest challenge was making unique applications on the desktop that also ran well. It's a similar challenge that mobile development faces. Companies want branded, unique applications but an OS wants uniformity, API access control, and a host of other concerns that the web simply doesn't concern itself with.
For a long time, the dominant answer was a framework called QT, which took an opinionated approach to building desktop interfaces. Tesla's infotainment is written in QT. QT, however, does not have native interfaces outside of select programming languages, so if you're writing in Rust or Go you'd have to rely on or write bindings to make use of it. Those bindings can be troublesome to work around and often lead to a very negative developer experience and a much longer development timeline.
Electron started to flip that script. The browser is the API on the web and its interface and access are commonly understood — Electron extended that to the desktop. Of course, Electron comes with some notable drawbacks; chief among them is how ridiculous the resource requirements are due to lugging around a shallow copy of the Chromium browser. Since then, projects like Tauri and Wails have taken advantage of built-in browsers to each OS and attempts at the operating system level to standardize capabilities amongst each other. There are still significant differences but that gap keeps closing over time.
The first time I touched Wails was years ago when it was, I believe, pre v1.0.0; it's now at v3.0.0. What Wails does is provide a way for a Go backend to talk to a web technology frontend. Historically this was achieved through what the Wails project maintainers called a "bridge" API that closely resembled RPCs. The concept is the same in Wails v3, however, the API has become far more robust. For instance, Wails now satisfies a zero-copy API so that resource utilization is not made multiplicative simply by virtue of communicating. It supports a rich type system, error handling, and several modes of synchronous and asynchronous communication. You can read all about it in the Wails documentation.
What Wails solved for me recently in Cascade Chat is in-app updates. I'm rapidly working on this client and I'd like to share it with people, but I had to be honest with myself that I've been actively learning about IRCv3. I'm making mistakes, learning, correcting them, and I need a fast loop to updating my users the way I have in web software. For that, Wails developed in-app updates.
In-app updates are a first-class feature in Wails that enable you to use GitHub Releases, keygen.sh, Sparkle AppCast, and custom update channel providers — including multiple simultaneously. What this results in is the ability for your app to prompt users to update the application in a straightforward workflow that reuses the OS permissions granted at installation. There's no "resetup" process and no need to click through a wizard. It just intuitively works.
With the introduction of in-app updates, Wails caps off a feature set that began with making web technologies reliably usable for desktop development — at a fraction of the resource cost of competitors. I think the answer is yes. I see Wails and Tauri leading a generation of connected software on the desktop that can leverage client-side compute and OS integration the way web apps never could.