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?
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.
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 like Flutter, it's actually not a webview unlike most other frameworks and likely the most mature out of them. I also am keeping an eye on Rust GUI frameworks, Dioxus Native in particular as they're making their own renderer.
> No borrow checker. No lifetimes. No fighting the compiler for 20 minutes over a string.
It's embarrassing. If the borrow checker and lifetimes are difficult for the author, I would suggest sticking with non-systems-languages. In systems languages you have to either do the work the borrow-checker does in your head, or you let Rust do it.
If you are fighting the Rust compiler for 20 minutes over a string (or whatever actually happened that warrants this hyperbole), you are simply not writing good systems-level code.
This is an advanced version of the kind of person who deliberately compiles without warnings in C because they make it harder to find the error messages. It's complete amateur hour and it's embarrassing.
The real fix here is to learn how to do it properly. I VERY RARELY run into Rust compilation issues where I think "this is stupid". Nearly all of the time, the compiler is telling me that I forgot to think of something that I should have been thinking about, or that I've not been explicit enough. I've written C++ for way too long to know that this is hyper valuable.
I've also written enough Zig to know that Zig is not for people who are bad at systems level programming. It'll blow up in your face, just like C.
I don’t know. I still prefer simply shipping Go binaries around that fire up a local web server and open the web page on start. I’m old enough to care about these fancy languages, frameworks, native APIs and such. A dumb language like Go, in combination with HTMX and some JavaScript/CSS is all I need.
21 comments
[ 4.1 ms ] story [ 52.4 ms ] threadI don’t like this attitude, both zig and rust have their strengths.
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?
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.
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.
What is the difference?
For some reason that always means WebKitGTK, which is crummy.
Someone, anyone, please get CEF working with GTK4.
It's embarrassing. If the borrow checker and lifetimes are difficult for the author, I would suggest sticking with non-systems-languages. In systems languages you have to either do the work the borrow-checker does in your head, or you let Rust do it.
If you are fighting the Rust compiler for 20 minutes over a string (or whatever actually happened that warrants this hyperbole), you are simply not writing good systems-level code.
This is an advanced version of the kind of person who deliberately compiles without warnings in C because they make it harder to find the error messages. It's complete amateur hour and it's embarrassing.
The real fix here is to learn how to do it properly. I VERY RARELY run into Rust compilation issues where I think "this is stupid". Nearly all of the time, the compiler is telling me that I forgot to think of something that I should have been thinking about, or that I've not been explicit enough. I've written C++ for way too long to know that this is hyper valuable.
I've also written enough Zig to know that Zig is not for people who are bad at systems level programming. It'll blow up in your face, just like C.
Do you really see nothing wrong with this sentence?
I don’t know. I still prefer simply shipping Go binaries around that fire up a local web server and open the web page on start. I’m old enough to care about these fancy languages, frameworks, native APIs and such. A dumb language like Go, in combination with HTMX and some JavaScript/CSS is all I need.