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.
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.
Process PID Avg CPU Footprint (MiB)
------------------------------ ------ --------- ---------------
Cascade 45314 0.46% 73.0
WebKit WebContent 45349 0.50% 392.9
WebKit GPU 45347 <0.01% 26.1
WebKit Networking 45348 0.02% 6.5
Nick completer plugin 45344 <0.01% 2.8
Nickname colors plugin 45345 <0.01% 9.7
ThemeWidget service 41353 <0.01% 10.1
SafariPlatformSupport helper 41355 <0.01% 13.1
------------------------------ ------ --------- ---------------
Total 1.00% 534.2
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.