Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tauri 2.0 Release Candidate

v2.tauri.app

Post reply on HN
Print view View original

41–50 of 101 posts

Re: Tauri 2.0 Release Candidate

#41

Post by cageface »

Sytten wrote: post #37
dvt wrote: post #34

Earlier quoted context omitted.

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 th…

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 safa…

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.

Re: Tauri 2.0 Release Candidate

#42

Post by theultdev »

runevault wrote: post #29
FFFXXX wrote: post #26

Earlier quoted context omitted.

One interesting usecase is that you can run a tauri app without any webview windows just as a system tray icon and only spawn a webview window when necessary. This kind of makes it way more lightweight but only in some situations (obv. heavily depending on the functionality of the app).

Would this be for a service style app that happens to have a UI when you need to configure it? If so that's an... interesting idea, but considering the UI is less important I'd probably mind it less (as someone who is not a fan of Electron apps).

I built a syncing tool that needed to run in the background with a simple UI to control it.

I used tauri so I could easily make that cross-platform toolbar app.

Some menu items spawn a webview (things like settings), everything else is in Rust.

Re: Tauri 2.0 Release Candidate

#43

Post by [deleted] »

Sytten wrote: post #33

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 Tauri, but I can't recommend it for a startup use until they allow packaging a webview into your build. The amount of time you currently have to spend in debugging each OS/Version combination of bugs is simply untenable. This is scheduled for v3 last time I ta…

[deleted]

Re: Tauri 2.0 Release Candidate

#44

Post by dvt »

theultdev wrote: post #38
dvt wrote: post #34

Earlier quoted context omitted.

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 th…

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.

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

Re: Tauri 2.0 Release Candidate

#45

Post by dvt »

Sytten wrote: post #37
dvt wrote: post #34

Earlier quoted context omitted.

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 th…

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 safa…

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

Re: Tauri 2.0 Release Candidate

#46

Post by nightowl_games »

Sytten wrote: post #37
dvt wrote: post #34

Earlier quoted context omitted.

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 th…

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 safa…

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

Re: Tauri 2.0 Release Candidate

#47

Post by jauntywundrkind »

TheCleric wrote: post #25
jauntywundrkind wrote: post #8

Earlier quoted context omitted.

Can anyone explain what Tauri or webviews offer that makes them a good choice over a local-http-server webapps? Imo, as a user, Webview, no thanks. Local webapps, yes please. There really isn't a good reason for webviews or electron/tauri that I can tell? Why some people love love love native apps, to the extent they'd rather a dressed up webapps is confusing to me. If it's already a webapps, hell yeah give me the us…

You are absolutely the exception there, especially if you are talking about an average low tech user.

I don't have any understanding why that would be though. Even if it is true, is there a reason or is it happenstance / path-dependence?

It seems so inferior to have the same thing but lose access to the browser's suite of tools/capabilities. What could possibly change other people's opinion or what should I use to reconsider my perspective?

Re: Tauri 2.0 Release Candidate

#48

Post by theultdev »

dvt wrote: post #44
theultdev wrote: post #38

Earlier quoted context omitted.

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.

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

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)

Re: Tauri 2.0 Release Candidate

#50

Post by logankeenan »

Sytten wrote: post #33

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 Tauri, but I can't recommend it for a startup use until they allow packaging a webview into your build. The amount of time you currently have to spend in debugging each OS/Version combination of bugs is simply untenable. This is scheduled for v3 last time I ta…

I found that using Axum and bundling it with the Tauri app was easier than using a front end framework to build the UI.
Post reply on HN