[dvt]

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]

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.

[dvt]

> 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]

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]

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.

[cageface]

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.

[thomaslord]

I think what Tauri is getting blamed for is the decision to always use the native web renderer, which IMO is fair because that was a design choice they made.

Personally I think the ideal scenario would be allowing developers a choice between: 1. Use the native OS renderer 2. Bundle a specific version of some renderer (most likely Chrome) 3. Use a shared library for the renderer (this gets a little trickier with sandbox-based security models, but allows Tauri to ship a renderer without ballooning the bundle size of each individual app)

As a user, I'd be happy with a combo of #1 and #2. Use the native OS renderer by default, but allow me to install a "known good" renderer if I run into problems. Since it sounds like MacOS and Windows both ship better native web renderers than Linux this would likely be an option mostly used by Linux users, who are on average more willing to poke around in the settings to enable a compatibility option.

[cageface]

Sounds like this is the plan for version 3, right?

[atonse]

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]

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]

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]

What system has 7 year old web views?

[Sytten]

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]

Tauri won't work with those. For example, on Linux, the .deb has dependencies on a version of webview that's not available on Ubuntu 20.04.

[nightowl_games]

Where can I find more information on what subset of WASM is supported on different mac os/safari versions?

[pornel]

Why are you using WASM? Tauri lets you call native Rust code.

[jitl]

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

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]

And abandon the web version of your product?

[theultdev]

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]

> 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]

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)