Is there any hope that Tauri could use something else as browser on linux? Something based off firefox or chromium would be ideal... That would solve all the problems I have with it
Tauri 2.0 Release Candidate
51–60 of 101 posts
Re: Tauri 2.0 Release Candidate
#52One big difference between tauri and electron is that tauri can deliver to mobile, from my understanding.
Is there an hybrid way to deliver with tauri on macos and windows, but electron in linux?
Re: Tauri 2.0 Release Candidate
#53Earlier quoted context omitted.
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?
When it comes to a non-hosted web app most non-technical users would have no concept or ability to run a local web server whereas “install this app” is something they’re familiar with.
I’m talking from a position of “I have an app that I want to distribute to a population of end users.” If that population happens to be technical your solution would likely work fine. As well if you’re not distributing apps to end users you can do what’s right for you. But if you are you have to meet your users where they’re at.
As well operating outside of the browser has the advantage of OS integration (tray access, alt tab support, etc).
Re: Tauri 2.0 Release Candidate
#54I've been following tauri for a bit. It seems very cool and interesting but I've always wondered - what are the use cases for putting your app in a webview instead of using the browser? Everything I've thought of would work just as well.
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…
Because you're thinking of it backwards. Users have known for decades that they can click an icon, a window will appear, and that's the "application" they're interacting with. This is culturally ingrained as the basis of graphical operating systems (even mobile!) and it's a standard people want to continue meeting regardless of the underlying technology they use.
It just turns out due to historical reasons, in 2024, "the web" has the most easy-to-get-running cross platform UX system available, where you can produce an icon that people click, and it opens the app. That's basically the long and short of it.
At the end of the day most of the stuff you mentioned doesn't matter because these are, from the beginning, designed as applications that use the web as a way to deliver UI more than anything. Things you mention like back buttons (requiring you to design around stateless hypertext APIs rather than what would be local RPC, and which may be better handled inside the system anyway with e.g. its own undo system) or "browser history" either have large design consequences, or just don't make any sense at all.
To be clear, it's very useful in some cases to have the design you describe (true client/server architecture), and underneath it all Tauri does something like that. But it alone can't fulfill all the use cases something like Tauri or Electron aim to.
> The daemon can talk to all the system APIs it needs to.
That's not the problem, it's the impact on the downstream design, like the fact such a daemon can't cleanly interact with the native windowing context of the (existing) browser or operating system without duplication. You cannot add a proper system menu bar or global shortcuts to the design you described in any way that won't either be sucky and fiddly, or just outright reimplementing what Tauri already does anyway. Or consider alt tabbing and wanting to dial in on a specific app window. There are tons of small things like this that do not work.
Re: Tauri 2.0 Release Candidate
#55One big difference between tauri and electron is that tauri can deliver to mobile, from my understanding. Is there an hybrid way to deliver with tauri on macos and windows, but electron in linux?
Any reason why? Tauri works fine on Linux as I understand.
Re: Tauri 2.0 Release Candidate
#56Earlier quoted context omitted.
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.
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.
Re: Tauri 2.0 Release Candidate
#57Earlier 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…
Why are you using WASM? Tauri lets you call native Rust code.
Re: Tauri 2.0 Release Candidate
#58One big difference between tauri and electron is that tauri can deliver to mobile, from my understanding. Is there an hybrid way to deliver with tauri on macos and windows, but electron in linux?
Any reason why? Tauri works fine on Linux as I understand.
Multiple posts about WebKitGTK webview used on Linux being a source of problems.
Re: Tauri 2.0 Release Candidate
#59Earlier quoted context omitted.
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…
Why are you using WASM? Tauri lets you call native Rust code.
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 webviewnative 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
Re: Tauri 2.0 Release Candidate
#60Earlier quoted context omitted.
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.
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.
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.