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?
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!)
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.
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.
"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."
"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.
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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.
