Possible alternatives to Electron

[MorsMortium]

Hi! First of all great job on all your previous work!

I would like to ask how decided you are on using Electron.
This is because you probably know there's a bit of negative preconception about Electron apps, in the GNU/Linux community. (that's where I'm coming from too)

Some parts where native toolkits shine:

• Native look on all desktops (even on Windows/Mac)
• Less resource usage while running
  • Faster running on lower end devices
  • Ability to run on even lower end devices
• Less space usage (especially on Windows where dependencies have to be bundled, but also on Linux with bad packaging)

On the less resource usage I would expand, that I discovered Kando on remembering how cool Gnome-Pie was, and being a bit down with Fly-Pie only working on Gnome, when I thought testing it on the PinePhone Pro, running Plasma Mobile with Wayland. If there was such a menu, always running and frequently opened, on a phone like that, Electron would drain the device a good bit.

I also got even a bit more excited, when seeing the name start with a K, but then I saw Electron, and now I'm writing this.

What I would recommend is either QT or GTK (or some offshoots like libadwaita or Kirigami)

Anyway, your project, your decision, just thought I'd ask. Also, good luck with it!

[Schneegans]

Hi there! Thanks a lot for this question, at some point I'll have to write a blog post on this issue, as it will pop up frequently, I guess 😄 I have indeed considered using various toolkits. I did a thorough test using Rust+Gtk4 and looked into iced, slint, tauri, and Qt (either using C++ or Python). All of them could be used, I guess.

The Drawbacks of Electron

So why did I choose Electron? Here are some potential drawbacks I considered:

• Large application bundle size. The package will come with an overhead of about 100 MB when compared to the other toolkits.
• Large RAM usage. Also during run-time, Kando will require about 100 MB more when implemented with Electron.
• Non-native look & feel. That's definitely a valid point, but it does not matter for Kando. Kando will not be a traditional application anyways. There are no dialogs, no windows, no drop-down menus, etc...
• Worse run-time performance. I am pretty sure that this is actually not an issue. I did some tests and I found that especially the 2D rendering of many animated shapes (which is very important for Kando) is extremely well optimized. It performed similar to Qt for me. I would expect a superior performance of native toolkits when it comes to large data processing, however this is not required for Kando. And even then, I could put the number crunching into native C++ modules which are well supported by Electron (in fact, the Kando prototype already uses C++ modules to access some host APIs). The only real issue I could see is start-up time. The Kando prototype requires about one or two seconds to start while a simple Qt application starts in a fraction of a second. But this is no issue either, as Kando will start automatically (like a daemon) and then wait for menu-open requests.

The Benefits of Electron

On the flip side, there are a couple of advantages which all boil down to one key advantage: Much higher development speed with Electron. I only have about one hour / day to spent on my open source projects. So this is extremely important! In just a few weeks (read: a couple of hours), I was able to set up a prototype which basically feels like Fly-Pie interactions-wise. Including touch and stylus support, fluent animations and neat transitions. With the other toolkits, I would still be trying to open a transparent top-level window when a hotkey is pressed (that is a bit exaggerated, but you get the point). Here are some of the reasons:

• Hot-reloading. Edit a source file and the running app will instantly reflect the changes.
• CSS transitions. Setting up rich and fluent animations is done with just a few lines if code. And it will be very easy to support custom themes. This would be way more complicated using the other tools. Maybe QML would be an option here, but the number of potential contributors is still much larger with CSS.
• Huge ecosystem and excellent documentation.
• Easy bundling and publishing. With Electron, I can easily create packages and installers for various distributions. Have you tried creating a windows installer with auto-update functionality? Or a flatpak package? All of this takes a lot of time if done from scratch.
• Very large user base which could contribute plugins and themes. I am sure that there are much more developers confident in JavaScript and CSS than in Rust or Qt.
• Last but not least, I would have to learn Python+Qt (or Rust). While this is no problem in itself, it will take time as well.

The Bottom Line

So using Electron for Kando does not seem to bring any drawbacks in terms of look-and-feel nor does it have a significant impact on the run-time performance. On the other hand, it brings a couple of important benefits! IMHO, it all boils down to the trade-off between memory usage and development speed. I think that it is well worth the couple of MB's. Is an additional 100 MB really an issue nowadays? I don't think so. After all, when choosing another toolkit, there would be a very realistic chance that Kando would never exist.

I think if the rendering performance on Linux was better, tauri would be the perfect choice. It would combine the fast development cycle with the low memory footprint. However, it may not be suitable for Kando right now, but it may become suitable in the future! So I will regularly check if this changes. Porting from Electron to tauri at some point shouldn't be too hard.

[eMPee584]

Just tried this and have to admit, didn't know electron could even be used in this way, with the shaped window and fluent animations. It really has (on a modern desktop) splendid performance, but it does use quite a bit of memory:

Can be monitored live by running it via systemd-run --user --scope --slice kando.slice kando and in another terminal watch -c -d -n 0.2 systemctl status --user kando.slice ..
Your conclusion & priorization is entirely valid though: UX 1st ..
Tauri seems cool as well.. electron/electron#673 doesn't look like it's going anywhere anytime soon but that wouldn't solve the memory issue anyways.

[Schneegans]

Thanks for these commands, they are pretty good for watching the memory consumption! At one point I should create a CI job which checks for regressions based on these numbers.

Anyways, thanks to #212, I just realized that a good portion of the memory consumption comes from the five included tutorial videos. I just pushed a commit to main which ensures that the videos are only loaded when they are shown for the first time.