Discussed recently:
Wails: Build cross-platform applications using Go - https://news.ycombinator.com/item?id=32080899 - July 2022 (45 comments)
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.
Hey, does that video editor has a public repo or is it a private thing?
It's a paid app called Recut (https://getrecut.com)
I didn't think you would be using Tauri in a production app. + That's a really nice idea! I hope you the best :)
one main advantage I see over Tauri is that Wails generate a typescript definition for the functions exposed to the frontend from the go side
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 sounds really cool and makes me want to learn go so I can make some desktop apps...
I made a speedometer display application for my motorcycle with Wails 1, and it has been great tbh. Low requirements and all
Interesting. Any more details?
I thought about implementing something like this with a SBC to replace a broken motorcycle dashboard but never got around to it.
In short: circular lcd display hooked up to a raspberry pi running the application, with a special connector to handle CANBUS
That sounds great. I don't suppose the code is published, is it? I'd love to see examples of CANBUS interaction from the rpi.
Not yet unfortunately, but I’ll make a submission if I do
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).
If you think a 10MB binary is amazing, try out FLTK, your cross platform GUI programs can start at 100KB.
Isn't the point of Wails (and Electron) to use "web" UI techniques vs. more traditional UI toolkits?
Isn't the point of software to deliver something people want to use?
I wouldn't have minded even if it was 20MB.
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!
I built a small thing in Wails, and was really quite happy with the experience, and got some great support when I had questions.
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.
I miss desktop UI designers.
based on the release announcement, no. But its the next major thing they want to tackle.
Thanks. I'm in no hurry.
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
I just want a decent native GUI framework for Go, I don't want to use a totally different language to write the UI...
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.
Is there a serious performance benefit here instead of using electron?
You still need to spin up an instance of your operating system's javascript engine correct?
I assume spinning up a JavaScript engine is much lighter than spinning up a chromium browser (like in electron)
How does this compare to Tauri ?
Edit: it looks like it leverages its own Webkit for the frontend, but then how is this more efficient than Electron ?
The key to it is that it uses the OS's webview (on Windows 10+ the new edge webview https://developer.microsoft.com/en-us/microsoft-edge/webview...) which means that you're mostly not bundling the whole of chromium / webkit each time.
Tauri does this as well, I use it for https://github.com/Ell/shortmon and get ~1-2 meg binaries with a react based ui
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?
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.
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.
The "web" side is completely customizable. You can definitely use plain JS, HTML, and CSS.
Agreed on the bloated frameworks.
I'm also enamored with https://redbean.dev/ -- this is a good problem to have: which awesome project to play with?
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.
I feel, in my bones, that this must have been done for C, too: could someone google it for me? Doing a search for "... C Electron" is a bit fruitless.
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.
you will need openssl for https,probably even need it for cross platform,that alone is a non starter for me.
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?
in that case, sciter might be your friend
It would be great if you could configure this depending on needs.
E.g. include only the Canvas part, leave out JS, CSS, Video, etc. for a simple drawing app.
Is there something similar but for Python?
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.
Wuby on Wails
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.
But I'll keep an open mind and give it a look
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.
I've used both and not seen any sign of the Rails mindset in Wails. We're writing Go not Wuby :)