Notes on two directions for ED4's UI that I'm unlikely to continue on.
One is to start a desktop app with a full-screen webview (for the app UI). The other is writing the tabbed browser-like shell of ED4 in a compiled language (like Go or C++) and loading the contents of the tabs as regular webpages (by using webviews). So it would load URLs like http://localhost:9000/ui/image_editor and http://localhost:9000/ui/settings etc.
In the first approach, we would start an empty full-screen webview, and let the webpage draw the entire UI, including the tabbed shell. The only purpose of this would be to start a desktop app instead of opening a browser tab, while being very lightweight (compared to Electron/Tauri style implementations).
In the second approach, the shell would essentially be like a 2008-era Google Chrome [1], that's super lightweight and fast. And the purpose of this would be to have a fast-starting UI, and provide a scaffolding for other apps like this that need tabbed interfaces.
Realistically, neither of the two approaches are actually really necessary for ED4's goals [2]. It's already really fast to open a browser tab, and I don't see a strong justification for the added project complexity of compiling webviews and maintaining a native-language shell. For e.g. I use a custom locally-hosted diary app, which also opens a browser tab for the UI, and I've never once felt that its startup time was too slow for my taste. On the contrary, I'm always pleased by how quickly it starts up.
I don't really care whether ED starts in a browser tab or runs as a dedicated desktop app. I just want ED4's UI to be interactable within a few hundred milliseconds of launching it. That's the goal.
---
[1] To be honest, the second approach is an old pet idea of mine (from 2010), of writing things like IDEs etc in a fast, lightweight tabbed UI (like 2008-era Chrome), back when IDEs used to be massive trucks that took forever to load (Eclipse, Netbeans, Visual Studio etc). Chrome was also very novel in writing the rest of their user interface in HTML (e.g. Settings, Bookmarks, Downloads etc). So this is more of a pet itch, rather than something that came out of ED4's project needs. I might explore this again one day, but it doesn't really matter that much to me right now.
[2] Another downside of the second approach is that it prevents ED from being used remotely from other computers via a web browser.