I've been using v2 for a month or so and it's really great. There are a few things that feel a little bit rougher than the Rust equivalent (Tauri), but Go is just so much faster to code in that this has been a pleasure to work with.
Also props to the lead maintainer Lea Anthony who seems to be behind all the very exciting momentum of the project
What would be the main differences Wails and Tauri? Rust's gurantees regarding type safety and parallelism? I image that the performance characteristics greatly depend on the chosen front end framework, or am I mistaken here?
I can only speak on Tauri, which I’ve been using to build a video editor, but with most of the heavy code living on the Rust side, the UI remains snappy and responsive even while the “backend” is seeking through videos or whatever.
I’m using Svelte, but I don’t think that matters too much. The popular front end frameworks are close enough in performance IMO. I think it would really come down to dividing up the operations so the expensive ones run in native code instead of JS.
Congratulations to everyone who worked on this! I'm definitely going to have to give this a chance. The fact that it doesn't require any large dependencies shipped with the application is a huge draw, and with native UI options in Go being a little lacking, it would suffice to say this option is currently very enticing.
As for my part, I've regrettably been pretty absent on go-webview2 lately, working on other projects and life, but it's cool to see some initiative on porting OpenWebView2Loader bits to Go thanks to Wails. For anyone wondering what this is, on Windows right now go-webview2 avoids CGo by linking directly to WebView2Loader.dll and implementing COM bits in Go. However, to make matters a little complicated, this DLL is also embedded into the binary and then loaded with a memory implementation of the Windows loader, in order to avoid needing to separately ship this DLL. If this sounds horrific, I agree; my intent was always to reverse engineer WebView2Loader and port it to Go, but I only ever finished the reversing part. In the meantime, it has been ported to Pascal, and maybe soon, it will be ported to Go, too. It's pretty uneventful for the end user, but I think it will lead to better robustness in the end, so I am excited for it.
I've been work on a proof of concept with Wails and it's a productive development loop. The only thing different about the front end code vs a website is that it calls functions generated from my Go back end (fully typed!) instead of making an HTTP call.
The end result is a single binary. I suspect there's interesting things to be built as small extensions/compliments to command line tools.
> The only thing different about the front end code vs a website is that it calls functions generated from my Go back end (fully typed!) instead of making an HTTP call
Now take it to the next level: put those functions in a service worker and create a REST API that works entirely locally and can be switched out for a remote server with ease.
Or don’t, if you have no intention of making a web version. But IMO it’s a powerful model for those who do.
That's an interesting point about service workers. My thinking is to layer them in the other order: the generated types are based on Go struct json tags so the function signatures I'm calling could be implemented as REST calls. ie SomeEndpoint(paramA: string, paramB: string): Promise<SomeEndpointResponse>
The notion of a web version is a distant one for the current project so it's only a theory.
This looks incredible. Really nice work so far. While I'm not interested in the more bloated frameworks, hoping that I can create something useful with just vanilla JS, HTML, and CSS. Could possibly even plug into Hugo to create a "native" app for content creators.
What's the size of an Hello World with Wails? uncompressed? Because that's the issue with Electron, shipping yet another entire web browser with every installation. At the same time, if the app doesn't ship with a browser and use the webview available then it defeats the purpose of using that kind of tech since it means that whatever chromium engine which runs on the user's device has to be tested. No an issue for simple apps, a much bigger one with complex applications with browser API edge cases.
My app (which is bigger than Hello World, but not by much) is about 9M on disk. This is typical for Go apps, oddly enough. It's not compressed so far as I know.
Wails is great! I've been working with wails v2 on Windows, and it's been a great experience. Built and delivered a Windows desktop application in Go + AntD for a customer really quickly.
It's a little complex app dealing with Win32 API's directly from Go and the binary being just 10MB is amazing, which can be compressed further with UPX.
Though, UPX-compressed Go binaries has a very high rate of being flagged by antivirus software (especially MS Defender).
The goal was having the convenience of building UI in React and have the heavy lifting done by Go. Both, stacks I am very familiar with and work with daily.
Readit News
Wails: Build cross-platform applications using Go - https://news.ycombinator.com/item?id=32080899 - July 2022 (45 comments)
Also props to the lead maintainer Lea Anthony who seems to be behind all the very exciting momentum of the project
I’m using Svelte, but I don’t think that matters too much. The popular front end frameworks are close enough in performance IMO. I think it would really come down to dividing up the operations so the expensive ones run in native code instead of JS.
As for my part, I've regrettably been pretty absent on go-webview2 lately, working on other projects and life, but it's cool to see some initiative on porting OpenWebView2Loader bits to Go thanks to Wails. For anyone wondering what this is, on Windows right now go-webview2 avoids CGo by linking directly to WebView2Loader.dll and implementing COM bits in Go. However, to make matters a little complicated, this DLL is also embedded into the binary and then loaded with a memory implementation of the Windows loader, in order to avoid needing to separately ship this DLL. If this sounds horrific, I agree; my intent was always to reverse engineer WebView2Loader and port it to Go, but I only ever finished the reversing part. In the meantime, it has been ported to Pascal, and maybe soon, it will be ported to Go, too. It's pretty uneventful for the end user, but I think it will lead to better robustness in the end, so I am excited for it.
The end result is a single binary. I suspect there's interesting things to be built as small extensions/compliments to command line tools.
Now take it to the next level: put those functions in a service worker and create a REST API that works entirely locally and can be switched out for a remote server with ease.
Or don’t, if you have no intention of making a web version. But IMO it’s a powerful model for those who do.
The notion of a web version is a distant one for the current project so it's only a theory.
I'm also enamored with https://redbean.dev/ -- this is a good problem to have: which awesome project to play with?
I thought about implementing something like this with a SBC to replace a broken motorcycle dashboard but never got around to it.
It's a little complex app dealing with Win32 API's directly from Go and the binary being just 10MB is amazing, which can be compressed further with UPX.
Though, UPX-compressed Go binaries has a very high rate of being flagged by antivirus software (especially MS Defender).
The goal was having the convenience of building UI in React and have the heavy lifting done by Go. Both, stacks I am very familiar with and work with daily.