Wails: Build cross-platform applications using Go(wails.io)
wails.io
Wails: Build cross-platform applications using Go
https://wails.io/
44 comments
I played with this a few days ago and it is still early days with rough edges but at the same time encouraging. I used the latest beta which supports Linux (the banner on the main site still says just Mac and Windows but the blog announces Linux support). The default app built after I increased the max file watcher system parameter and the dev mode reloaded quickly on changes after that. There was a flash of white as the app view loaded but I remember early Electron apps doing the same. Kudos to the devs for working on this - I’m hoping it brings some competition for Electron as it matures.
It states you can use native components and that it uses webkit. How does this work? I thought native components meant using the OS gui like Win32/MFC etc. How does this work through webkit? Does webkit have Win32 bindings?
Only a couple of elements are truly native: dialogs (like file pickers) and menus (like the old-fashioned app kind, File, Edit, etc.). See https://wails.io/docs/reference/runtime/dialog and https://wails.io/docs/reference/runtime/menu/
Everything else is rendered in a DOM.
And it doesn't always use WebKit; on Windows it would use Microsoft WebView2, which uses Blink/Edge.
Everything else is rendered in a DOM.
And it doesn't always use WebKit; on Windows it would use Microsoft WebView2, which uses Blink/Edge.
A while ago, I had posted about an app I made,
- using Wails,
- using Webview.
You can compare both: https://github.com/fusion/pngsource
Spoiler alert: it works, but... "meh."
You can compare both: https://github.com/fusion/pngsource
Spoiler alert: it works, but... "meh."
There's many complaints here about webviews vs native. How does this compare to the likes of Dart/Flutter?
Apart from the different backend(?) what is the difference between this and Tauri?
The different backend makes a lot of difference.
You can become good at Rust in 6 months of intense training, or you can become good at Go after a week. Of course Go is more limiting, but it's good enough for many cases, like JavaScript with Electron.
You can become good at Rust in 6 months of intense training, or you can become good at Go after a week. Of course Go is more limiting, but it's good enough for many cases, like JavaScript with Electron.
> It does not embed a browser, so it is resource efficient. Instead, it uses the native rendering engine for the platform. On Windows, this is the new Microsoft Webview2 library, built on Chromium.
How does this make it magically resource efficient? It's still another Chrome tab running some inevitable pile of inefficient excrement that burns watts. It's just not shipping it with the package. Disk and bandwidth is cheap compared to watts and latency which is the biggest problem with any web based technology.
I just want my native apps back (and no I don't want wx/Qt/Gtk!)
How does this make it magically resource efficient? It's still another Chrome tab running some inevitable pile of inefficient excrement that burns watts. It's just not shipping it with the package. Disk and bandwidth is cheap compared to watts and latency which is the biggest problem with any web based technology.
I just want my native apps back (and no I don't want wx/Qt/Gtk!)
If you're using Linux GNOME then GTK IS native, same thing for KDE and QT. wxWidgets uses native system components on all operating systems (and provides both GTK and QT backends for Linux). I agree that applications that are made for a single operating system are generally more appropriate because they feel better, but I don't feel it's realistic to expect from any company developing software simply because there's so many permutations of different systems to support. If you're developing for Windows for instance then "native" depends on the operating system version (win32 > uwp > winui3).
Also using the system webview (compared to loading a whole dedicated browser just for the application) in my experience is better when it comes to application bloat in the runtime, Tauri for instance achieves half of the memory usage that a Electron application needs and it's also possible to reduce CPU usage significantly by offloading any computations to the Rust backend.
I'm not saying I'm satisfied with the situation, just that I don't expect that anyone cares enough for truly native applications to become relevant again.
Also using the system webview (compared to loading a whole dedicated browser just for the application) in my experience is better when it comes to application bloat in the runtime, Tauri for instance achieves half of the memory usage that a Electron application needs and it's also possible to reduce CPU usage significantly by offloading any computations to the Rust backend.
I'm not saying I'm satisfied with the situation, just that I don't expect that anyone cares enough for truly native applications to become relevant again.
Here we go again. Another landing page that tells me absolutely nothing.
"Build beautiful cross-platform applications using Go"
OK this works as the title of the page, but to have it as the only sentence on the page? What exactly are you thinking? How is this supposed to convey any information?
Come on!
The first link is "get started" which again does not tell me anything about this tool. It tells me I need to install Go (I already have it).
Just how many links do I have to click through to figure out what this thing is?
EDIT:
Ironically, the actual useful content is filed under the "Docs" link on the top bar, which is the last place I would expect.
https://wails.io/docs/introduction
"Wails is a project that enables you to write desktop apps using Go and web technologies.
Consider it a lightweight and fast Electron alternative for Go. You can easily build applications with the flexibility and power of Go, combined with a rich, modern frontend.
Wails doesn't hold back with the eye candy either! This is xbar - a desktop application for MacOS written using Wails. It has menus, supports light and dark desktop themes, and the main window uses translucency that gives it that 'frosty' effect of a native app."
Why can't this paragraph be on the landing page?
"Build beautiful cross-platform applications using Go"
OK this works as the title of the page, but to have it as the only sentence on the page? What exactly are you thinking? How is this supposed to convey any information?
Come on!
The first link is "get started" which again does not tell me anything about this tool. It tells me I need to install Go (I already have it).
Just how many links do I have to click through to figure out what this thing is?
EDIT:
Ironically, the actual useful content is filed under the "Docs" link on the top bar, which is the last place I would expect.
https://wails.io/docs/introduction
"Wails is a project that enables you to write desktop apps using Go and web technologies.
Consider it a lightweight and fast Electron alternative for Go. You can easily build applications with the flexibility and power of Go, combined with a rich, modern frontend.
Wails doesn't hold back with the eye candy either! This is xbar - a desktop application for MacOS written using Wails. It has menus, supports light and dark desktop themes, and the main window uses translucency that gives it that 'frosty' effect of a native app."
Why can't this paragraph be on the landing page?
[deleted]
We don't need more beautiful apps. We need usable and consistent apps.
Typical beautiful app is barely-usable.
"beautiful" is an overused buzz word... has been for years. It rarely means anything.
I've seen "beautiful code", "beautiful API", "beautiful mobile apps", "beautiful note taking apps", etc and they usually aren't distinguishable from just normal stuff. 9/10 it's just some gradients and rounded corners thrown in somewhere.
I've seen "beautiful code", "beautiful API", "beautiful mobile apps", "beautiful note taking apps", etc and they usually aren't distinguishable from just normal stuff. 9/10 it's just some gradients and rounded corners thrown in somewhere.
[deleted]
I don't get these projects. If you're going to write an html/js app, why not just launch the web browser against the local url of your app?
Some people don't like the user experience of doing everything in the default browser. It's subjective.
How did the local url get there?
Or, to look at it from another angle, you could just click on the app and it opens?
Or, to look at it from another angle, you could just click on the app and it opens?
Mostly because with Wails/Tauri/Electron, you get file system access, native code etc.
yeah, the exe running the server (Go in the current case) has access to all that.
Because you might ship this to users and just having an app for them to click on and open is a lot more user friendly than telling people to type in some localhost URL or open browser tabs with "cryptic" urls.
Just have the application start the browser like daemons used to 20 years ago.
Nowadays they can even send the PWA manifest to hide the browser appearance.
Nowadays they can even send the PWA manifest to hide the browser appearance.
Are we really arguing why someone might want to have a "native" app instead of a browser window? There's many reasons why someone might want to have that.
Yes we are, Web technologies belong in the browser.
I wasn't impressed with MSHTML when it came up as Active Desktop, nor I am impressed with anything that followed suit.
I wasn't impressed with MSHTML when it came up as Active Desktop, nor I am impressed with anything that followed suit.
> Web technologies belong in the browser
That ship has sailed a long time ago. These days sometimes whole operating systems are based on HTML based interfaces (LGs TV OS would be one example).
That ship has sailed a long time ago. These days sometimes whole operating systems are based on HTML based interfaces (LGs TV OS would be one example).
WebOS applications don't ship a browser alongside them, they use what is already installed.
Doing Web development alongside native since Web exists, hasn't made me like shipping browsers with applications (or Web views) any better during the last 20 years.
Doing Web development alongside native since Web exists, hasn't made me like shipping browsers with applications (or Web views) any better during the last 20 years.
This framework does this same thing:
> It does not embed a browser, so it is resource efficient. Instead, it uses the native rendering engine for the platform. On Windows, this is the new Microsoft Webview2 library, built on Chromium.
https://wails.io/docs/introduction#native-elements
> It does not embed a browser, so it is resource efficient. Instead, it uses the native rendering engine for the platform. On Windows, this is the new Microsoft Webview2 library, built on Chromium.
https://wails.io/docs/introduction#native-elements
You missed my remark between parenthesis.
Not really sure what your point is. That these things are unimpressive? Agreed. It's just one lazy approach to a problem (multi-platform apps) that's not easy to solve. Webviews are a cheap way to get there.
This way you know exactly which browser people are using and you don't have to deal with idiosyncrasies.
Using the the apps I have built in this style as an example (not this library in particular though) - starting a whole browser comes with a lot of baggage you may not need - plug-ins as a small example. It’s easier to target 3 OSs than some random permutation.
Also, doing it this way, you can extend the Javascript to add custom callback functions - if that is something you need.
Also, it’s all in one process so there is less fiddly bits (request / response and all that)
You do bring up a good point though, and I hadn’t thought of the PWA angle. It would be an easy way to add a cli interface (just curl I guess)… I might try that next time.
Also, doing it this way, you can extend the Javascript to add custom callback functions - if that is something you need.
Also, it’s all in one process so there is less fiddly bits (request / response and all that)
You do bring up a good point though, and I hadn’t thought of the PWA angle. It would be an easy way to add a cli interface (just curl I guess)… I might try that next time.
performance.
some apps need native functionality, for example, instagram needs access to your camera.
some apps need native functionality, for example, instagram needs access to your camera.
An embedded webview gives you more control over the browser chrome (as in UI), extensions, cookies, etc. It also gives you a shim into some filesystem/OS APIs that a regular sandboxed browser page wouldn't have. It gives you a predictable HTML/JS renderer that you control, instead of blindly hoping that your user will happen to have a compatible browser.
Still, webview UIs are a lazy alternative to actual native apps. I don't like them either, but not every org can afford to hire native devs and write 3x-4x the UI code.
Still, webview UIs are a lazy alternative to actual native apps. I don't like them either, but not every org can afford to hire native devs and write 3x-4x the UI code.
> It also gives you a shim into some filesystem/OS APIs that a regular sandboxed browser page wouldn't have.
If you're just talking to a localhost server, it's got all the local access it needs. The web UI doesn't have to do anything besides control the native service running. I'd much rather be able to ship a tiny binary and use the local browser than pack around a whole browser just to access otherwise restricted/sandboxed APIs. You can just drop a URL shortcut on the desktop (or wherever) during installation.
If you're just talking to a localhost server, it's got all the local access it needs. The web UI doesn't have to do anything besides control the native service running. I'd much rather be able to ship a tiny binary and use the local browser than pack around a whole browser just to access otherwise restricted/sandboxed APIs. You can just drop a URL shortcut on the desktop (or wherever) during installation.
Because normal users expect a unified app experience and launching a local server that opens a tab in the browser is not an acceptable experience to them.
There's also limitations with that, like the inability to use the browser native file browser picker.
There's also limitations with that, like the inability to use the browser native file browser picker.
Wooby on Wails?
Lol, I imagined a series of mournful cries, like "Wail wail waaaaaiiiiil, not yet anoooooother webview framework...."