Comparison with wails

[kishaningithub]

I stumbled upon wails https://github.com/wailsapp/wails
Which is mostly similar to tauri.
If possible a comparison between tauri and wails would be great.

[zakaria-chahboun]

Wails is easier

[zakaria-chahboun]

Golang is easy to learn!
Wails has good documentations + easy configurations, you can learn it completely in one day!

[ghost]

Yeah that's what I'm setting up for right now. I was preparing a Deno package for use as a sidecar for Tauri, but today I noticed that Deno is spitting out huge binaries. I could have swore that they were only about 30mb last time I tried it.

I would use Tauri if I could do more from the JavaScript side out of the box, but I'm not going to spend 6 months getting familiar with Rust in order to do all the things that I want to do. I already know a few basics of Golang from checking it out years ago.

Things I would have liked Tauri to let me do out of the box with non-webview/global JavaScript:

• Serve files and api methods to my frontend with local http.
• Work with native SQLite database.
• Run native/OS cli commands and process the results.

But I need a sidecar or Rust code/plugins to do all that stuff.

[FabianLars]

Serve files and api methods to my frontend with local http.

Similar to a rest api server thingy? Yeah that's a little more involved and indeed would require rust or a sidecar.

Work with native SQLite database.

Unless your use-case is super complicated (in which case you'd really need a custom solution), we do have this: https://github.com/tauri-apps/tauri-plugin-sql. And while this is not part of tauri's core, the plugin system was designed in a way to make it easy to integrate additional features so that you use them just like they would be part of it, if that makes sense?

Run native/OS cli commands and process the results.

https://tauri.app/v1/api/js/modules/shell 🤷

But in general the vast majority of tauri users don't do anything in rust. While i appreciate every tauri app that actually makes use of rust, it's definitely not a requirement, unless your app is like super complicated and doing close OS interactions or something.

Anyway, thanks for the feedback both of you! :)

[ghost]

Thanks for giving me something to think about @FabianLars - I have decided that for my particular application, I will need a sidecar no matter what because I eventually want to run the same code as a headless api server. The desktop environment will be for local development and the integrated GUI will be optional even for that. So, I'll just continue developing my Deno solution and revisit Tauri and Wails later. I'm already using JS engine for my code and most web devs won't think twice about downloading a 100mb+ binary for doing local dev.

One more feedback on the pro-Tauri side: I already have Tauri and Create-React-App working together in development and that was super easy to do. During my brief look into Wails and CRA today I could not see a straightforward solution to run the CRA devserver. The Wails docs direct you to a gist that has a very sketchy and unstable looking watch/build script.

[huangjj27]

Everybody (tm) says that you can learn enough Golang in 2 weeks to become an effective Go programmer.

With my personal experience, 2 weeks is long enough for someone to write rust program as fast as the go ones from zero, If they decides not to use hard part of rust, like lifetime parameter (by using cloned ownership as replacement)

[RustLoverTheCoder]

tauri will be more stable and smaller

[zakaria-chahboun]

Wails also provide a smaller binary! You can also do a cross compile from your current os!

[RustLoverTheCoder]

For me, I use go for small projects or demos, and rust for serious projects

[Blatman]

I guess eventually the pros will produce some item by item comparisons but here is my take on WAILS/Tauri and Neutralino/NWjs as well.

As an amateur hobbyist I am looking for a way to make desktop apps leveraging the simplicity of using HTML/JS/CSS without having to get involved with more intensive lower level languages. I also occasionally want to do apps for both Windows and Mac so web makes it easy.

The other good thing about using HTML/JS/CSS for most of the app coding is that compiling is not necessary (WASM excepted) so dev can be simply done with text editors and doesn't require complex toolchains.

Uptil now NW.js has done this quite well - custom builds of the distributed binary can be done by developers if they wish (not necessarily easy) but otherwise apps can be developed using just HTML/JS/CSS/Node technologies. Core features such as windowing/notifications/events/etc are implicit within the binary but made available via the nw API to the JS/Node world so no need to get to grips with lower level languages such as C++/Rust/Go/etc. The downside of NW.js is the size of the shipped binary because a browser is always being bundled (Chrome).

This led me to look at Neutralino/WAILS/Tauri which all offer the advantage of a vastly smaller shipped binary package by using the OS'es inbuilt webview interface.

At this point I would suggest that one of the biggest weaknesses of all these distros is that they are effectively one man bands (although Tauri appears to be more heavily resourced) and this means fixes/features/docs are too slow at times.

Note 1: I haven't covered Electron here as I don't use it but it is similar to NW.js and rather better resourced - it also suffers from large shipped binary size.

Note 2: The static web archive I have used initially to try the distros is old school with linked JS script files and standard page href links (no modules or ES stuff).

Of the three (Neutralino/WAILS/Tauri) WAILS and Tauri look to be quite similar in concept with Neutralino almost but not quite.

All three have small binary sizes as a result of not having to ship a browser.

Neutralino (uses C++ for backend) -

Pros:

