A year ago, my co-founder launched Desktop Docs here on HN. It's a Mac app we built with Electron that uses CLIP embeddings to search photos and videos locally with natural language. We got positive feedback from HN and our first paying customers, but the app was almost 1GB and clunky to use.<p>TLDR; rebuilding in Rust was the right move.<p>So we rewrote the app with Rust and Tauri and here are the results:<p>- 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)<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>AMA about Rust/Tauri migration, Redis bundling nightmares, how CLIP embeddings work for local semantic search, or why Electron isn't always the answer.
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?<p>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.<p>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 did the same thing with one of my projects. I built a simple webcam viewer that is optimized for USB microscopes as I couldn't find anything out there for this purpose. Basically all of the functionality was implemented in the renderer. As I was planning for App Store submission, I realized that a 500mb webcam viewer might not be the best thing. I decided to port it to Tauri V2 and got it down to about 15mb.
I'm neither a Mac uset nor is our team exploring a Rust rewrite ... however I appreciate this post.
This is what I hope for from "Show HN", a just long enough summary of technical tradeoffs required to solve a real-world problem for a relatable small business (admittedly that part is an assumption). Thank you for sharing your experience.
It would be great to see an up-to-date benchmark comparing modern cross-platform frameworks like Tauri, Flutter, Electron, React Native, and others.<p>Key metrics could include:<p>- Target bundle size<p>- Memory usage (RAM)<p>- Startup time<p>- CPU consumption under load<p>- Disk usage<p>- e.t.c.<p>Additionally, for frameworks like Tauri, it would be useful to include a WebView compatibility matrix, since the rendering behavior and performance can vary significantly depending on the WebView version used on each platform (e.g., macOS WKWebView vs. Windows WebView2, or Linux GTK WebKit). This divergence can affect both UI fidelity and performance, so capturing those differences in a visual format or table could help developers make more informed choices.
At a previous company we maintained a desktop electron app for Windows and macOS. It was super bloated though and updates with Squirrel were a pain.<p>We kept the GUI as a web spa app (using Inferno) and wrote two small native apps with C# and Swift that would load a webview and other duties. App download size and memory consumption was reduced by like 90%. We also moved distribution and updates to the app stores of each platform.<p>It was a great decision.
- "Try" on the main LP call to action implies there is an available trial but just leads to a buy page. You really should have a trial, even something like just 1 week.<p>- Fan of the perpetual fallback licensing. Though $99 is a high barrier but i'm guessing you are targeting more creators/studios vs a more general consumer target (would think more like $20-25 for general consumer).<p>- You mention performance in this post but not at all on the landing page. The 38 minute video in the minutes would be very important to know for many potential customers. Would want benchmarks on various machines and info like parallel task processing, impact of and requirements around vram, etc. I would want an insight into what processing hundreds to thousands of hours of video is going to look like.<p>- I am curious how (and shocked) that electron itself was somehow responsible for a processing bottleneck going from 10-14 minutes to 3 minutes. Wasn't electron just responsible for orchestrating work to CLIP and likely ffmpeg? How was so much overhead added?<p>- I built (but never released) a similar type media search tool but based on transcriptions in Electron and didn't run into many performance issues<p>- Usually a lot of the motivation for building in Electron in the first place (or Tauri) would be cross platform, why mac only (especially for something like bulk media processing where nvidia can shine)<p>- I too recently went down the path of hadn't coded in Swift in 10 years and also investigated Tauri. I opted for Swift (for a new app not a re-write of something) and it has been mostly a pleasure so far and a dramatic improvement compared to my last swift app from around 2014 or so)<p>- If the LP section about active users is true it sounds like you've already found some modest success (congrats). Did you already have relationships/audience around the studio/creator space? Would be interested to hear about the marketing
Honest curiosity — why did you choose a service like Redis over a more straightforward embedded solution like SQLite? In my head Redis seems better suited to distributed solutions but I've never actually built a desktop application so I'm probably speaking from ignorance.
I write a lot of small internal tools to enable my team to work more efficiently. I've traditionally used WinForms, but recently tried using WinUI3. Disaster. Not even close to ready. After that, switched to just using React, uploading to an Azure static site, and adding Tauri if someone really wants an executable. Finding what you're finding--Tauri gets you most of the way there and comes with a much smaller file size than its competitors. Really nice to be able to ship the same code for the web and desktop without shipping Chrome again in the binary.
How did you settle on Tauri, as opposed to e.g. egui? Is it because of the experience with Electron?<p>I'm dragging my feet about porting my Python Qt app to Rust, because I feel that no Rust GUI library is as rich as Qt and I know that I'll get stuck with that at some point.
+1 for using Tauri over Electron. I've been using it for my MCP marketplace and management app[1], and it's been excellent. Having previously used only Electron, I was surprised by how much smaller the binaries are. Performance also feels noticeably faster.<p>The only challenge was my lack of familiarity with Rust. Even if you're starting off with a "JS first app", Tauri often requires dropping into Rust for anything even slightly native, such as file system access (eg. managing config files for Claude, Witsy, or code editors), handling client lifecycle actions like opening, closing, and restarting, or installing local MCP servers.<p>1. <a href="https://ninja.ai" rel="nofollow">https://ninja.ai</a>
I recently built an Electron app (<a href="http://dyad.sh/" rel="nofollow">http://dyad.sh/</a>) and I looked at other options like Tauri, but Electron has such a mature ecosystem (e.g. <a href="https://www.electronforge.io/" rel="nofollow">https://www.electronforge.io/</a>) that I was able to ship a cross-platform app in a couple weeks (Mac+Windows) and then adding Linux support was pretty trivial.<p>The only downside from my point of view is the large installer size for Electron apps, but it hasn't been a big issue for our users (because they will need to download quite a bit of other stuff like npm packages to actually build apps with dyad)
I love the idea of wha this app is doing, and so many of the options in this space are laggy and painful, so I'm very interested in this rewrite. That said, as a photographer a lot of my media is stored as RAWs, and it's not clear whether that's supported (or perhaps its exclusion from the list of "all major image and video formats" suggests that it's not)?<p>Does your product have docs/a support forum/other place these kinds of details would be covered?
I have built something similar but only for photos - <a href="https://viroop.com" rel="nofollow">https://viroop.com</a>. It is free for now. You have to run this command on the extracted app for MacOS to not show you the dreaded "App is damaged" dialog - `xattr -d com.apple.quarantine Viroop.app`.<p>My app is built with tauri too. It supports all kinds of images - - JPEG - PNG - TIFF - WEBP - BMP - ICO - GIF - AVIF - HEIC/HEIF and RAW images from various camera manufacturers.<p>The image reading and processing (for exporting images) is all done on the rust side. These are the crates i use
- image
- libheif-rs -> to read HEIF/HEIC images
- rawler -> to read JPEGs embedded inside RAW images
- libraw -> to convert RAW images to JPEGs and PNGs
- rexiv2 -> to read image exif data<p>I use the candle crate to download the CLIP model and generate index pairs for images. I store the faiss indexes in a file on the file system.<p>I am using the app personally for about a month and it feels amazing to use something you have built yourself.<p>I hope to add an image editor to the app in the future so that I have my own app management and editing software which is enough for my ametuer needs.<p>Any kind of feedback would be most welcome.
Why embed Redis ? What feature do you need from Redis so bad that you need to embed it? Maybe you could just use Rust and have something performant without adding complexity?
You didnt rebuild in Rust. you built a wrapper around a Webview. that webview still uses the same resources as if youd have used webkit directly.<p>your application is now at the whim of version breaks by the OS browser.
Very nice. I've been trying to find an image duplicate detection algorithm/system that suits my use-case for a while. Your app seems promising, however, I'm not willing to pay $99 just to see if it works with my (uniquely challenging) duplicate images.<p>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.<p>Consider adding a demo and contact info.<p>Otherwise, the app is looking solid. This seems like a great use of AI.
The UI appears simple enough to be implemented in any desktop GUI library. Why did you decide on using web technologies? Is it because of the libraries you are using in the app?
Isn't such app best implmented with some cross platform framework like flutter? It has support for all major desktop OSes and at leqast the examples run very smooth.
Long time ago we worked on a similar concept. A framework to build native applications via plain HTML/Javascript files with support for invoking native code: <a href="https://axemas.readthedocs.io/en/latest/" rel="nofollow">https://axemas.readthedocs.io/en/latest/</a><p>At the time the native part was the reason why the project never caught up, people preferred pure JS solutions even though they were much more limited and worse performing. Do you think that Tauri will actually be able to catch up even though it requires Rust knowledge which is far from being an easy language?
How much of it was the UI, and how much of was the non-ux code? Could've you achieved many of the same gains by creating a local backend in rust for things like indexing and leaving the UI as a more lightweight electron app while saving a lot more time in a rewrite? How much dev time was the UX rewrite compared to the backend rewrite?
Please note that Redis 8 supports vector sets as a native type without building any module. And the API is very simple to use. This may simplify the building / bundling process perhaps.
Inspiring! It seems Electron has proved it's value for the v1 MVP anyway. And then Rust has cemented the already proven functional value.<p>I don't know a technical details but maybe Sqlite would be the best next step of slim down?<p>I noticed screenshots on the page are displayed croped on Chrome Android (yeah I know).
Congratulations on the rewrite and launch!<p>1. Did you consider WAILS(Go)?<p>2. Did you consider ColPali ?<p>3. Are you planning to launch for other platforms (Linux/Windows) if so how are planning to achieve self-updates & signing the binary to prevent false detections from AV.<p>Thank you.
How do you run CLIP in Rust? I'm still not sure what the best inference stack on Rust is --- I tried onnxruntime bindings in Rust a few years ago and it was rather finicky to work with.
What an amazing achievement. From the outcome, it sounds like all the hardwork has paid off. Congratulations :)<p>How have the users perceived the new version so far? Are there positive feedback? Any new complaints due to the parity issues? Or in general, how is your team measuring success of the UI? From the post, it sounds like the users have a way to provide feedback and your team has a way to engage with them, which is wonderful. So I'm curious to learn.
> Redis for vector storage ... Redis bundling nightmares<p>Im super curious why you picked Redis over something more typical (SQLite springs to mind)<p>What was the advantage of doing this that made it worth the pain?
Great work, I can imagine how interesting the migration went. Why are you using Redis if I may ask? Was something like sqlite not enough? What are your biggest challenges with Tauri?<p>I also work with an Electron app and we also do local embeddings and most of the CPU intensive work happens in nodejs addons written in Rust and using Neon (<a href="https://neon-rs.dev" rel="nofollow">https://neon-rs.dev</a> very grateful for this lib). This is a nice balance for us.
OT but I would love to have a trial to test this before purchasing. But nice product idea I have this kind of issues dealing with my photos and videos.<p>And how come you don't charge any VAT or GST ?<p><pre><code> > Do you offer refunds?
Once you download Desktop Docs it's yours forever, so it's non-refundable.
</code></pre>
Hum it's not really common to not offer refunds for software licenses. And you might have chargebacks anyways.
I’ve been trying to build a desktop app in Rust+egui but as a Rust newbie (and desktop app newbie in general) I’ve found it really difficult to learn so many concepts at once. My work centers around mechanical engineering analysis tools which require high perf backend and data visualization on the front end. With Tauri did you find it difficult to maintain multiple stacks (rust, js, html, etc)?
> Today the app still uses CLIP for embeddings<p>Have you investigated multimodal embeddings from other models? CLIP is out of date, to put it mildly.
I'm curious how you're implementing the image similarity matching. I recently reverse engineered the Apple Neural Hash model and wrote an API to use it in my app for doing image similarity calculations. I found it to be extremely quick compared to some of the other more computationally intensive methods that I was trying to use before.
Would you please describe your adoption of LLMs in achieving this task in detail? For example, specific tooling at code-completion, web-chat and any other modalities?<p>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.
Very nice!<p>What were your most valuable resources when moving from Electron to Tauri?<p>Are there any guides out there on the equivalencies between the two systems?
Looks awesome. I work closely with Multimodal search and have had trouble porting CLIP to ONNX and other formats due to the lack of multi-head attention operators. Are you using Python for the CLIP inference, or did you manage to port it to a format hostable in a Rust or C/C++ inference runtime?
Is that macOS and Apple Silicon only? In this case indeed it's a no-brainer not to use Electron (why even use it in the first place?). If you ever want to support Intel processors, Linux and its many variants and Windows that will be a different story.
Really like your approach! Local-first and clean UI makes a big difference.
We're building a social media tool with similar values—more account support and personal profile compatibility.
RSS deserves this kind of revival. Keep it up!
Thank you for sharing such a rare experience. I'm also looking into building a Tauri production app, and I'm curious about how you handled authentication. Are there any helpful documents or resources you could recommend?
You could have just write the performance critical part of your Electron app using C++ and native node module and achieve the same performance improvements. You actually did it, but using Rust instead of C++.
This seems like the type of thing that LLMs would be great at, since you already have a fully specified application (all requirements and details worked out). Has anyone attempted something like this?
Why Mac specifically? Context: I do a lot of GUI application work in rust, and have never had to make a program OS-specific. There are quirks with CUDA, and CPU architecture if using SIMD, but they can be feature-gated out, or detected at runtime.
Would you be willing to upload a basic template repo of your architecture? I'm very interested in this, and would love to see how you organized your project.<p>Another question - how long did it take for you to rewrite your app?
> 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.<p>Can you recommend useful resources?
Launch post:<p>Show HN: I made a Mac app to search my images and videos locally with ML<p><a href="https://news.ycombinator.com/item?id=40371467">https://news.ycombinator.com/item?id=40371467</a><p>May 15,2024 | 173 comments
> Indexing files is faster: A 38-minute video now indexes in ~3 minutes instead of 10-14 minutes<p>can you explain how indexing is done and how rust helped in this case?
I wonder why it wasn't written in Swift. I mean, if you want to make an app targeting a specific platform and willing to invest time into a native language, might as well use the platform's official native language.
”but the app was almost 1GB "<p>I mean, I knew Electron was heavy, but holy cow that is HEAVY. No wonder that despite CPUs getting fast and RAM being 10x the size it used to be that software keeps feeling slower than ever. So you weren't talking RAM size, you were talking the size of the app itself? 1GB? That used to be the size for AAA games.
After this experience, do you think you'll ever build anything in the future with Electron? When do you think Electron is actually the right choice (if at all)?
i built an electron app for managing massive (millions) photo and video libraries. it took work and creativity (what technical problems dont) but its very performant. node is actually pretty good at io. that is to say electron itself wasnt your bottleneck, but rewriting in another language is pretext to write long form blog posts for seo and marketing purposes
There is no trial - the "Try Desktop Docs" button just links you to a stripe payment.<p>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-
Beware the greenfield effect.<p>I don’t want to comment on the technology choices specifically here, but in general the whole “we rewrote our app in X and now it’s better” is essentially a fact of life no matter the tech choices, at least for the first big rewrite.<p>First, you’re going to make better technical choices overall. You know much better where the problems lie.<p>Second, you’re rarely going to want to port over every bit of technical debt, bugs, or clunky UX decisions (with some exceptions [1]), so those things get fixed out of the gate.<p>Finally, it’s simply invigorating to start from a (relatively) clean slate, so that added energy is going to feel good and leave you in a sort of freshly-mowed greenfield afterglow. This in turn will motivate you and improve your work.<p>The greenfield effect happens even on smaller scales, especially when trying out a new language or framework, since you’re usually starting some new project with it.<p>[1] A good example of the sort of rewrite that _does_ offer something like an apples-to-apples comparison is Microsoft’s rewrite of the TypeScript compiler (and type checker, and LSP implementation) from TypeScript to Go, since they are aiming for 1-to-1 compatibility, including bugs and quirks: <a href="https://github.com/microsoft/typescript-go">https://github.com/microsoft/typescript-go</a>
Better do a Google reverse image search before you put fake testimonials on your website:<p>Alex Chen is also known as „Alexander Hipp“ or „Felix Mueller“<p>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
It's sad to witness how much suffering developers are ready to endure (and make their users suffer) just not to part ways with HTML/CSS/JS stack. The stack that was never designed properly, let alone for modern UI apps.<p>Flutter would be much better choice for such a desktop app, for example.
tl;dr: Came for the Mac app rewrite reactions, lingered and scrounged for info about the app.<p>Interesting approach to digital asset management. After watching the demo video I wanted to trial the app.<p>Wish I could, but it’s purchase only.
It might be a good idea to remove 'One-time purchase • No subscription' from the landing page, as the pricing page instead says 'One year of updates for $99'.