Except WinForms, spectacular for Windows-only utility GUIs.

No kidding - kind of wild that winforms is still kind of a gold standard experience today! I actually liked VB Forms - lots of easy rapid application development was possible.

WPF as well

I like WPF and I code with it regularly, but the drag and drop UI builder was the worst aspect of WPF and generated terrible Xaml that was almost impossible to maintain.

Delphi was the best RAD tool though. It was native code, not a weird interpreted or jitted app. It could also build to a single exe file. VB struggled with an unwieldy engine for most of its life.

> spectacular

Not exactly the word I'd use, since it really hasn't changed since VB4, but it's definitely reliable and stable.

WinForms came way after VB4 and it was a .Net only technology.

IIRC, because of Wine, Mono has enough of WinForms to make a few things work. But who the hell wants to distribute an application with a Wine runtime?

I was going to suggest the same, just use WinForms. It's basically feature complete, and it's going to be the last UI framework Microsoft is going to yank out from beneath you.

As wrong as it feels to have to use Electron for a desktop app, it really is the safest approach for most applications.

Qt also seems to be a good option, though there are licensing considerations for commercial applications.

I’m excited for various upcoming Rust options as well, but right now Electron is the battle tested option.

I am curious though about Avalonia. I’ve heard good things, but it’s definitely a smaller player compared to Electron. I’d most likely choose it over Microsoft’s first party frameworks.

> it really is the safest approach for most applications.

It's also the option which gives your users by far the worst experience. Not worth it at all, imo.

Not really. The downsides are mostly overblown.

Plenty of category leading applications like Discord, VSCode, Slack, Figma, etc. use it quite successfully.

All of those are examples of overbloated, slow, horrible user experience apps.

Does their market share back up your take of them as horrible apps?

Are there QT or GTK competitors crushing them?

I always hear how terrible electron apps are, but the companies picking electron seem to get traction QT or other apps don't and seem to have a good cross platform story as well.

Users will happily deal with a suboptimal experience as long as there are other things attracting them to the product. That's why Microsoft can do whatever it wants with Windows without worrying their users will run off somewhere else. So if you care more about people than businesses, maybe it shouldn't be an excuse to pick "better dev experience" over the user's.

They said horrible user experience apps, not horrible apps. You can still deliver an app with a horrible user experience and build a profitable business. Ever done an expense report?

Companies aren't picking Electron due to inherent shortcomings in other platforms, they're picking it because it's easier (and cheaper) to find JavaScript devs who can get up to speed with it quickly.

Discord, VS Code, and Figma are all apps that individuals choose and are well liked despite many alternatives. Slack too I think, though I don’t have experience with it.

Your comment applies to Teams and I’m sure other electron apps. But the sweeping generalization that electron apps have terrible user experiences is pretty obviously incorrect.

Beware with that logic. You notice successful electron apps because of how bloated they are. I suspect you use many Qt apps without even noticing.

One that comes to mind that I use daily and noticed only recently that it was implemented in Qt is the telegram desktop app.

They work great for me.

Oh yes, the great old "works for me". On a yesterday's supercomputer, I presume? I live in a "developing" (have doubts it's really developing) country, most people are running laptops with no more than 8 GiB of RAM (sometimes it's 4 or less), and all this Electron nonsense is running like molasses, especially if you're trying to use a computer like a proper computer and do multitasking.

And most of the world is like that, very few of us (speaking globally) have $2k to drop on a new supercomputer every few years to run our chat applications.

Hey, I found CEO of Discord

All of those I avoid using due to their slowness. I can notice text-input lag in vscode ffs!

> Qt also seems to be a good option

I think Qt really is 'just' missing more language bindings, and a better hot reload story for more people to use it. Lots of devs (specially Free Software devs) would prefer to use native toolkits, if the prototyping experience was similar to how Vite is for web frontend stuff, I think Qt would be used a lot more.

They are building more language bindings to back QML frontends

https://www.qt.io/qt-bridges

Thanks for sharing. I hope that initiative goes well. And again, integration with whatever solution the language has for hot reloading is a must these days for UI development.

For what value of “safest”?

>As wrong as it feels to have to use Electron for a desktop app, it really is the safest approach for most applications.

> Qt also seems to be a good option, though there are licensing considerations for commercial applications.

you need to respect the LGPL with Qt. You also need to with Electron which uses Chromium which is LGPL.

Tauri is pretty awesome. Rust backend, WebView front end. Nothing uses native desktop elements of course.

To be fair, there is no practical way to write native desktop applications using stylistically consistent UI elements AND have it be portable AND in a language that you enjoy using.

As far as I can tell, Windows 11 doesn't even have a toolkit with platform UI elements.

GTK on Gnome is pretty okay and GTK-rs is not dissimilar to React. Who know what MacOS uses but something something Swift XCode.

But I agree, just use web technologies. Write once, ship everywhere (and hum loudly when people complain about poor performance - joking, it's the vendors' fault we have to use web technologies).

> As far as I can tell, Windows 11 doesn't even have a toolkit with platform UI elements.

They do, it's called WinUI 3. It's barely used for all of the aforementioned.

I tried this. Their examples don't even compile lol

> Rust backend, WebView front end.

I don't know much about it but it seems like a weird combination. If you want high performance and low memory usage, you don't want HTML, if you want fast code writing, you don't want Rust.

I could see a case where the core logic needs to be performant, but the UI does not. The front end could be some menus, displaying (not a giant amount of) data, and a progress bar, while the back end does heavy computing.

And furthermore, if you want fast code writing, you write in the language you already know. For some people, that is Rust.

A very reasonable combination:

- HTML is the main way of designing interfaces (whether we like it or not)

- Rust is the main language promoted by intelligence agencies with multi-billion dollar budgets because it is laced with their backdoors (whether we like it or not)

There's Wails for Go backend and webview frontend; https://github.com/wailsapp/wails

I don't believe you generally end up writing a lot of Rust with something like Tauri. It is mostly web dev. While it is true that browser based UIs are slower than native, it isn't clear that .NET based UIs would be any faster while being very niche.

Use the slower but easier to write languages for front end is the norm for complex apps. Many apps that passed the trial of time are like that.

Blender: frontend Python, backend C++.

Houdini: frontend Python(PyQt), backend C(presumably)

Sim City: frontend JavaScript, backend C++

The reason is very simple: frontend is more error tolerant, but less resistant to the product designer's whims (or the users' desire to customize.)

