heh, I'm not sure of your particular beef with these two but I'll use this as an opportunity to explain my rationale.
I obviously write a lot of code in Go but as a language it's also a really nice pairing with the IRC protocol. The way you write abstractions and tests just lends itself so well to writing desktop applications. On the other hand, writing UIs in Go (which I've tried in a multitude of ways) is just a really poor fit because asking Go to emulate Elm architecture is very clunky.
From my perspective, UIs are side effect driven code and demand a language that can fit that paradigm not just well, but great. Anything else I would or could have chosen would've required way more CGO dependencies than I have (of which I only have 1 atm) and would have read worse when I tried to hook it into Go.
Conversely, Wails' bridge to Typescript and React is very simple to use, reliable, and keeps up with the performance and consistency demands on an IRC client. Tailwind is also just very good at making compatible CSS; I was inspired by the use of QT in modern car infotainment systems in my selection of a component-based CSS approach.
Lastly, the whole thing is compiled into the binary that you download and makes no external calls on its own. It's all built on top of the OS WebView rather than a third-party browser the way, say, Electron is.
My beef is around your comment where you stated "limited in its resource footprint". Sure, Wails is lighter compared to Electron, but it's still not as lightweight or efficient as a native app. I personally wouldn't pitch it as a "limited resource footprint" app.
> Sure, Wails is lighter compared to Electron, but it's still not as lightweight or efficient as a native app.
Yeah, I think that's fair. I don't think about resource utilization in a vacuum: native apps require I develop three different apps and likely have a lot of CGO dependencies. With Wails and the OS WebView the same client you're used to using on MacOS should work the same or similarly on Linux and Windows within reason. They should also all maintain similar resource utilization profiles. That's why I said it's limited in its footprint, I'm not here to compete with native library performance and native library performance isn't trying to compete with my ability to cross-compile.
I'm currently connected to four networks for 6 days and 18 hours. Compared to other native apps on the same system:
App Main PID Uptime Avg CPU Main MiB Total MiB
------------ -------- ------------ ------- -------- ---------
Cascade 45314 6d 17h 45m 1.52% 73.0 556.8
Proton Drive 22091 11d 04h 32m 0.15% 48.0 65.1
Ghostty 78285 27d 22h 03m <0.01% 173.6 184.2
Finder 1308 34d 19h 32m 0.05% 104.4 104.4
so, if I rewrote the application into three separate applications I could probably save ~200 MiB of memory footprint. I'll look into my ability to slim down the memory utilization but some chunk of this is probably the message buffer of each channel.
The wails website says "~10MB baseline memory (vs Electron’s 100MB+)" and that sounds pretty reasonable to me. Does it bloat up badly when you start doing things?
heh, I'm not sure of your particular beef with these two but I'll use this as an opportunity to explain my rationale.
I obviously write a lot of code in Go but as a language it's also a really nice pairing with the IRC protocol. The way you write abstractions and tests just lends itself so well to writing desktop applications. On the other hand, writing UIs in Go (which I've tried in a multitude of ways) is just a really poor fit because asking Go to emulate Elm architecture is very clunky.
From my perspective, UIs are side effect driven code and demand a language that can fit that paradigm not just well, but great. Anything else I would or could have chosen would've required way more CGO dependencies than I have (of which I only have 1 atm) and would have read worse when I tried to hook it into Go.
Conversely, Wails' bridge to Typescript and React is very simple to use, reliable, and keeps up with the performance and consistency demands on an IRC client. Tailwind is also just very good at making compatible CSS; I was inspired by the use of QT in modern car infotainment systems in my selection of a component-based CSS approach.
Lastly, the whole thing is compiled into the binary that you download and makes no external calls on its own. It's all built on top of the OS WebView rather than a third-party browser the way, say, Electron is.
My beef is around your comment where you stated "limited in its resource footprint". Sure, Wails is lighter compared to Electron, but it's still not as lightweight or efficient as a native app. I personally wouldn't pitch it as a "limited resource footprint" app.
> Sure, Wails is lighter compared to Electron, but it's still not as lightweight or efficient as a native app.
Yeah, I think that's fair. I don't think about resource utilization in a vacuum: native apps require I develop three different apps and likely have a lot of CGO dependencies. With Wails and the OS WebView the same client you're used to using on MacOS should work the same or similarly on Linux and Windows within reason. They should also all maintain similar resource utilization profiles. That's why I said it's limited in its footprint, I'm not here to compete with native library performance and native library performance isn't trying to compete with my ability to cross-compile.
I'm currently connected to four networks for 6 days and 18 hours. Compared to other native apps on the same system:
so, if I rewrote the application into three separate applications I could probably save ~200 MiB of memory footprint. I'll look into my ability to slim down the memory utilization but some chunk of this is probably the message buffer of each channel.
The wails website says "~10MB baseline memory (vs Electron’s 100MB+)" and that sounds pretty reasonable to me. Does it bloat up badly when you start doing things?
1 reply →