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.
This looks incredible. I built a posture improvement app for MacOS, with the timing code written in Go and the actual window display in Swift. This seems like it would have been a far cleaner solution overall.
Does anyone have experience developing in Wails? How is the dev experience?
I've developed a few test application in wails. It's great and stable as a single widow application! It doesn't have support for system tray nor multiple windows.
Also, having contributed I have to say the source code is very well organized and easy to understand!
Is there multi-window support yet? I wanted to do a hobby project with it months ago but spent too much time before I found out it can't do that. Wails+svelte+go was going to be my stack.
Are there ways to create cross-GC cycles with this framework (e.g. JS object pointing to Go object pointing back to a JS object), and if so, how does the framework handle this?
My initial instinct would be to treat the JS and Go as frontend and backend, and not have objects like that coupled so closely, but I don't know anything about this framework
Building on top of a framework that bundles a Chromium should result in a smaller application than building on top of a framework that bundles a WebKit. As an example, compare Vivaldi (Chromium) and Orion (WebKit).
Chromium has many more batteries included though, such as V8/Node.
I believe the right term here is WebView, which will use the OS's native browser framework to display the app. For Windows this would be Microsoft Edge WebView2 and for Linux webkit2gtk. I do believe Qt WebEngine (or Qt WebView) might be the better option for Linux though, although I'm guessing webkit2gtk is being used because of more readily available Go bindings.
You’re wrong in your belief. We all know what a WebView is, but what is being discussed is bundling WebKit vs. bundling Chromium (like Electron does). A solution that bundles only a WebKit engine would be smaller than one that bundles a Chromium. What is your objection, specifically?
That's fair, but that Go framework would likely be inferior to the flexibility and robustness of the web stack. Not to mention require a learning curve to master, whereas web frameworks are already familiar to many developers.
I think projects like Wails bring together the best of both worlds, without the drawbacks of something like Electron.
Kudos to the team for releasing v2! I'm looking forward to trying it out.
Looks interesting and a great deal more elegant than the usual Electron mess, though I'm running into some kind of race condition on Windows that continually crashes `wails dev`, so that's a bit disappointing. Nonetheless, looking forward to using this.
Wombat, a wails based gRPC GUI client has been working great for me and my team, and we use it for every gRPC demo we have to give since it's been introduced to the team.
There is webview, a low level C library with various bindings that can be used to create a webview using os provided browser and interact with it. Wrt. featureset its is a lot more simpler and lower level than both electron and wails.
Don't get me wrong: https everywhere is a good policy, but I'm not super convinced of the need for strictly local connections to use https. Am I missing something?
This looks interesting, but I'm always hesitant to use anything in Go that's developed with a Rails mindset. They're two very different ways of looking at development, and trying to anything in Go using a Rails mindset usually ends in very confused code.
Having done Rails for about a decade, I believe that it's just the name. It's not only a reference to Rails, but the main author lives in Wales (the country), so it's a nod to that as well.
Wails is really well done, and pretty minimal, and (to me) doesn't feel like Rails at all.
Wails: Build cross-platform applications using Go - https://news.ycombinator.com/item?id=32080899 - July 2022 (45 comments)