Consider using Tauri instead of Electron

[motin]

As mentioned in open-webui/open-webui#8262 (comment), I have packaged Open WebUI using Electron and found it rather clunky to work with and leading to large binaries. Also referenced in the comment is @reecelikesramen's https://github.com/reecelikesramen/open-webui-desktop which is a Tauri-packaging of Open WebUI which demonstrably is able to bundle the entire Open WebUI frontend in a mere 14.2mb binary. Using Tauri also may allow this repo to host both desktop and mobile apps, and we know at least two community members that have offered to contribute Tauri-packaging (Reece and me :)) to Open WebUI.

There are of course good things with Electron as well (and Ollama uses it for their Mac app for instance), but given that now (very early) in the project is the time to decide the framework for packaging, it'd be great to hear how you arrived to the choice of Electron, and if that choice is open to reconsideration?

[tjbck]

As much as I can appreciate the performance and smaller binary sizes offered by frameworks like Tauri or Wails, Electron provides critical advantages that are hard to overlook for a project like Open WebUI. Here are the key reasons behind the choice:

1. Consistent Rendering Across Platforms: Electron bundles a specific version of Chromium, ensuring pixel-perfect rendering and uniform behavior across all operating systems. This is crucial as Open WebUI increasingly leverages cutting-edge browser APIs that may not yet be stable across bundled or native WebViews in Tauri or Wails.

2. Simpler Development Stack: By keeping the stack limited to JavaScript (and Python for backend components), Electron avoids the need for Rust or Go, which can alienate contributors unfamiliar with those ecosystems. A JS-first environment aligns better with the majority of web developers, fostering more community contributions.

3. Community Ecosystem: Electron boasts a mature ecosystem, extensive documentation, and a wide array of plugins, which reduces friction during development and enables faster iteration for features that target multiple operating systems.

4. Battle-Tested Stability: While Tauri and Wails are evolving, Electron has been field-tested in projects like VS Code, Slack, and Discord. Its widespread use ensures robust support for edge cases and compatibility issues that arise on complex desktop environments.

5. Future-Proofing: As Open WebUI grows and adopts newer technologies, Electron's locked Chromium engine ensures confidence that features won't run into discrepancies due to varying WebView implementations or platform-specific quirks.

While Tauri and other frameworks are undoubtedly exciting, the goal is to prioritize reliability, consistency, and accessibility for contributors, especially in the early stages of Open WebUI's development. These criteria make Electron the better choice for our long-term vision.

With that being said, would love to see a community version in tauri!

[reecelikesramen]

As the author of the original Tauri desktop port, I am behind an Electron version. Here's why:

• I only chose to work with Tauri out of interest in the framework.
• There was a severe lack of reliable documentation for certain build errors, permissions, capabilities, and other features. The internet is splintered between v1 and v2 documentation given v2 is hot off the press; it was only released in October.
• The small binary is nice, but the point @tjbck makes about the rendering is very important. Also, if the desktop app bundles a local backend server and Ollama instance for less technical users (undecided on these items right now I think) the binary size will already be larger anyway and a Chromium instance will be relatively negligible.
• Electron allows bundling OS-native window code just like Tauri; See VS Code's Mac specific interface.
• Most app logic lives inside the frontend and can be moved relatively seamlessly to Electron. Some should be moved to the backend, but iterating Rust code with Tauri v2's really long build times was painful.

[motin]

Stable clunkyness it is then :) Thanks for laying this out so clearly both of you!