About this Series
Over the last several months I have been testing several HTML/CSS/JavaScript based cross platform development systems. When trying out a new technology, I spend several full days playing with it learning the in's and out's. Its awesomeness and its gotchas. I am going to go over Tauri, NodeGui, Flutter, NW.JS, Yue, Node-GTK+ and Electron over the next couple posts. (These link to the actual tool sites, not to any of my blog posts on them)
The reason I am creating this post is that I really wish I had found a set of posts like this to help choose a direction, before I started my all playing around. So this is a just a simple heads up to developers on the current multi-platform development. There are a couple other things I might investigate in the future -- if you have suggestions please feel free to leave a comment.
Flutter is the odd man out in this, as it isn't JS/HTML. With Kracken, in the near future it could be a viable method to deliver HTML or JS based apps to multiple systems.
Raw Stats
I have a couple types of apps, the graphical app is like a heavy graphic scroll list app with lots of images and can keep scrolling forever. Since I added this at the end of the my testing, I didn't create an AppImage for NodeGui but I plan on revisiting this in the future once I can get the Flutter Kraken working on Linux as right now these values are from just plain Flutter apps.
Be forewarned, It is possible that the unbundled memory numbers are off, as it is very hard to track shared memory that an app is using, since memory will be allocated in shared processes and libraries for your primary process but overall I believe they are relatively accurate as I used a couple methods to try and track it.
| 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 |
Linux AppImage Why?
I'm also primarily focusing on the Linux AppImage as they are universal and work on virtually every single Linux system and are sandboxed, so that the "actual" memory usage can easily be determined since the memory required for the app isn't being hidden elsewhere because some components and libraries are being shared by the OS. An AppImage will use more memory than a deb install, since everything including shared memory is sandboxed.
Bundling an AppImage is one of the safest way to bundle an app for Linux do to the vast number of versions of kernel, support libraries, and basically everything in multiple linux eco-systems. Using an AppImage you get basically everything needed included in the AppImage file. So the image will work as well on older versions of the OS and even on KDE (and other non GTK window managers) based systems without them having to find, build or install other dependencies. There are several other formats for Application images like Snap & FlatPaks, but we will only deal with AppImage as it was the one that I could easily get working with everything and it is a fully portable app (meaning you can just copy the full AppImage file to another computer and it should run without any installation).