Easy to use with distributed compiled binaries. Server binary using C++ code and Client library using JS.
The server binary controls the Native API and core features and every HTML file in the app code need to reference the Client library to work with the Server binary via the Native API.
It has a CLI that will package app assets/resources into a file called resources.neu that can be used with the server binaries. App assets/resources can also be used as plain source along with the binaries and this is how I usually package my mac apps which can be done manually without toolchains.
This is an advantage for Neutralino because both WAILS and Tauri package the app resources within the shipped binary so compilation is required.
Mac app - resources can be available in Resources folder or as bundled package.

Cons:

Native menus not available.
Newly introduced websocket not robust.
Lot of dependence on upstream libraries that don't get enough attention.
Multi-window management not implicit needs to be done by dev however can be done in JS using the API.
Node not supported directly - only via extensions somehow.
Raw binaries are produced (compilation is easy) but no packaging/bundling code is included.

Usage:

I find it great for small apps and archived static webs. It has extensions but documentation and useful examples are thin on the ground but potentially should be good - pro devs should have more success here. Manual bundling of Mac .app packages is easy but a toolchain could be handy.

WAILS (uses Go for backend) -

Pros:
App bundling done with builds.
Go is meant to be easier than Rust from what I have heard (can't see until the dust settles on that one).
Main dev is very responsive to queries/etc.

Cons:
Multi-window still on roadmap
Notifications still on roadmap
Native menus not available to JS context.
App bundling appears to only support modules for JS
Mac app - resources always compiled into binary rather than available in Resources folder.

Usage:

Tried a static web archive and worked fine in dev mode but links/JS not working in production mode. The fix may entail some changes within the backend Go code so looks like for a simple app dev needs to get involved with Go coding. The WAILS example app works well but it is designed around ES module coding which I think WAILS prefers.

Tauri (uses Rust for backend - other languages on roadmap) -

Pros:

App bundling done with builds.
Native Menus supported
Multi-windows supported
Notifications supportedg

Cons:

Native Menus require Rust coding
Multi-windows require Rust coding
Notifications require Rust coding
No DMG customisation
Mac app - resources always compiled into binary rather than available in Resources folder.

Usage:

Tried a static web archive and it worked well in both dev and production. The production build for Mac actually produced a debug binary, a raw binary, a packaged .app bundle and a DMG.

• Wahoo!

I see these distros as a means to bring web tech into the desktop arena and provide a fusion of web and traditional desktop but sometimes it appears that the web ethos (along with Mobile) seems to predominate at the expense of the boring desktop feature set - things like native menuing are necessary in desktop to provide a consistency of use within an OS (bad enough that Apple changes the OS every year). Most app examples I've seen tend toward the web SPA approach in the main window using a framework of some sort - still to find a decent example of a desktop multi-window paradigm.

Endnote:

For me if shipped binary size is not an issue I would still use NW.js as apps can be coded with HTML/JS/CSS/Node without having to get involved with low level backend stuff.

Neutralino is my next choice for smaller app sizes but the robustness of the backend needs improving but at least efforts are made to bring core functions out into the JS world.

At this stage I would take Tauri over WAILS as it appears more feature complete but unfortunately too many core features are hidden in tha backend - caveat here - I think both distros have mechanisms for the backend to talk to the frontend for databases and stuff but it appears not implicit for things like windowing and menus, it is up to the dev to code.
To be fair both distros will have capabilities that I have yet to uncover but unfortunately I haven't found any good examples to to figure them out eg: multi-window.

With Tauri I must say that the fact I could drop a simple web archive into the dist folder and do a build with a DMG as a result was impressive and I have managed to change the native menus around a bit but I would rather be doing it with JS.

At the moment for me Tauri is potentially the best but would be good to see basic core functions like multi-windows/notifications/native menus made available in the JS space.

[FabianLars]

Thank you for this super extensive write-up!! ❤️
I don't know enough about the other projects, but 2 corrections for Tauri: Both Notifications and multiwindows do work in JavaScript,

• Notifications: https://tauri.app/v1/api/js/modules/notification and the browser-native apis work too! (we overwrite the latter with what powers our own notification module)
• multiwindow, it's currently only one (too) small paragraph in the docs: https://tauri.app/v1/guides/features/multiwindow#create-a-window-in-javascript. And here's a repo example too https://github.com/tauri-apps/tauri/blob/dev/examples/multiwindow/index.html

You're right about the Menus tho, we do plan to add js apis for that after the menu rewrite (https://github.com/amrbashir/muda). Probably will have some quirks because JavaScript runs "too late" for Menus meant to be present at window creation, nothing a hidden window can't fix tho 🤷 ("hidden window" as-in, it starts hidden, runs its init code, and then shows the window; this will have to be manually done by the dev tho)

[Blatman]

Yup - I was just trying the window settings in the config file and probably a good solution is to start the window hidden giving the JS time to config the menu arrangement then show the window. The way I see it is that it would be good to have core features like Menus available in the JS space but for those interested in a more performant app they can get into the Rust backend directly.