About this Series
If you haven't read the intro, I discuss a lot of the core information about this, I have included the Raw Stats in each of the blog posts so you can easily reference it while reading about each of the products.
Raw Stats
| Platform | AppImage File Size | Hello Memory AppImage | Hello Memory Unbundled | Graphic AppImage | Graphic Unbundled |
| Electron | 97 Megs | 203 | 129 | 401 | 316 |
| NW.JS | 110 Megs | 274 | 163 | 515 | 389 |
| Tauri | 71 Megs | 192 | 52 | 364 | 301 |
| NodeGui | 47 Megs | 437 | 53 | 760 | 467 |
| Yue | 19 Megs | 59 | 43 | 302 | 292 |
| Node-GTK | 100 Megs | 85 | 70 | 90 | 89 |
| Flutter | 70 Megs | 124 | 53 | 337 | 321 |
Tauri
Tauri - Build smaller, faster, and more secure desktop applications with a web frontend.
Tauri is one of the newer kids on the block. It has a lot of potential, and I was really strongly rooting for it. It is a extremely immature framework, and I don't say that lightly. They have done a awesome job with what they have built, it just is still very very young. They are attempting the noble goal to be a better Electron than Electron. To do that they have to create a decent API that right now you get out of the box on Electron/NW.js because of Node. How well have they done on this? I would say maybe 1% of the API surface is done that node currently supports, and that is probably being very generous. Node's API has some significant depth and breadth.
Doing a security freeze to finally release a "v1.0" at this point seems very, very pre-mature to me after my usage of it. For some very limited scope of apps, it is production ready but for the vast majority of apps that you would want to do in Tauri, you can't do them. I never managed to crash any apps that Tauri created! In that the apps actually built using features it supports appear to be production ready however I did have some issues with some simple Tauri JS API code that worked in development but didn't work on a release build...
In the multiple days I have played with Tauri, I have easily ran into so many different issues that makes me think it is no where even close to production ready for any real world usage or, as you will see later, very many application types. Everything from virtually a non-existent JS API's (missing many simple things, like you can't even check if a file even exists...) to things like broken flavors (Pure JS & Svelte JS don't even work out of the box, despite them having official flavors for them). However, one of the biggest issue for Tauri is that two of its major claims to fame appears to be false for the majority of developers and instead create some way worse issues for the Tauri team and by extension you the developer.
The size of application...
Lets take Windows first, if you want to support any older Windows (Like say Windows 7/8, and even Windows 10 prior to the April update) you have to ship a 110meg .msi file from Microsoft. Tauri requires a Edge WebView2 to be a certain version that didn't start shipping in Windows 10 until April. So to be safe, especially for offline install, you have to ship the msi embedded yourself. And bam, It is no longer a small app being distributed... In addition your user has to have ADMIN rights to install it, as installing the webview2 requires admin rights, which may or may not bother you. I prefer to build apps that require no installation.
On Linux, the build process does create a 8 meg .deb package which is nice and small! Tauri depends on libwebkit2gtk which is 57 megs and also on JavscriptCore which is another 25 megs and another dozen or so dependencies. Close to a 100 megs in dependencies. The good news is if you are using a gnome/gtk based windows manager, they should all already be installed. If you are using KDE, you will have to install them if you haven't installed any other gnome/gtk based apps before. So a 8 meg .deb file is actually really awesome size for a full app, and in this they did a awesome job! Very impressive, and lots of kudos for this!
Unfortunately, the currently distributed Webkit on most distributions has a very nasty bug that makes most Tauri app that needs access to any and all web sites that use CORS, impossible in virtually all situations. So to "fix" this you have to build your own version of Webkit using the latest sources. Which is fairly time consuming and basically means you are forced to distribute using an AppImage so that everything including the new fixed Webkit is bundled in your app.
Now, Tauri, awesomely supports building a AppImage right out of the box in addition to a deb, so another round of Kudos for the Tauri team. The AppImage is around a 71 megs file for a fairly simple app, and it is 100% self contained, so it should work properly on any distribution.
On Macintosh, I didn't investigate very much as Linux is my primary driver, and Windows rules the market. So these were my primary interests. It appears they haven't quite nailed down what the minimum MacOS version will be and unfortunately as of the time of this writing both MacOS and linux has issues with "secure" cookies from web sites. If your app requires remote authenticated resources, you might run into some more blocking issues until it is fixed...
Memory usage...
Tauri claims to be more memory friendly. My simple Tauri hello world app is using 191.8 megs. Electron is using 203.3 megs. If you look at the graphical test they again are with in spitting distance. The difference is trivial. Both use a lot of memory, but that is very typical of any WebView based app. No matter the framework, if it is using a Webview it is going to be gobbling memory.
Oh no, really, even more issues with Tauri
Sorry, I really hate to be the bearer of bad news.
The current "frozen" version of Tauri does NOT have any API to access cookies from the rust side, and the JavaScript side is unable to see any cookies that are marked "HTTP Only". So there is absolutely no way to capture any authentication cookies to reuse at a later point or on a background thread / service worker or to save for a later startup of the application. In addition the current version of Tauri's Webkit on Mac and Linux has issues actually recognizing cookies marked as "Secure". So overall Tauri and Cookies are currently not very friendly with each other at this point. Now granted this only impacts any apps that need remote resources (assuming the CORS issue isn't already blocking you), but it does eliminate a number of apps that people might want to do...
This brings up the next issue with Tauri. To try and make the apps really small they are binding to whatever the existing version of WebKit is on Linux & Mac. If you are running a older version of Linux or MacOS, the app won't run because it requires WebKit to be a certain version. This is similar to the Windows issue, you have to be running a certain version of the OS browser component or the app will not work. On Windws, you can ship the MSI, on Linux it can be solved by distributing as a AppImage, on MacOS (I assume there is a solution for MacOS), in all situations what have you really gained over Electron, at the point you bundle the webview your file size is going to be in the exact same ballpark as Electron as the reason a Electron app is so large is because it bundles a webview.
However, that is unfortunately just the tip of the iceberg of the issues with this design.
The bigger issue, in my opinion, is that WebKit on Linux & MacOS is actually a completely different beast to what WebView2 is on Windows. WebView2, Electron, & NW.JS are all based on the Chromium (& v8) engines. WebKit is what Safari uses. According to wpt.fyi Safari/WebKit has OVER 3,500 broken features compared to the Chromium engine, that is NOT even counting all the JavaScript language issues (certain ES2016+ support or even simpler things like different Date handling) nor does it count all the WebKit CSS gotchas. Unfortunately in this case, A large number of the issues on WebKit are related to things you would actually use in a day to day app. So these are "issues" you will have to have different code for Windows vs Linux/Mac. If you are more curious about this aspect, do a search for "Safari is the new IE6" and see the MANY developer complaints about all the crap Safari makes you jump thru to have a web app that looks good and performs well and is cross-browser compatible with Safari vs Chrome/Firefox. You now also have to unfortunately deal with this exact same issue with Tauri too. This is not something Tauri can fix, without replacing the actual engine, meaning they have to ship a large file on one or more platforms. Either they replace the Windows engine with Webkit (probably their easiest solution), or switch to Chromium on Linux and Mac OS. Tauri, you are dealing with effectively TWO completely different targets that act similar until they don't. This alone makes developing on Tauri a much larger job than the other platforms...
The final issue with this design is that they are seriously beholden to the Webkit team, the Edge team, Apple, Microsoft, and all the different Linux distributions. They have to hope and pray that first the Webkit team (or Edge team on Windows) fixes any browser issues they find. Then they have to wait patiently for these to actually hit the distribution channel. The supply chain for fixes for Tauri is very deep. A really good example is the CORS issue above, first they had to report it to WebKit team, the WebKit team had to decide it was something they wanted to fix (and even when to fix it). So now presuming the Webkit team has actually fixed it, then downstream Apple has to ship it for MacOS (which again is hit or miss on when Apple will decide to ship, another sore point for a lot of developers). On the Linux side I believe the Gnome/GTK team is responsible for the initial source code release. The Debian maintainers have to pick it up and do a release for whatever OS versions they feel it is safe for. Then it has to trickle up to Ubuntu and Ubuntu has to decide if it is safe to distribute in which versions of Ubuntu, then other distributions based on Ubuntu (like PopOS, Mint, etc) might also have to to push a release if they are also using a modified Ubuntu or Debian version. So you can see a new WebKit version has to go thru at least a couple hands. So despite v2.34 of Webkit being released almost a month ago (Sept 22) Ubuntu is still on 2.32 And based on some issues I read, it is possible the current (and prior versions) of Ubuntu might not get 2.34 for quite a while (if ever) because Webkit apparently bumped an internal api version number and this is kinda like a semver type number so full testing has to be done in the Gnome shells.
So until Ubuntu ships the new WebKit, ALL downstream OS's that are based on Ubuntu has the broken browser that doesn't support CORS properly. Tauri team can't do really anything thing about this. Since you have two different paths for bugs (WebView2 & WebKit) and features they really are fighting an uphill battle. Flutter, NodeGui, NW.JS and Electron for the most part have the ability to own virtually the entire stack, yes they are dependent on some upstream items, but overall because they build the entire thing and distribute the entire thing -- any bugs or features they need they can easily add or fixed in the source code and they aren't totally beholden on a deep supply chain to the extent Tauri is. In my humble opinion, this is the significant Achilles heel of Tauri and I would consider it way more than just a heel -- the ability to get timely fixes out to the developers is completely outside of the Tauri's hands unless they start distributing pre-built webkit builds with the app (which then makes it the exact same footprint as Electron in all factors but using Rust as the back end)
Now if you have been following along on how it Tauri binds, what is the other issue you face with this design? What happens when the Edge team or the Webkit team introduces new bugs into the WebView's?
The Good of Tauri
I prefer to end my mostly negative reviews on a positive note. Tauri's backend Rust is very well built, I was very impressed how easy it was to add new features that were callable by the browser. For example the Rust API has the ability to "eval" into a Webview window so you can pass JS code into a webview from Rust. However, in there JS window api they didn't bother exposing this (despite exposing most the other rust window api to JS), so I can open and close a new JS window, but I can't push any new JS code into it. It took me about 10 lines of rust code to create a new function which I can now call from JS that I just pass the window and the JS code and it and I was done using Tauri's rust window api. Adding features to the runtime that you can call from JS is trivial and well thought out in my opinion. In this they have something very solid to grow upon.
In addition having the ability to package .deb, AppImage (and msi, dmg) out of the box is also well thought out, so many projects make you deal with this part and spend many hours figuring it out or there is an either "eco-system" with multiple ways on how to package Electron apps which again makes you waste lots of time figuring out which one works well. Tauri build and you are done.
Tauri's App Sync is also fairly complete for any flavor that supports hot reloading. For example pure JS doesn't support hot reloading (no rollup/webpack/etc), so it doesn't hot reload on Tauri. With the Svelte JS (after fixing the template issues), It was doing hot sync of all my Svelte changes to my Tauri app live -- only occasionally did it fail, and then I just right mouse clicked in the Tauri window and told it to reload the page and we were off again for a while. Tauri also picks up changes to the rust code and will rebuild and relaunched the full app when I made changes on that side. All in all, if using a framework flavor that supports hot reloading, Tauri's integration with it works very well and made a very pleasant development experience.
Summary of Tauri
The idea behind Tauri has tremendous merit, trying to reduce the application size is a noble goal. Using Rust as the backend engine with its quick ability to add new commands is just friq'n awesome. I have to say I was very impressed by this ability. However, by not shipping a browser in the app by default they have created a support and technical nightmare in multiple areas that none of the other projects even have to remotely deal with. The long tail of getting actual WebView fixes to each of the platforms, is going to hurt a lot. Every new WebView release from both the Edge and the Webkit team also have the potential of breaking your already deployed applications on that platform. And finally the inability to code once and have work everywhere is going to be a killer issue for them. When simple things like this:
let dt1 = new Date("2019-01-01Z00:00:00");
let dt2 = new Date("Tue, 01 Jan 2019 10:00:00 Z");produce different results between Linux/Mac, and Windows, the developers job just got a significantly more complicated and fraught with perilous bugs and time pits -- all of these issues are something none of the other stacks I reviewed have to deal with.