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.
|Platform||AppImage File Size||Hello Memory AppImage||Hello Memory Unbundled||Graphic AppImage||Graphic Unbundled|
NodeGui probably was my favorite contender based on the site's marketing materials. Node w/ QT -- It had me totally sold! However, like Tauri the NodeGui base library is very early, lots and lots of missing widgets. Fortunately you have full access to the Node.js API and all the NPM modules, so in that it has considerably more ability than Tauri right out of the box. However, it is unlike Tauri in stability -- I have totally lost count the number of times I have crashed my app during development or just plain usage. How frequently something doesn't work, widgets or widget functions are non-existent is another issue you run into frequently. NodeGui currently is more of a prototype of what can be done.
This is one of the few projects that I'm reviewing where I've actually sent a couple PR's in to fix issues. I really so badly want it to be solid, so adding QTableWidget and a slew of other features was in my best interest while I was playing with it to see how it all worked. The code layout is fairly well setup, and if you know any C/C++ code, it is pretty easy to expose more QT API features or fix issues. And it took a couple hours to add and test the entire QTableWidget code.
This also is the one of the two projects that requires its own custom node, called "qode". Qode is actually a fork from Yue's Yode. it shares using Yoga, and having a custom event loop. However, that is where the sameness stops. Qode is QT, and Yode uses is its own custom Yue visual library.
Plain and simple, it follows QT API to the letter, which doesn't make anything easier. It does make grabbing examples out of the actual QT docs and convert it to JS easier. The QT api is very verbose and not, imho, terribly developer friendly. Me, I want something like
<strong>window.title = "Hi"; console.log(window.title);</strong> to assign the title, and read the title. QT, and NodeGUI no, we can't make it that simple.... let use window.setTitle(value)/windows.getTitle() or perhaps it is window.setProperty('title', value) everything is not always 100% obvious and frequently requires trips back to the docs to figure out which way is the proper way.
NodeGui is fast, in fact of all the projects I've built this one is the three fastest while running, it Node-GTK and Yue all are speed demons. I love the speed of most components. I can have tables with thousands of rows and it is fast to scroll, sort and do other things to the data in the table. Now unfortunately, clearing the table will simply just crash the app, so you have to use the slower method of deleting each row individually. It is things like that, which makes NodeGui frustrating to use. You never know which exposed QT Api will just crash the app, the good news is almost all crashes are consistent -- you do X, Y, then Z and it will always crash or perhaps just Z will cause it to crash.
NodeGui not only uses the most memory of the bunch and it also leaks memory. In the more recent versions of NodeGui clicking a menu item still does trigger the menu code, but then that specific menu item has about a 80% chance of disappearing from the menu. I suspect it is also memory related (or specifically GC related), but I have not spent the time to track it down. So if you are worried about memory usage, at this point NodeGUI is not a app for any long running applications.
The NodeGUI project actually has some serious long term potential, and I am personally using it for one of my own internal projects as it is a very fast system and has enough features to allow me to do everything GUI wise I need. However, it is no where near being ready for a consumer facing app, it is just too unstable. I really hope in the future this changes...