We actually haven't rolled out cross platform support yet with the Tauri version, so we will see how that goes. Our UI needs are simple, luckily. What kind of rendering differences were you seeing with Tauri? Was there one platform that worked the best/worst for your app? We'd love to support Windows next.
With the Electron version of the app, we had issues running our bundled binaries on Macs with Intel chip. That caused us so many headaches that we decided for the rebuild on Tauri that we wanted to focus on one platform first (Macs with Apple chip) before supporting other platforms.
We went with Tauri 1.4 and no issues so far. Will have to check out the docs for 2.0 migration and see what that looks like.
I worked with an open-source project that uses Tauri 1.x and their migration has been blocked with issues for months. It was a nightmare for the span I was involved in, and it looks like it hasn't moved forward since I stopped.
In particular, rendering and crashing issues specific to Linux have been blockers, but Tauri 1.x also has other rendering issues on Linux that 2.0 fixed. There's little to no guidance on what's causing the stability and new rendering problems or how to fix them.
The app I worked on was a launcher that installed and managed content for an app, and the launcher invoked the app through command-line flags. Those flags arbitrarily fail to be passed in Tauri 1.x but work as expected in Tauri 2.x, but nobody we asked about it knows why.
Also the multi repo nature of the Tauri project, and the changes to this structure between 1.x and 2.0, makes migration hard.
Tauri 2.0 migration can potentially give you some more performance benefits, because they've greatly enhanced the JS-Rust bridge especially when you're moving lots of data.
We picked egui instead of tauri because we had more rust skills than web skills. Other than rastered text, whoch I can't find any customers who actually care, are there good reasons to go tauri? It seems widely used, but also widely complained about.
I think the main good reason to go Tauri is getting access to the full JS ecosystem, especially if you already have experience with that. If you don’t not really any reason to complicate your life I think.
My app needs wysiwyg editors, and JS is full of them.
Who is 'we'? :)
Would you have any webpage or product info, possibly with screenshots?
We're building an in-house DCC with egui so I'm curious.
No, our customers use it internally. Not even sure if they will end up deploying it as a website or a windows application. Which is an advantage of egui i suppose. I just picked it because I don't know any html or javascript and it does all that stuff for you, so it is just a rust app you can browse to. My team didn't know much more JavaScript than I do and they seemed to like it fine, but not as well as something declarative, which it is not.
Nothing flat out broke, but I am developing and dogfooding on a Mac, so I get visual QA for free on that platform. When I tested my app on a Windows machine, I noticed several UI regressions that looked/felt really janky. I didn't get as far as testing a Linux build, but I assume I'd find more issues there.
I can't remember why I wanted to migrate to 2.0 now, but there was a nice-to-have that I couldn't do in 1.4. I ended up abandoning the 2.0 migration after a slew of cryptic errors, took a step back, and decided I'd be better off using Electron for my project. My app is at heart a rich UI text editor and none of the computation is that expensive. With all the value add coming from the interface, optimizing for consistency there feels right.
Interesting you ran into UI regressions on Windows. I'm looking forward for us to get to that point where we can test on a Windows and see what changes...hopefully it's smooth.
With Electron's UI powered by the same browser across platforms, you end up with a much more consistent experience. Makes sense to optimize for that.
> I recently went the other way (started a project in Tauri, moved to Electron) because of frustration with rendering differences between the web views employed on different platforms.
This is our #1 frustration with Tauri. The OS-provided system webviews are not stable, repeatable, consistent platforms to build upon.
Tauri decided that a key selling point of their platform was that Tauri builds won't bundle a browser runtime with your application. Instead, you wind up with whatever your operating system's browser runtime is. Each OS gets a different runtime.
Sounds nice on paper, but that has turned into a massive headache for us.
Safari and Edge have super finicky non-standard behavior, and it sucks. Different browser features break frequently. You're already operating in such a weird way between the tight system sandboxing and CORS behaviors (different between each browser), the subtle differences are death by a thousand cuts. And it never seems to stop stacking up. These aren't small CSS padding issues, but rather full-blown application behavior breakages. Even "caniuse.com" is wrong about the compatibility matrix with built-in web views.
To be fair, we're using advanced browser features. Animation, 2D contexts, trying to do things like pointer lock. But these are all examples of things that are extremely different between each web view.
All of this has doubled (quadrupled - with dev and prod builds behaving so differently! - but that's another story) the amount of physical testing we have to do. It takes so much time to manually test and ship. When we were building for the web, this wasn't an issue even if people used different browsers. The webviews have incredibly different behavior than web browsers.
Their rationale for using OS-provided system webviews instead of a bundled runtime baked into the installer at build time is that it would save space. But in reality all it has done is created developer frustration. And wasted so much freaking time. It's the single biggest time sink we have to deal with right now.
We were sold on Tauri because of Rust, but the system browser runtime is just such a bad decision. A self-imposed shotgun wound to the chest.
The Tauri folks have heard these complaints, and unfortunately their approach to solving it is to put Servo support on the roadmap. That's 1000% not the right fix. Servo is not even a production-ready platform. We just want Chrome.
Please just let us bundle a modern chrome with our apps. It's not saving anyone any headache with smaller programs and installer sizes. Games are already huge and people tolerate them. Lots of software is large. It's accepted, it's okay, it's normal. We have a lot of space, but we don't have a lot of time. That's the real trade off.
I want to use Rust. I want to use Chrome.
I hope the Tauri devs are reading this. It's not just from me. This is the general community consensus.
Built-in webviews are not the selling point for Tauri. Rust is.
Why even bother with a browser runtime? It sounds like you have intricate UI needs, so you need a proper UI library. Several options exist.
There are some intangible matters of practicality. The team is more familiar with React.
I tried to use Bevy (since we also use 3D) and that wasn't ready for prime time.
I thought about Iced and Imgui and several other Rust frameworks, but given our experience with Bevy we shied away from it.
We figured we'd be able to move faster and rely on a lot of existing tooling. That's been true for the most part.
> Please just let us bundle a modern chrome with our apps.
please, no.
I wish software companies had to pay the hardware they require for their users, then we would have devs using Rust instead of JS and optimizing using ASM just to save parts of cents per instance. And we wouldn't see companies like MS kill well designed and performed native apps for a electron app
[dead]
> I want to use Rust. I want to use Chrome.
So use Electron and FFI, it's not that hard
Haven't touched Tauri because of the cross platform issues. The major appeal with Electron to me is the exact control over the browser. I'm curious about Rust integration though. I'm guessing they're doing something that provides better DX over something like https://github.com/napi-rs/napi-rs?
> Haven't touched Tauri because of the cross platform issues.
You were wise. That's the biggest issue plaguing the project right now.
> curious about Rust integration though
Tauri is written in 100% native Rust, so you write Rust for the entire application backend. It's like a framework. You write eventing and handlers and whatever other logic you want in Rust and cross-talk to your JavaScript/TypeScript frontend.
It feels great working in Rust, but the webviews kill it. They're inferior browsers and super unlike one another.
If Tauri swapped OS webviews for Chromium, they'd have a proper Electron competitor on their hands.
Sounds easier/more reasonable the other way around. Aren't there already specific libs / bridges for Rust / Electron / Node for performance heavy computations ?
Don’t try to speak for me please. I’m perfectly happy with my app looking mildly different and not weighing 1GB. I’m inclined to believe most people using Tauri do not have your issue.
I don’t quite understand why you have that issue in the first place. The fact they use the system webview is front, left and center on their website. It’s like you decided to use a fork because of the decorations on the back, and now complain that it’s pointy and the developers should just make it a spoon instead.
Because Tauri people advertise it as a complete solution to everything Electron does. But then they act surprised when people have platform difference issues that they don't have with Electron. Tauri is being actively misrepresented and people have good reason to feel duped.
> I don’t quite understand why you have that issue in the first place.
My read on it is that they didn’t understand the implications of using system webviews.
And possibly they expected Tauri would insulate them from cross-system differences without a lot of exploration.
This. We wouldn't have signed up for this if we'd have known.
Tauri needs a big fat warning label.
Is it hard to ship a Rust library with Electron? At least then it's not all C++