> Blender: frontend Python, backend C++.

blender's frontend is pretty much exclusively C++? https://github.com/blender/blender/tree/main/source/blender/...

> Houdini: frontend Python(PyQt),

I would be infinitely surprised if Houdini's frontend wasn't also a majority C++. Likewise consider large apps such as Ardour, Krita, etc.

In my experience with Tauri, it's pretty good on Windows, but not so much on other platforms, especially Linux. The decision to target different browser engines on each operating system means you still have to deal with a bunch of different OS-specific bugs.

For Windows you're dealing with Edge (so Chromium), on macOS you have Safari, and on Linux you have WebKitGTK. WebKitGTK has honestly abysmal performance, and you're missing a lot of modern standards.

The Tauri devs are looking at bundling a Chromium browser with it to deal with that, but that's still some time off, and leads to the same issue Electron has, where you have large bloated applications.

https://github.com/tauri-apps/wry/issues/1064

So you've never used WinForms, WPF and MVC

MVC is not .NET of course.

You are right that WinForms and MVC have been around forever. However, Microsoft has continuously told devs that they are the past. So, you would be forgiven for expecting them to go away.

WinUI is the current official desktop paradigm and it is basically UWP from an API point of view. So the idea that UWP went away is not 100% accurate either.

Microsoft does not really abandon their UI tech like people say they do. But look how many different frameworks they have.

All of the above is Windows desktop only. There are a completely different set of UI technologies for the web.

UNO Platform (Open Source) allows you to use the WinUI API to target almost anything.

.NET MAUI is the official "cross platform" UI tech from Microsoft. It is what you use to target iOS and Android. As a bonus, you can target macOS and Windows too. On Windows, it uses WinUI. You will notice that the Linux desktop is missing from that list.

Here comes Avalonia to build MAUI on top of the Avalonia framework. This adds Linux and WASM to the list of platforms that MAUI will run on. Adding Linux is awesome. A lot of people have wanted that and it really completes the MAUI cross-platform story.

Adding WASM is neat but MAUI was never meant to target the web. If you use it for that, it is literally just the modern version of Silverlight. But Microsoft did not design it for that at all. It is just a back-end that Avalonia supports.

> MVC is not .NET of course.

https://en.wikipedia.org/wiki/ASP.NET_MVC

I feel like they're both talking about MFC instead..

MVC is a design pattern, ASP.NET MVC is a framework that used MVC as its go to pattern. But MVC is not in any way only ASP.NET MVC. There are plenty of other UI frameworks that use MVC and the Wikipedia article lists a lot of them for example: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93con...

Blazor is pretty great. It is mature at this point and MS is using it internally more and more. Trying to go back to something like React makes me shudder. It's not perfect, but it's better than many alternatives.

I agree. For Blazor there is hope. It is standard based (web assembly, HTML, css) and it feels very intuitive particularly when compared to other spa frameworks like react. Also you can reuse all your html, css and design systems you have. Which is huge because like that it hooks up with the whole web development stack.

For as much crap as MS gets, the entire ASP.NET Core stack is an oasis.

Most of .NET is.

I sure never will write a single line of JS/TS again now that Blazor exists and is stable.

Same for me. I used to do desktop dev with MFC and WPF but these days you would be suicidal to build any app that needs to last for a few years on .NET. If totally needed, WPF is still the best bet. Otherwise I am pushing everything I can to the web.