Tiny nitpick: Windows Forms wraps the Windows API; the function call is `CreateWindowEx`[1].

[1]: https://github.com/dotnet/winforms/blob/27e7cb2e5043780dd75e...

Maybe it's called zero native because that is how native it is.

If Tauri ever gets proper webgpu support, that'll be the Electron killer.

Considering Microsoft already doing this in win11, it's fine.

Rust has bad ergonomics. You will see that "attitude" as long as coding exists, or lifetimes are fixed in a way to allow you to omit them in contexts which are not concurrent or are embarrassingly parallelizable.

I would take Zig over Rust any time. It simply fits the way I think much much better.

And since 0.16/0.17 Zig introduced a very nice async/concurrency system that doesn't require function coloring. While async in Rust still feels strange and not well integrated.

> "I don't like this attitude"

Cool, let me know when you have a rational counterargument then, some of us have gotten fed up with Rust (especially at scale) and are very much enjoying Zig (which has no magic, which turns out to be a huge advantage at scale)

I keep coming back to this and not finding / choosing a solution. It sadly feels like people who are doing this are just going with Electron now. I'm mostly coding in Go now, so I seem to be looking for a similar solution to you.

This page has a lot of cross-platform GUI toolkits, but it focuses on C++:

https://philippegroarke.com/posts/2018/c++_ui_solutions/

I've been drawn to wxWidgets (actual native controls on each platform) or JUCE (most of the cross-platform commercial Windows/Mac/Linux audio effects I've bought are made in JUCE). But I've not had a chance to give either a proper try.

Years ago I used to all my cross-platform work with Xojo, a kind of cross-platform Visual Basic. That actually worked well for me, but then you're writing code in the Xojo Basic language, and it had some odd file formats for projects (not just raw text source files like C++ / Go would give me). Once LLMs hit I felt I probably needed to move on from Xojo to something less proprietary: https://www.xojo.com/

The last one I did was using Fyne in Go, which is quite cross platform but its software drawn not native. Its targeting phones as well so its cross compatibility is very good but at the cost of giving you the full complexity of desktop applications, it does not have a highly capable table view for example. Since its written in Go this is what you will develop in.

Otherwise I think its QT and GTK on C/C++ as the other option across the desktop operating systems, neither is native on anything but Linux but they also look OK but I think a lot of people would rather avoid C nowadays for application development.

I'm actually working on that - it's called Hypen - (hypen.space).

You can build your core in Go or any other supported language, and write the UI in the Hypen DSL.

While desktop is still in the works and should be out in the next week or two, currently the alpha supports Native iOS, Android, Web and Web Canvas, and just like mobile, the Desktop will be _real_ native.

I've not used it myself, but I've heard good things about Wails.

https://wails.io/

if typography is critical for you, nothing has better support for it than the web platform

Only reasonable way is shared core with thin UI layer on top. For Rust there is Crux, don’t know for other languages. Everything else is just compromise, like all Flutter apps I know on iOS are just atrocious.

Easy: the problem with memory is not the WebView nor is it displaying HTML using that WebView. The problem is the layers of layers of JavaScript (frameworks) running in that WebView when using Electron or the like.

I am working on something similar, HTMXNative as part of a bigger idea called interscri.pt that can use either WebView or native for rendering and the difference in memory consumption is somewhere between minimal (or even undetectable) and modest.

From a baseline that's also modest by current (native) standards.

Using the system webview theoretically saves memory. Though it's still not great.

Cause they all share one webview. Electron apps each run their own version of chromium

Well, yes, it's zero-native (as in 0% native).

hence the "zero" in the name /s

Unfortunately, all the native "system" GUI frameworks are all terrible in their own unique ways.

Unless you mean drawing the gui directly to a graphics surface, which often results in even poor accessibility and system integration unless the developer cares a lot about that and puts a lot of effort into it.