Slightly off topic, but what is the best way to build a cross platform GUI app these days, but something with good graphics, typography, etc. I mean a beautiful app. I would prefer to have a shared core in Go, and then something around it to give me the GUI. I know on MacOS it is straightforward to build something beautifully looking with their native Swift toolkit, but not sure on Linux and Windows. Is it better to just use a web view, or perhaps Flutter?
I have my eyes on that, looking forward to V3, maybe they manage to ship mobile support as well. That would be fantastic. For anyone that doesn't know, it's still a browser based stack.
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.
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)
"No borrow checker" id not a reason to switch to Zig, unless you have a reason that borrow checker is limiting you from developing, hence the "I don't like this attitude". Just give the reason, not the "solution"
Not to mention we're nitpicking over something that an LLM wrote.
Im not sure if people are getting the biggest problem in electron desktop apps.
Its RAM usage not the disk!!
Why are they all making the same thing in different ways?! I have never worked on an electron app where the executable size was an impediment to the business. Its always the RAM/CPU usage. If we are going to work on the same webviews like electron and others, how will this make any difference?
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.
Still, using system's native GUI should be more performant and use less memory.
I would rather see existing Zig GUI libraries using system's GUI primitives improving. With LLM GUI stuff should be simple enough and we don't need to rely on people web expertise to build desktop apps.
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.
Qt is used to develop arguably the best desktop environment on the market - KDE Plasma - as well as a miriad of serious software artifacts. It's not exactly native to MacOS and Windows, but advantages overweight the downsides.
> Use the system WebView for lightweight apps, or bundle Chromium via CEF
so basically a vibe coded Tauri in zig? I don't like calling webview dependent applications "native desktop apps".
Native desktop apps means using the OS primitives and directives to draw the UI imo; WinForms, SwiftUI, and their ilk.
Maybe it's called zero native because that is how native it is.
That was my interpretation too (no idea if it's correct though)...
"Not native" doesn't roll off the tongue quite so easily (dot com is available for a few grand). Concept is solid, an ingenious name even.
Slightly off topic, but what is the best way to build a cross platform GUI app these days, but something with good graphics, typography, etc. I mean a beautiful app. I would prefer to have a shared core in Go, and then something around it to give me the GUI. I know on MacOS it is straightforward to build something beautifully looking with their native Swift toolkit, but not sure on Linux and Windows. Is it better to just use a web view, or perhaps Flutter?
I've not used it myself, but I've heard good things about Wails.
https://wails.io/
I have my eyes on that, looking forward to V3, maybe they manage to ship mobile support as well. That would be fantastic. For anyone that doesn't know, it's still a browser based stack.
if typography is critical for you, nothing has better support for it than the web platform
I love the redefinition of "native desktop app" - a web app which uses the system web-view instead of bundling Chrome.
Considering Microsoft already doing this in win11, it's fine.
> No borrow checker. No lifetimes. No fighting the compiler for 20 minutes over a string.
I don’t like this attitude, both zig and rust have their strengths.
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)
"No borrow checker" id not a reason to switch to Zig, unless you have a reason that borrow checker is limiting you from developing, hence the "I don't like this attitude". Just give the reason, not the "solution"
Not to mention we're nitpicking over something that an LLM wrote.
Ok have fun. The rest of us are having no problems.
Given this is from Vercel and most likely vibe coded (hopefully not), I wonder how many zero-day vulnerabilities will be there... :^)
Then why make an app instead of a website?
Sounds very similar to webui (zig version: https://github.com/webui-dev/zig-webui)
What is the difference?
Using the "system WebView" is not a positive on Linux.
For some reason that always means WebKitGTK, which is crummy.
Someone, anyone, please get CEF working with GTK4.
That is not native at all.
Well, yes, it's zero-native (as in 0% native).
hence the "zero" in the name /s
This is not native.
Im not sure if people are getting the biggest problem in electron desktop apps.
Its RAM usage not the disk!!
Why are they all making the same thing in different ways?! I have never worked on an electron app where the executable size was an impediment to the business. Its always the RAM/CPU usage. If we are going to work on the same webviews like electron and others, how will this make any difference?
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
zero examples
Still, using system's native GUI should be more performant and use less memory.
I would rather see existing Zig GUI libraries using system's GUI primitives improving. With LLM GUI stuff should be simple enough and we don't need to rely on people web expertise to build desktop apps.
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.
Qt is used to develop arguably the best desktop environment on the market - KDE Plasma - as well as a miriad of serious software artifacts. It's not exactly native to MacOS and Windows, but advantages overweight the downsides.
No screenshot examples even? :/