Show HN: I rewrote my Mac Electron app in Rust (desktopdocs.com)
TLDR; rebuilding in Rust was the right move.
So we rewrote the app with Rust and Tauri and here are the results:
- App size is 83% smaller: 1GB → 172MB - DMG Installer is 70% smaller: 232MB → 69.5MB - Indexing files is faster: A 38-minute video now indexes in ~3 minutes instead of 10-14 minutes - Overall more stability (old app used to randomly crash)
The original version worked, but it didn't perform well when you tried indexing thousands of images or large videos. We lost a lot of time struggling to optimize Electron’s main-renderer process communication and ended up with a complex worker system to process large batches of media files.
For months we wrestled with indecision about continuing to optimize the Electron app vs. starting a full rebuild in Swift or Rust. The main thing holding us back was that we hadn’t coded in Swift in almost 10 years and we didn’t know Rust very well.
What finally broke us was when users complained the app crashed their video calls just running in background. I guess that’s what happens when you ship an app with Chromium that takes up 200mb before any application code.
Today the app still uses CLIP for embeddings and Redis for vector storage and search, except Rust now handles the image and video processing pipeline and all the file I/O to let users browse their entire machine, not just indexed files.
For the UI, we decided to rebuild it from scratch instead of porting over the old UI. This turned out well because it resulted in a cleaner, simpler UI after living with the complexity of the old version.
The trickiest part of the migration was learning Rust. LLMs definitely help, but the Rust/Tauri community just isn’t as mature compared to Electron. Bundling Redis into the app was a permissioning nightmare, but I think our solution with Rust handles this better than what we had with Electron.
All in, the rebuild took about two months and still needs some more work to be at total parity with its Electron version, but the core functionality of indexing and searching files is way more performant than before and that made it worth the time. Sometimes you gotta throw away working code to build the right thing.
AMA about Rust/Tauri migration, Redis bundling nightmares, how CLIP embeddings work for local semantic search, or why Electron isn't always the answer.
464 comments
[ 4.5 ms ] story [ 346 ms ] threadI like the narrative, BTW, on why you needed to port your app.
As far as porting over goes, we are much happier maintaining the new version.
The smaller bundle size with Tauri and blazing speed are well worth the effort.
[1] https://crates.io/crates/burn
[2] https://github.com/huggingface/candle
Interestingly, burn supports candle as a backend.
I was just looking into this today!
The options I've found, but yet to evaluate:
- TorchScript + tch = Use `torch.jit.trace` to create a traced model, load with tch/rust-tokenizers
- rust-bert + tch = Seems to provide slightly higher-level usage, also use traced model
- ONNX Runtime - Convert (via transformers.onnx) .pt model to .onnx encoder and decoder, then use onnxruntime+ndarray for inference
- Candle crate - Seems to have the smallest API for basic inference, and AFAIK can load up models saved with model.save() without conversion or other things
These are the different approaches I've found so far, but probably missed a bunch. All of them seem OK, but on different abstraction-levels obviously, so depends on what you want ultimately. If anyone know any other approach, would be more than happy to hear about it!
Candle is a great choice overall (and there are plenty of examples) but performance is slightly worse compared to tch.
Personally, if I can get it done with candle that's what I do. It's also pretty neat for serverless.
If I can't, I check if I can convert it to onnx without extra work (or if there is an onnx available).
As a last resort, I think about shipping torchlib via tch.
Also it's a bit ambiguous if it searches documents? All the screenshots of are of image search, but the features say you can search inside PDFs and docs, though "All Your Files" says images and videos only-
What were your most valuable resources when moving from Electron to Tauri?
Are there any guides out there on the equivalencies between the two systems?
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 unusual or if rendering differences are as common as they felt to me.
Also, did you go Tauri 2.0 or 1.0? 2.0 released its first stable release while I was mid-stream on v1, and migration was a nightmare/documentation was woefully inadequate. Did they get the docs sorted out?
I am wondering why rendering differences between different platforms are such an issue? When building web apps, you face the same challenges, so I would assume it wouldn't be much different.
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.
Electron apps often fully share codebase with the Web apps, so on the app backend you implement native functionality and communicate with your app via IPC.
The question is not if Electron feels better for developers because it renders consistently.
The question is if that matters. Is it a big issue? Does any user actually care?
They build in Chrome and test with Chrome and then the test of the week they whine about Firefox and Safari.
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.
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.
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.
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.
Would you have any webpage or product info, possibly with screenshots?
We're building an in-house DCC with egui so I'm curious.
My app needs wysiwyg editors, and JS is full of them.
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.
So use Electron and FFI, it's not that hard
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.
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.
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.
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.
Tauri needs a big fat warning label.
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
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)
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.
Additionally, the issues people find with WebkitGTK/Tauri aren't always web related, usually moreso Linux related (weird blank screens, issues with rendering certain stacked items, etc).
I have one such device and Firefox and Chrome also run on it. They're slow but still usable.
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. So the tradeoff with Tauri for me was "accept that I will ship obvious UI bugs" vs "accept that I will ship a bloated binary."
Reading anecdata on forums, 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.
I think it's good to be wary of overly sensitive advice that regular users don't care about. But would a regular user realize they have 10 electron apps running and their ram is maxed out all the time?
The argument against Electron isn't just a single bloated binary, but everyone shipping an app that uses way more RAM than necessary.
In other circumstances too though, it's not great UX to demand your users quit your app once they're done with it because it eats too many resources just being idle in the background. It's an issue I have with both Electron, where idle apps waste tonnes or RAM, and with many Rust UI frameworks, where an immediate-mode architecture means they'll be consuming CPU on the background.
NSApplicationDelegate's -(BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender; method exists so an application can, uhh, automatically terminate after the last window closes.
https://developer.apple.com/documentation/appkit/nsapplicati...
It's not 100% consistent but if you look at Apple's applications based on single window (calculator, system preferences, etc), closing the window quits the app.
I can’t find obvious reference or when Apple started changing this, but it seems related to background app killing that is done now as well. I’m still not sure how I feel about it, but historically that wasn’t common for Mac apps.
Nowadays, apps closing themselves or being closed by the OS automatically is reasonable in a lot of cases, but Electron apps tend to hit the cases where it still is valuable to operate with the classic NeXT/OS X document-based app paradigm.
Take pride in your work and respect the people using it.
I think the person you're responding to didn't actually measure if their claim is true.
It bas always been a fallacy though, as with CSS the end result can depend on the DPI scaling and the size of the display (unless you make sure it doesn't, but then you need to test different setups to be sure).
I never managed to find a set of CSS properties which made it look good in Chrome tho. And if it was a more serious project I'd probably have used SVGs instead of Unicode characters.
Tauri however, is.
I also feel like I will have to, yet again, trot out the comment from a Slack dev that explains why they moved _from_ per-platform webviews to Chromium. This isn't new ground being charted, plenty of companies and teams have been down this path and Electron exists for a reason.
(I am not saying Electron is _good_, I am saying that Tauri isn't the holy grail people make it out to be)
Regardless, your point stands: it's a bundled Chromium on all platforms
It took me 2 seconds to find in Google, and you're splitting hairs if you think it being macOS-only was the point of my comment. Their second bullet point is just as true today as it was back then.
It's like developing sophisticated websites for IE6-era web, with ActiveX and Java applets and this new "ajax" thing on the horizon that sure sounds nice but it'll be a decade before you can actually use it for most of your users.
The very core basics are essentially the same because yea - it's just a web browser. An <h1> will be bigger than a <p>. But they are regularly multiple years out of date, have WILDLY different security and native-access models, version specific bugs, initialization and threading requirements, performance tradeoffs, styling quirks, and you might have hundreds or thousands of versions to test against which you cannot reasonably test against because they are frequently tied to specific operating system versions that you can no longer download and install, or require hardware you do not have.
So yea. IE6-era stuff. Not an exaggeration at all.
For simple stuff they work just fine, performance is generally more than good enough, and they start up faster, use fewer resources, and lead to a much smaller install. They're entirely reasonable choices. But once you push the edges of the envelope they're an absolute nightmare, and that is the entire reason Electron exists. That is what caused Electron to become the giga-powerhouse that it is now. It solved that problem, at relatively high cost, but it is incredibly obviously worth it to anyone who has dealt with native webviews in complicated ways.
Modern browsers are a completely different game, in comparison - far more consistent and up to date in aggregate. They're utterly incomparable.
What a waste of time it was fighting for Web freedom.
Polyfills fix most of the things and we are running automated end to end test on Linux, which catches most of the issues.
IMO the most difficult thing is figuring out how far the users are behind with their webview version, mostly on Linux and macOS. Windows has done thinga right with their WebView2 implementation
And the performances of webkitgtk are horrible on Linux.
The main drawback, of course, is that it ships a browser with every app.
On the contrary if it's a large app that the user spends lots of time in, then the performance overhead might well be worth it for the user.
Imagine in the first case that it requires a base load of 10 units of energy to run and gives 2 units of output, while in the second it still costs 10 units of base load energy, but now it gives 100 units of output. The base load becomes relatively irrelevant.
TBH, a lite weight polyfill for most system webview would be refreshing change to all the spa frameworks out there.
Edit: It looks like Tauri uses the following platform webview features.
https://github.com/tauri-apps/wry?tab=readme-ov-file#platfor...
More on the stack and our initial issues can be read here: https://kreya.app/blog/how-we-built-kreya/#cross-platform-gu... (from 2021)
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.
“We moved from X to Y and were so in love.” posts are often postcards from the honeymoon.
> This year we've got a lot of exciting innovations in store for you, like CEF and SERVO based webviews...
From their discord.
HN discussion: https://news.ycombinator.com/item?id=43518462
Monocultures are great, as long they are the one we bet on.
Likewise I guess there is no problem that game developers mainly care about Windows, Proton is open source, so no big deal, why bother.
The browser is the actual product. An open source browser engine lowers the barrier of entry of creating new browsers.
>Likewise I guess there is no problem that game developers mainly care about Windows, Proton is open source, so no big deal
Which is why Valve recommends game developers to target Windows and use Proton for compatibility. Having one platform to target simplifies developers lives. Before developers were making bad ports to Linux because they did not have the resources to properly support another tech stacks. The value of developers being able to target a single platform can not be understated.
Though this is fundamentally a different situation as the leading implementation is closed source and is more capable.
>pretending to be "native".
The code is native. Just because something uses a library to call platform code it doesn't mean it isn't native. By that logic programs that use qt are not native because they use a cross platform api.
The Linux kernel is an implementation detail on Android, there is nothing about Linux exposed as official userspace API.
Any use of Linuxisms on Android apps is done at user's own peril and possible kick out of PlayStore.
>The Linux kernel is an implementation detail on Android
The kernel is such an important part of an operating system, you can't really ignore it as a developer even if technically it may be an implementation detail.
>Any use of Linuxisms on Android apps is done at user's own peril and possible kick out of PlayStore.
Sure, but Linux's ABI is stable and even in a world where things are moved to Zircom starnix was made to support that same ABI.
This applies to every open source project. The owners control what will be merged upstream and the direction the project will go in.
Of course not, it's only for Mac. If they were to support Windows and Linux, they probably would not have published this post.
Cross-platform UI is hard, even harder if you want to keep almost the exact same UI, same feature set across platforms, and potentially an online version. People moved from native applications to Qt to web stack for a reason.
Saying this as someone who works at a company that develops cross-platform desktop application that has millions of users. I can't imagine what my job would be like if we were using any other solution.
Chromium is superior to the native web view unless you have latest version of Windows or Mac.
[0] https://napi.rs/
this is good work & massive. nicely done
I'd love to write more about bundling redis binaries into these apps soon. There isn't a lot written about it now (at least that I could find) and it was a lot of trial and error to get it working.
Im super curious why you picked Redis over something more typical (SQLite springs to mind)
What was the advantage of doing this that made it worth the pain?
Show HN: I made a Mac app to search my images and videos locally with ML
https://news.ycombinator.com/item?id=40371467
May 15,2024 | 173 comments
see https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-...
if you open in new tab or copy/paste in new tab it does not.
After realizing there was no demo I was looking for a way to contact you directly with a few sample images, but can't find contact information on the website.
Consider adding a demo and contact info.
Otherwise, the app is looking solid. This seems like a great use of AI.
De-duplicating images is on our roadmap. Shoot me your contact info at hello@desktopdocs.com. Would love to see if we can help.
I would want to use a demo version (could be with limited functionality) before paying $99 upfront! Not a demo video...
Have you investigated multimodal embeddings from other models? CLIP is out of date, to put it mildly.
Given the importance to your business, it may be worthwhile into finetuning a modern native multimodal model like Gemma 3 to output aligned embeddings, albeit model size is a concern.
Who are they? as far as I see ProductHunt with only 11 votes.
It's probably okay on Windows though as the backend is different, but that's part of the problem.
One criticism of mobile app stores is that they don’t provide the option of paid major updates, and thereby strongly push adopting a subscription model.
The move to rust freed us up to focus more on feature development than configs and setup. It was surprising because I thought learning rust would set us back much longer, but the trade-off was worth it.
In our case, the bottleneck was related to how big the app was to start and how much we could optimize it to index media files for local AI search.
Alex Chen is also known as „Alexander Hipp“ or „Felix Mueller“
Though the concept is interesting - I don‘t like bullshit marketing like „Trusted by Professionals worldwide“ if I can uncover the real deal within seconds
I do so with Rust also with the package flutter_rust_bridge which works great, I'm working on a mobile app that also simultaneously works on web and desktop when I tested it, even all the Rust parts.
Maybe in some cases, but I kind of doubt this statement in general. I just tried a Flutter demo from their official site and text selection doesn't even _work_ correctly.
https://flutter.github.io/samples/web/simplistic_editor/
I'll copy-paste a few lines of the example sentence, double click on one of the middle lines to start selecting by word (which it doesn't seem to even do), and then highlighting starts on the top line instead of the line I selected.
In general the flutter apps always feel janky and second-class to the platform they're on, because they never fully implement the exact behavior of each platform they run on.
The short version is that Flutter's lack of rich text editing solutions at the time made it a non-starter. It's a common problem in the Flutter ecosystem from what I've seen, there's often 0 or only 1 quality package for many "advanced" desktop use cases.
I've found that the GUI library I tried (fyne with go) was mobile-first, so some desktop things e.g. file-open dialogs didn't have the functionality I expected (the "dialog" was actually drawn within the same window as the application window). Flutter is mobile first too IIUC.
Outside of Qt, languages like rust and go don't have a good solid desktop GUI development option.
Any lessons learned, particularly to leveraging LLMs to complete this transition could give a boost to people contemplating leaving electron behind or even starting a new project with Tauri.
Smart choice.