Live data from Hacker News

Show HN: I rewrote my Mac Electron app in Rust

desktopdocs.com

261–270 of 465 posts

Re: Show HN: I rewrote my Mac Electron app in Rust

#261
post #234

Earlier quoted context omitted.

Have you actually tried deploying to webkitgtk ever? Good luck "testing" your video conferencing app on webkitgtk - it doesn't support webrtc! It is still useful to test your error page I suppose. Note that this is one example among many of missing features, bugs and/or horrible performance. Here's a preview: no notifications, no :has, no TLA. (Not blaming the epiphany devs for the situation here to be clear)

Ahem https://github.com/tauri-apps/tauri/discussions/8426

That's a significant amount of workaround for something that "just works" elsewhere (and if I'm reading correctly doesn't work under Wayland).

It proves what everyone knows: that there's no reason WebRTC can't work in Tauri/Linux environments.

It also proves the point here: there are legitimate issues with the system-provided webview approach that are not always apparent.

Re: Show HN: I rewrote my Mac Electron app in Rust

#262
post #62

Earlier quoted context omitted.

The promise of Electron is the version of chrome you develop on is the version that ships with your app. If it looks right on your machine, it looks right on whoever is running it. This is much nicer than when doing web development and deciding which browsers/browser versions to test and support. Tauri does not bundle chrome with your app. This makes the bundle size much smaller. But the tradeoff is you end up render…

Does anyone actually choose to ship an Electron app instead of a web app in order to benefit from UI consistency? Most Electron apps I've seen either share a codebase with a web app that's also made available (so the codebase still has to be tested cross-browser), or else can't be web apps because they need full filesystem privileges or otherwise don't work with the browser's security model.

Yep, we use Electron specifically because it gives us a locked-down version of Chromium with a consistent WebGPU implementation. Without that, we're stuck dealing with whatever browser version the user happens to have, and that completely wrecks the stability of our GPU pipeline.

Re: Show HN: I rewrote my Mac Electron app in Rust

#263

Earlier quoted context omitted.

That's part of it, but also Tauri uses Rust on the backend while Electron uses Node. Electron is way more mature with a larger developer community, but Tauri keeps gaining momentum. If memory safety, bundle size, and performance are important to you, Tauri is a nice choice. Electron is not bad but there's a reason there are so many new players.

> If memory safety But Tauri is just a wrapper around WebKit, which is written mostly in C++.

It has very easy binding for your own rust code, so anything you actually care about (your own code) will be memory safe.

Re: Show HN: I rewrote my Mac Electron app in Rust

#264
post #152

Earlier quoted context omitted.

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.

Re: Show HN: I rewrote my Mac Electron app in Rust

#265
post #14

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. Have you run into any cross platform UI bugs since you switched? It looks like your UI needs are pretty simple while computation is complex so the extra QA tradeoff would still be worth it for you. I'm just wondering if my experience was…

I had the exact same experience and switched from Tauri 2.0 to Electron after a month. No only were there UI inconsistencies, but Safari lags behind chrome with things like the Popover API and the build/codesign/CD ecosystem for Tauri is incredibly scattered. When I was using it, IAPs were still not really an option for Tauri or at least I could not find any docs or resources about it.

Same here. We went with Electron mainly for consistency and stability. The larger bundle size wasn’t an issue for our particular project, so the decision was pretty straightforward.

Re: Show HN: I rewrote my Mac Electron app in Rust

#266
post #23

Just curious did you guys give any thought to writing the core processing work in a separate Rust solution that your Electron app could call into?

If anyone does decide to pursue this, you can use napi-rs [0] to write Rust modules and call it from JS. Lower overhead than IPC but you will crash your process if there's an issue in your Rust code.

[0] https://napi.rs/

Re: Show HN: I rewrote my Mac Electron app in Rust

#267

Earlier quoted context omitted.

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

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

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.

Re: Show HN: I rewrote my Mac Electron app in Rust

#268
post #75
post #58

Earlier quoted context omitted.

I know. I'm saying that Tauri doesn't make things more difficult than any normal web app development, it's not like making web apps which work across browsers is a new and scary thing

It's not a new or scary thing, but it's way more expensive (in time or money) than relying on "it looks good on my machine, so it looks good everywhere." I've worked on large consumer-facing web-apps where we had a dedicated QA team (and/or contracting firm) that runs visual regression testing on multiple platforms and browser versions. As a solo developer, I have no interest in being that team for my hobby project.…

> it seems like the only people who get up in arms over an extra 200MB are HN readers, and my app isn't really targeted at them

Tauri however, is.

Re: Show HN: I rewrote my Mac Electron app in Rust

#269

Earlier quoted context omitted.

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

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.

Re: Show HN: I rewrote my Mac Electron app in Rust

#270

Earlier quoted context omitted.

That's part of it, but also Tauri uses Rust on the backend while Electron uses Node. Electron is way more mature with a larger developer community, but Tauri keeps gaining momentum. If memory safety, bundle size, and performance are important to you, Tauri is a nice choice. Electron is not bad but there's a reason there are so many new players.

> If memory safety But Tauri is just a wrapper around WebKit, which is written mostly in C++.

Yes, but it is far more tested, fuzzed, studied and battle hardened than your app code will ever be. So in the grand scheme of things it isn't a high risk for stability or security.

Yes, it would be nice if the full stack is memory safe, but that isn't a good reason to not write your own code in a memory safe language.

Post reply on HN