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
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 |
Wrapping Up
When I started this series, I had extremely high hopes for Tauri and NodeGui, and actually had a very active dislike of Electron and NW.JS applications. I was on the exact same band wagon as most the internet. Huge fat apps that waste memory === BAD. I still believe it, but based on the research, other than Node-GTK, I don't see any way to make a cross platform heavy graphical desktop apps QUICKLY. Seems to be a trade-off, quickly build via Electron/NW.JS, or memory efficient via Node-GTK, but take you probably five to ten times as long to build your app. (Small update: I started a project called Node-GTK-Svelte, which allows Svelte to drive GTK using html elements)
Doing the actual research and building several test apps via different frameworks really opened my eyes to the reality. If Flutter can't do better than Electron and it has full access to everything including the entire rendering pipeline, then is a Web interface really that bad for a complex graphical app? Most interesting question!
I had totally bought into the hype of Tauri, but now looking back it should have been obvious if it is using a WebView it will gobble memory, nothing Tauri, NW.JS or Electron can do about that.
The NodeGui results were also very striking, it has zero Webviews in the app, but somehow it still managed to use more memory then all the other platforms. Now, part of this I suspect is the memory leaks, but I seriously expected much better memory usage for it since it is using the QT library for all display.
Where do we go from here?
That is a really good question, I love my NodeGui app, and it works very well for my personal use and I have no issue restarting it several times as it is fast and it is easy to add new features.
I was also very impressed with Node-GTK, but then GTK is the primary tool set on most Linux desktops, and probably installed on the vast majority of Linux desktop machines even those running a KDE based desktop system, so it doesn't surprise me that it was one of the three fastest running apps.
I was tempted to review .NET as it qualifies, but its runtimes can be quite massive and sometimes a real pain if you don't have them installed. So at this point, I think I'll leave that one alone.
At this point I'm to going to play a lot more with NW.JS, and see what happens if I pre-reduce all the images to 200x200 to see what the memory usage is and how it compares to Node-GTK.
I am very eager to hear from all my readers on if you have any other cross platform ideas to investigate. It must support all three major platforms, Linux, Mac and Windows.
Update (Nov 4th)
Shortly after writing these blog posts I decided to see how well I can map Node-GTK to components to allow making the app rapidly. Well I have some really cool news to share in my next blog post.
Really interesting article. I would suggest taking a look at Fyne, a cross-platform GUI framework using Go. I'd be curious how it compares.
https://fyne.io/