3 ms·

We just finished migrating away from Tauri to Electron for our desktop application after running Tauri for 2 years. We are a rust shop so it makes sense to use

• dvt 2y ago
  I also use Tauri for a startup project I'm getting off the ground and I've been extremely impressed. Unless you're doing something extremely non-standard, I'm not sure what edge cases you're seeing. The webviews packaged with modern operating systems are very compliant (essentially Safari on MacOS and Chrome on Windows). The only wildcard is Linux which uses WebKitGTK which does have all kinds of weird quirks (but that's a comparably tiny market sector to begin with). Using OS WebViews, you also get the added bonus of security updates which you get for "free" with OS updates (otherwise you have to handle these yourself). There have been some RCE exploits in Electron, so it's something you need to keep an eye out for.
  • Sytten 2y ago
    Yup this was also our first impression. Wait until you have users (no snark here, but its the reality). We do have around 1/3 of our users on Linux and WebKitGTK is plainly bad. Our application is complex I will give you that, but it isnt just that. Say you want to use WASM you have to check which macos versions you want to support and check the oldest possible webview (it doesn't get updated at the same time as safari), check which subset of WASM that supported, etc. It really is a nightmare of subtitle bugs that are hard and time consuming to reproduce. OS webviews in our findings have a way worse update cycle than us shipping a new version of the app.
    • cageface 2y ago
      This is just the reality of web development. You'd have the same issues if you were developing a PWA. Blaming Tauri for this doesn't seem fair. It sounds like Electron is a better fit for what you're trying to do.
      • atonse 2y ago
        I dunno it feels entirely fair since isn’t one of the benefits of Tauri the fact that it uses your system’s existing WebKit instead of bundling a full chromium? That makes them also use less memory etc.
        • cageface 2y ago
          Right that's the tradeoff. If you need exactly the same environment on multiple platforms and you're willing to pay a high price in memory and disk space then use Electron. On the other hand, if you can work around browser incompatibilities then Tauri will give you a much less wasteful app. Choose the right tool for your use case.
      • Sytten 2y ago
        Not really PWA will use your browser of choice which is likely up to date. Tauri often is run on system with very old webviews like 6-7 years old.
        • cageface 2y ago
          What system has 7 year old web views?
          • Sytten 2y ago
            A lot of people outside rich outside run old computers and like I said webviews usually are the one first released with the OS and dont get updated.
            • bryanlarsen 2y ago
    • nightowl_games 2y ago
      Where can I find more information on what subset of WASM is supported on different mac os/safari versions?
    • dvt 2y ago
      > Say you want to use WASM... Using WASM, unless you're doing it for some really good reasons, seems like overkill for essentially a front-end layer. I think of the WebView in a Electron/Tauri app as comparable to the Qt Framework. It's not supposed to do any heavy lifting, and trying to do heavy lifting in JS suggests a mis-architecting of the app.
      • thejazzman 2y ago
        Using wasm is becoming a very common and practical thing to do, especially with how you can cross compile so much into it. Unless you're just making blogs and content pages, it's just part of writing web apps now
        • pjmlp 2y ago
          Only for those with allergy to JavaScript. It hardly adds anything in performance if there are too many DOM interactions, and if the performance need is due to compute, all modern computers have a GPU.
    • pornel 2y ago
      Why are you using WASM? Tauri lets you call native Rust code.
      • jitl 2y ago
        Sometimes you do just want to use off-the-shelf libraries for things and not need to re-implement them yourself. If you already have a web app you’re building around, it’s annoying to need to rewrite bits of it - especially rock solid 3rd party libraries - unnecessarily. Another consideration is that any webview<->native bridge is going to impose some kind of bridge toll in the form of serialization and message passing (memcopy) overhead. You can call into WASM from JS synchronously, and share memory between JS and WASM without copying. Sync calls from webview to Tauri native code doesn’t appear to be possible according to https://github.com/tauri-apps/wry/issues/454 https://github.com/tauri-apps/wry/issues/454 Finally, security posture of native code running in the main process is quite different from WASM code in the webview. I maintain a WASM build of QuickJS and I would never run untrusted JS in real native QuickJS, whereas I think it’s probably safe enough to run untrusted JS in QuickJS inside a WASM container
      • thejazzman 2y ago
        And abandon the web version of your product?
  • theultdev 2y ago
    I've ran into this trying to use OPFS with Tauri. While it works in Safari 17, it's unavailable in 16 for many users. There's also various UX differences in webviews. It's all fine though, I'd rather have multiple webviews over a bloated app. Used to developing for multiple environments anyways.
    • dvt 2y ago
      > I've ran into this trying to use OPFS with Tauri. I also do file system stuff, and I'm not sure why you would even try doing this from JS when you literally have rust at your fingertips (for example, I use the `native_dialog` crate). Just seems kind of anti-pattern-ish, as JS is not really supposed to have any business logic: it's purely a front-end.
      • theultdev 2y ago
        It's a React Native app. I have plans to use React Native Macos eventually but I use Tauri to wrap the React Native Web build for unsupported platforms (Linux & Mac) and as a fallback if the native apps don't work for the user. I use OPFS on web for the SQLite database store. But yes, I will be writing an adapter using Taurus SQLite plugin to solve this in the long term. Not a huge issue, and wasn't going to be long term anyway, but it did make it go from "you can release this now" to "oh shoot it works everywhere but on mac, now go write an adapter to this 2.0 sqlite plugin with limited docs" And there's perfectly fine reasons to use OPFS in Tauri, it's a sandboxed file system. You may not want to deal with the native filesystem for security purposes (yes Tauri has permissions, but not sandboxing after-the-fact)
• lovethevoid 2y ago
  Have you or your team written about the migration? Would love to read about that more as usually there's a lot to learn from these situations even when you don't make the same move.
  • Sytten 2y ago
    We might do it, I don't necessarily want to push bad publicity on Tauri since I want them to succeed in the end :)
    • lovethevoid 2y ago
      That's very understandable. It can be hard to get people to grasp that it's not a versus competition when these migrations happen, it's all about the compromises (and that's where the fun reading is for me, selfishly!)
• deleted 2y ago
  [deleted]
• logankeenan 2y ago
  I found that using Axum and bundling it with the Tauri app was easier than using a front end framework to build the UI.
• arresin 2y ago
  Exactly my own experience. I like rust and I like the package size. But if I was to build this again I would 100% go with electron. They started working on 2.0 with the docs for v1 in a 10% state. I mostly searched through discord threads for tidbits. It was painful. Expect the documentation for 2.0 to be at 5% for years.