Show HN: I rewrote my Mac Electron app in Rust

On the contrary it is a big big issue if you have a complex web app like we do. It was a PITA to deal with user bugs in a specific macos version with a 8y out of date webview.

And the performances of webkitgtk are horrible on Linux.

Yeah I was wondering how you dealing with the inconsistency of the different webviews? Are you using jquery? Or data star? Or is your own custom made polyfill depending on your user base?

TBH, a lite weight polyfill for most system webview would be refreshing change to all the spa frameworks out there.

Wait - there's system webviews? On Mac, Windows, and Linux?

Edit: It looks like Tauri uses the following platform webview features.

https://github.com/tauri-apps/wry?tab=readme-ov-file#platfor...

This looks fantastic! Any deets on the stack?

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.

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.

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.

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

Blog post: https://v2.tauri.app/blog/tauri-verso-integration/

HN discussion: https://news.ycombinator.com/item?id=43518462

Looking forward to either being stable. I like the idea of Tauri, but I need it to work well on Linux too.

With Electron, it will bundle chrome into the app so you only have to handle that single rendering engine. Tauri uses whatever is the default browser on the system the app is installed on

No, WebkitGTK is notoriously an issue.

Chrome has by far the most consistent cross-platform rendering.

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 rendering in whatever the default web view browser is. On Mac this will be some version of Safari (depending on MacOS version), and on Windows it will be some recent-ish Edge thing. Tauri actually has a nice page breaking this down: https://v2.tauri.app/reference/webview-versions/

This also means that a new OS release can change how your app is rendering, so a user can conceivably have a UI bug appear without updating your app.

Web developers building web apps for web browsers typically do not test cross browser compatibility.

They build in Chrome and test with Chrome and then the test of the week they whine about Firefox and Safari.

Web apps pretty much by definition don't do the kinds of things that desktop apps want to do. In the rare cases where they are actually on par feature-wise, it's just as much headache to support all the browsers in use, it's just that the functionality bar is so much lower on average.

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.

Not sure what you're saying; Tauri uses the native web view, it still ends up rendering a website. The differences in UI toolkits don't matter.

Pure html/css rendering. JS support could be addressed trivially in the build system by transpiling anything unsupported by the oldest likely target.

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.

Tauri uses native WebView (can be very outdated in old OS versions) and compiles to native machine code. Electron bundles full Chromium (rendering engine for HTML/CSS+V8 for JS) AND Node.js for your app code.

Honestly if there was an Electron without Node.js which would use literally any compiled language (although Rust is probably too low level), it would've been more tolerable.

Exactly. Electron ships with a copy of chromium in every app, while Tauri uses the native WebView of the operating system.

Electron is also way more mature, but Tauri is improving.

I used MediaStream, which is part of the standard Web API

https://developer.mozilla.org/en-US/docs/Web/API/MediaStream

I ended up calling it Microscopic View. I made a webpage for it and everything.

https://microscopic-view.jgarrettcorbin.com

I got tied up with other projects while I was trying to navigate the submission process (it was my first time), so it's not up yet, but I'd be happy send you a build if you want to check it out.

The benchmark also says Tauri takes 25s to launch on Linux and build of empty app takes over 4 minutes on Windows. Not sure if those numbers are really correct.

I wonder the reason Tauri does great in Linux and Electron is at its worst is because of Optimization or lack thereof respectively.

I agree about dealing with Apple but having updates completely solved for us was a huge deal. We just didn't have the resources to solve this properly.

This was an app offered for free to some customers of the company. If the app had been the main commercial product we would have obviously opted for a better solution than distributing through stores or using Squirrel.

Back in 2018 we needed a server[1] that would notify Squirrel for the udpates. Squirrel worked ok on macOS but it was particularly bad on Windows. I don't remember the details... iirc Squirrel installed the actual executable in some weird folder and users would never be able to find the app if they deleted the link from the desktop.

[1] https://github.com/ArekSredzki/electron-release-server

It was trivial to create the apps with a web view. Then we implemented new features integrated with the OS that we didn't have before. This was back in 2018 so my memory is a bit fuzzy but I'd say in total 2-3 weeks of work. We definitely lost more time with Squirrel and Electron than that...

I know it’s probably still not ready for prime time, but I believe the arc browser team was building a windows runtime for swift bec they prefer to use swift everywhere.

Have you started your windows version testing? Any issues you've seen in the differences between browsers tauri would use on the different OSs?

App looks great, I'm on Windows so I can't wait to see it!

Thanks! Mentioned it on the other comment - but we're using the Ort crate in rust and bunlding onnxruntime with the app. Definitely considered Swift and I know it's gotten a lot better since I last used it, but cross-platform support was what got us to use Rust over Swift.

As far as porting over goes, we are much happier maintaining the new version.

After our Electron experience, I wish I had moved out of my comfort zone (JS) sooner. Electron just requires a lot of optimization and you have to be really tight with your imports to avoid loading things you don't immediately need.

The smaller bundle size with Tauri and blazing speed are well worth the effort.

There are two specific places where Python is not performant. I ran some tests in a few languages and Rust and C++ came out on top, by far. I could write Rust components and access them via Python. I could also use C++ and stick with Qt. Or I could take the plunge with Rust. As this is a personal app with no other users, this is a good place to keep sharpening my skills.