TLDR; I'm keeping an eye on using LibWeb instead, which promises to be less bloated

-------------------------------------

Honestly, we're solving the wrong problem by using something like Electron, webit, Tauri, etc. We're aiming for perfect feature parity with web browsers.

Instead, I want a good way to declare my UI in a subset of HTML, a subset of CSS and optionally a subset of Javascript. That's it, as far as web support goes. I don't need support for 1999 HTML/CSS, or special cases for animation in CSS, etc.

What I actually need for native applications is support for desktop/OS integration. Things like taskbar/panel icon control, notifications (not just toasts), access to the file system that doesn't use Javascript inside node.js, running tasks in the background independent of the GUI (after the GUI is closed, I expect the browser engine to end, freeing up all that RAM).

Striving to maintain feature parity with actual web-browsers eats up a lot of dev effort, so instead of targeting a sane subset of HTML, CSS (and optionally Javascript) it's simply easier to use an existing browser engine, which brings in the bloat and difficulty.

"Perfect is the enemy of good" has never been truer: I don't need everything that webkit, chrome, servo, etc provides when writing a native application, but "bloated" are the only options.[1]

Personally, I'm waiting for some free time, or a week off, to look into LibWeb (the SerenityOS engine, currently used by Ladybird browser). I think that creating a simple FFI around it is probably a better use of my time than doing the debug dance with Tauri and similar; at the end of the dance I'll still have a heavily bloated thing tied to an engine better suited for writing browsers than for writing apps.

---------------------------

[1] Not sure where Sciter lands on this.

Electron vs. Tauri