If Tauri ever gets proper webgpu support, that'll be the Electron killer.
cyanydeez 5 hours ago [-]
nothings going to kill electron. The value of packaging the chrome browser is you don't need to suddenly track down 4+ different webview rendering bugs, capabilities, etc.
aiscoming 18 hours ago [-]
I love the redefinition of "native desktop app" - a web app which uses the system web-view instead of bundling Chrome.
feverzsj 17 hours ago [-]
Considering Microsoft already doing this in win11, it's fine.
HappySweeney 12 hours ago [-]
They are redeveloping much of that electron-based code back to Win32 as part of their quality improvement initiative.
lionkor 13 hours ago [-]
If Microsoft does it now, and didn't used to do it, it's probably terrible.
AbuAssar 19 hours ago [-]
> 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.
nurettin 18 hours ago [-]
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.
DeathArrow 18 hours ago [-]
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.
pmarreck 18 hours ago [-]
> "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)
ramon156 17 hours ago [-]
"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.
InsideOutSanta 16 hours ago [-]
There doesn't really need to be a counterargument. If you like Zig, that's great. Zig is great, you are great. You go on using it.
mpalmer 10 hours ago [-]
You should really make sure to take your own advice when you're being this discourteous.
adastra22 17 hours ago [-]
Ok have fun. The rest of us are having no problems.
lifty 16 hours ago [-]
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?
SyneRyder 16 hours ago [-]
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++:
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/
hypendev 16 hours ago [-]
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.
lifty 15 hours ago [-]
Thanks, I will keep an eye on this as well. Wish you success!
hypendev 11 hours ago [-]
Thank you so much! If you ever have any feedback or wishes for the Go side, feel free to reach out!
raulgooo 5 hours ago [-]
Hey this looks pretty good.
lifty 14 hours ago [-]
[dead]
PaulKeeble 14 hours ago [-]
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.
kitd 16 hours ago [-]
I've not used it myself, but I've heard good things about Wails.
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.
aiscoming 16 hours ago [-]
if typography is critical for you, nothing has better support for it than the web platform
d12bb 14 hours ago [-]
The web platform, which just recently gained tolerable text wrap?
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.
lifty 14 hours ago [-]
I like this approach, it's what I had in mind, but Crux doesn't seem to support desktop targets. I know on MacOS you can get nice looking apps with their native toolkit, on Linux you have GTK4 which can be decent looking, but not amazing, and on Windows, I truly don't know. Native apps on Windows look crap to me (without even mentioning the advanced fragmentation in UI toolkits in Windows). Maybe someone has some good examples for Windows and Linux, using native SDKs.
delta_p_delta_x 12 hours ago [-]
> Native apps on Windows look crap to me (without even mentioning the advanced fragmentation in UI toolkits in Windows).
WinUI 3 is pretty decent. Have a look at first-party programs like PowerToys[1], or Windows Terminal[2].
Only partially true: macOS is supported, and one can fall back to the web. But you're right in that native Windows and Linux are still missing.
> Linux
Problem with Linux of course is that it's almost as fragmented as Windows, with Qt and GTK being the main toolkits, but a dozen more if you ask the wrong people :D
I personally don't like GTK, to me it (well, mainly Gnome) looks and feels like trying to copy macOS without understanding what makes it great, but Qt is a toolkit I can get behind…
norskeld 18 hours ago [-]
Given this is from Vercel and most likely vibe coded (hopefully not), I wonder how many zero-day vulnerabilities will be there... :^)
p5v 5 hours ago [-]
This looks like Tauri.
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.
Do you really see nothing wrong with this sentence?
lionkor 13 hours ago [-]
> 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.
jsomedon 16 hours ago [-]
That is not native at all.
rob74 16 hours ago [-]
Well, yes, it's zero-native (as in 0% native).
anhner 16 hours ago [-]
hence the "zero" in the name /s
vijaybritto 18 hours ago [-]
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?
mpweiher 17 hours ago [-]
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.
vijaybritto 14 hours ago [-]
I am cursed that I always have to work on legacy products that were built many years ago and didnt consider these things.
I hope we eventually get a good/simple language/framework that can compile to native code. Even react native for mac/windows is good enough now.
cosmotic 18 hours ago [-]
Using the system webview theoretically saves memory. Though it's still not great.
Bolwin 18 hours ago [-]
Cause they all share one webview. Electron apps each run their own version of chromium
iamcalledrob 17 hours ago [-]
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.
easeout 16 hours ago [-]
Then why make an app instead of a website?
mpalmer 10 hours ago [-]
Tauri, but without the memory safety, funding, governance model, or human maintainers.
Oxodao 16 hours ago [-]
This is not native.
iamsaitam 17 hours ago [-]
zero examples
JoeDohn 8 hours ago [-]
"native", checks inside "web engines".
DeathArrow 18 hours ago [-]
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.
thayne 17 hours ago [-]
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.
kombine 16 hours ago [-]
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.
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.
[1]: https://github.com/dotnet/winforms/blob/27e7cb2e5043780dd75e...
I don’t like this attitude, both zig and rust have their strengths.
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)
Not to mention we're nitpicking over something that an LLM wrote.
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/
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.
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.
https://wails.io/
https://webkit.org/blog/16547/better-typography-with-text-wr...
WinUI 3 is pretty decent. Have a look at first-party programs like PowerToys[1], or Windows Terminal[2].
[1]: https://github.com/microsoft/PowerToys
[2]: https://github.com/microsoft/terminal
Only partially true: macOS is supported, and one can fall back to the web. But you're right in that native Windows and Linux are still missing.
> Linux
Problem with Linux of course is that it's almost as fragmented as Windows, with Qt and GTK being the main toolkits, but a dozen more if you ask the wrong people :D I personally don't like GTK, to me it (well, mainly Gnome) looks and feels like trying to copy macOS without understanding what makes it great, but Qt is a toolkit I can get behind…
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.
What is the difference?
Do you really see nothing wrong with this sentence?
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.
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?
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.
I hope we eventually get a good/simple language/framework that can compile to native code. Even react native for mac/windows is good enough now.
For some reason that always means WebKitGTK, which is crummy.
Someone, anyone, please get CEF working with GTK4.
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.
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.