| Because you're thinking of it backwards. Users have known for decades that they can click an icon, a window will appear, and that's the "application" they're interacting with. This is culturally ingrained as the basis of graphical operating systems (even mobile!) and it's a standard people want to continue meeting regardless of the underlying technology they use. It just turns out due to historical reasons, in 2024, "the web" has the most easy-to-get-running cross platform UX system available, where you can produce an icon that people click, and it opens the app. That's basically the long and short of it. At the end of the day most of the stuff you mentioned doesn't matter because these are, from the beginning, designed as applications that use the web as a way to deliver UI more than anything. Things you mention like back buttons (requiring you to design around stateless hypertext APIs rather than what would be local RPC, and which may be better handled inside the system anyway with e.g. its own undo system) or "browser history" either have large design consequences, or just don't make any sense at all. To be clear, it's very useful in some cases to have the design you describe (true client/server architecture), and underneath it all Tauri does something like that. But it alone can't fulfill all the use cases something like Tauri or Electron aim to. > The daemon can talk to all the system APIs it needs to. That's not the problem, it's the impact on the downstream design, like the fact such a daemon can't cleanly interact with the native windowing context of the (existing) browser or operating system without duplication. You cannot add a proper system menu bar or global shortcuts to the design you described in any way that won't either be sucky and fiddly, or just outright reimplementing what Tauri already does anyway. Or consider alt tabbing and wanting to dial in on a specific app window. There are tons of small things like this that do not work. |