The advantage of electron was that the client side scripts in the renderer and the backend use the same language and the two can share data easily (although not so much these days given disabling that is done for security). Whenever I use electron, I have communication between the backend and the renderer client side scripts go over a socket. This made the code fairly portable, such that I was able to do proof of concept port of an electron application I wrote for use in health care to a WebKitGTK version written in around 100 lines of C with the backend nodejs process still running. Interestingly, this cut memory usage in half, with half of the remaining memory usage being the nodejs process. I assumed replacing nodejs with pure C code would lower memory usage even further, but this ran on a CM4, so there was no pressure to reduce memory usage, and I abandoned the C port because using electron as is was more convenient.

There really is not much special about electron or tauri. You can do the same thing in any language that can use WebKit as a library.

TBH we are also doing something similar, where we have a separate process that creates a winit overlay window and draws the remote cursor with wgpu, this process also handles screen sharing and remote control.

The process with the tauri backend are communicating via a socket, so you could say it doesn't really make a difference if it is electron or tauri in the end of day.

Though we are thinking of using egui for the rendering process in the future and then we could have the opportunity to integrate it in the main app (tauri has an egui integration for v1, which unfortunately is broken for v2).