[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?