[HN Gopher] Show HN: I rewrote my Mac Electron app in Rust
___________________________________________________________________
Show HN: I rewrote my Mac Electron app in Rust
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. 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.
Author : katrinarodri
Score : 344 points
Date : 2025-05-28 16:53 UTC (6 hours ago)
(HTM) web link (desktopdocs.com)
(TXT) w3m dump (desktopdocs.com)
| JohannMac wrote:
| Given your destination was the Mac app, why not Swift/SwiftUI
| rather than Rust/Tauri? Just curious is all.
| correa_brian wrote:
| Thanks for checking it out. The goal is for Desktop Docs to be
| cross-platform. We've had a lot of requests for Windows
| support, so we chose Rust to set us up for an upcoming Windows
| version.
| burnte wrote:
| App looks great, I'm on Windows so I can't wait to see it!
| correa_brian wrote:
| Thanks! If you're interested in that version, drop us a
| note: hello [at] desktopdocs dot com. We'll shoot you an
| update when it's ready!
| rstupek wrote:
| Have you started your windows version testing? Any issues
| you've seen in the differences between browsers tauri would
| use on the different OSs?
| correa_brian wrote:
| We haven't started testing for windows yet. Are you on
| Windows? Happy to let you know when we're releasing that
| version.
| amendegree wrote:
| 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.
| mark_l_watson wrote:
| I wanted to ask the same question. Swift is a fairly nice
| language and seems to offer many of the benefits of Rust. As
| another commentator asked, I am also interested in details of
| integrating CLIPs.
|
| I like the narrative, BTW, on why you needed to port your app.
| correa_brian wrote:
| 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.
| ptsd_dalmatian wrote:
| Curious as well. I'm planning to build a desktop app, haven't
| use swift for a long time and I'm pretty new to rust. Tauri
| looks very promising. I really don't like electron apps.
| They're so slow to start even on lightning fast machines.
| Thanks for any insights!
| correa_brian wrote:
| 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.
| porphyra wrote:
| 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.
| correa_brian wrote:
| We're using the onnxruntime bindgs with the Ort crate. Our
| biggest challenge was just bundling the onnxruntime into the
| app and making sure everything was signed, etc.
| bn-l wrote:
| Tauri, from my experience, can be extremely frustrating.
| correa_brian wrote:
| Yeah there are definitely hang ups along the way. It's a
| big of wack-a-model but thankfully we've had an easier time
| developing with Rust than on Electron.
| porphyra wrote:
| I heard about burn [1] and candle [2] recently and they
| sounded interesting.
|
| [1] https://crates.io/crates/burn
|
| [2] https://github.com/huggingface/candle
|
| Interestingly, burn supports candle as a backend.
| correa_brian wrote:
| Nice. I'll try to test these out against our current
| implementation.
| diggan wrote:
| > I'm still not sure what the best inference stack on Rust is
|
| 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!
| jokethrowaway wrote:
| There's also the burn framework but there are a lot of
| tradeoffs to consider. It's neat for wgpu targets (including
| web) but you'll need to implement a lot of stuff.
|
| 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.
| correa_brian wrote:
| Great resources, thanks. I'll look into the other packages
| and compare against our onnx runtime setup.
| turtlebits wrote:
| There is no trial - the "Try Desktop Docs" button just links you
| to a stripe payment.
|
| 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-
| correa_brian wrote:
| We aren't offering a trial right now, but to answer about docs
| --> we're testing an update to support searching text and will
| be releasing it soon. Right now you can search the contents of
| all your images and videos.
| xbryanx wrote:
| Very nice!
|
| 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?
| yojo wrote:
| 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 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?
| logankeenan wrote:
| Do you mean the actual rendering of html/css when you say
| rendering differences? Or are you referring more to differences
| in JS support?
| yojo wrote:
| Pure html/css rendering. JS support could be addressed
| trivially in the build system by transpiling anything
| unsupported by the oldest likely target.
| ameliaquining wrote:
| Not all JS APIs are fully pollyfillable, especially ones
| that are part of the Web platform rather than ECMAScript. I
| dunno if it's a bigger problem overall than HTML/CSS,
| probably not, but it's not consistently trivial.
| krisknez wrote:
| I am a web developer and haven't used Tauri or Electron much
| yet.
|
| 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.
| yojo wrote:
| 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.
| ameliaquining wrote:
| 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.
| skydhash wrote:
| I would expect most trouble to come from complicated
| features like the audio stack or canvas, as well as system
| integration, not aesthetics.
| fmbb wrote:
| That does not answer the question.
|
| 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?
| fmbb wrote:
| 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.
| SoftTalker wrote:
| If true then Chrome is truly the new IE because that's
| exactly what they used to do with IE.
| int_19h wrote:
| 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.
| katrinarodri wrote:
| 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.
| starkparker wrote:
| 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.
| yojo wrote:
| 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.
| katrinarodri wrote:
| 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.
| M4v3R wrote:
| 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.
| galangalalgol wrote:
| 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.
| virtualritz wrote:
| 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.
| echelon wrote:
| > 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.
| duped wrote:
| > I want to use Rust. I want to use Chrome.
|
| So use Electron and FFI, it's not that hard
| dontlaugh wrote:
| 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.
| autoconfig wrote:
| 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?
| mort96 wrote:
| Dealing with the rendering differences isn't any more difficult
| with Tauri than it is when making a normal web app, is it?
| Klonoar wrote:
| No, WebkitGTK is notoriously an issue.
| mort96 wrote:
| Is WebKitGTK as used by Tauri worse than WebKitGTK used by
| a web app user's web browser?
| porridgeraisin wrote:
| No. But also, nobody(first order approximation) uses
| Gnome web. I would wager most javascript web apps don't
| work on that browser anyways due to webkitgtk. The most
| popular gnome distros all come with firefox installed so
| even the "just use the default" folks won't be using
| gnome web.
| oblio wrote:
| But the thing is, if you're using Tauri, you control the
| web app. So you need to test it on WebkitGTK, I guess
| that's the extra burden?
| ameliaquining wrote:
| WebKitGTK benefits from sharing a codebase with WebKit
| for iOS, which web developers do care about supporting.
| There can still be bugs in the Linux-specific platform
| integration code, but that's not most of the codebase, so
| any given app is less likely to run across a bug in it.
| It's not as reliable as more mainstream browser-OS
| combinations, but saying that _most_ apps don 't work is
| an exaggeration.
| Klonoar wrote:
| Last I checked, WebkitGTK does not have parity with
| WebKit on iOS, and plenty of devs do test on that
| platform anyway - so I'm not sure what you're talking
| about? You're right to correct someone saying _most_ apps
| don't work, but it's also not cool to just sweep the
| WebkitGTK issue under the rug and pretend it's not an
| issue at all. It's bitten plenty of people who build on
| Tauri.
|
| 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).
| anthk wrote:
| Gnome Web sucks, it's has shitty defaults and a horrid
| performance. But luakit/vimb can be really fast. Luakit
| even ran under a netbook. Single page bound, ok,, but not
| bad from an n270 with 1GB of RAM.
| anthk wrote:
| Gnome Web sucks, it has shitty defaults and a horrid
| performance. But luakit/vimb can be really fast. Luakit
| even ran under a netbook. Single page bound, ok,, but not
| bad from an n270 with 1GB of RAM.
| macawfish wrote:
| It's awful. I'm cautiously optimistic (hopeful? naive?)
| that progress on servo will make it unnecessary!
| cosmic_cheese wrote:
| The Linux port of Orion (Kagi's power user oriented web
| browser) is built with WebKitGTK, some hopefully the Orion
| team will be patching up some of the more glaring issues.
| At minimum the port will put it in front of pairs of
| eyeballs that hadn't been looking at it before which should
| help bring attention to bugs.
| logankeenan wrote:
| 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
| mort96 wrote:
| 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
| yojo wrote:
| 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. 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.
| Capricorn2481 wrote:
| > 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.
| yojo wrote:
| That's a fair point. My app (and possibly the OP's) is
| built assuming it is the user's current focus and
| priority, and that you'll quit it once you're done with
| the task. I don't feel bad about asking for a chunk of
| RAM for a focal app like this, but I would feel
| differently if I was shipping a background tool or small
| utility or something.
| mort96 wrote:
| Especially macOS is built on the assumption that you
| rarely "quit" apps. When you close all of an app's
| windows, it remains running. You actually have to hit
| cmd+q or right click and hit "Quit" in the Dock to really
| quit an app.
|
| 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.
| ksherlock wrote:
| Electron doesn't seem to support it (and even if it did,
| I suspect most electron developers wouldn't pay it any
| mind) but...
|
| NSApplicationDelegate's -(BOOL)applicationShouldTerminate
| AfterLastWindowClosed:(NSApplication *)sender; method
| exists so an application can, uhh, automatically
| terminate after the last window closes.
|
| https://developer.apple.com/documentation/appkit/nsapplic
| ati...
|
| 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.
| jonhohle wrote:
| The function has been available for a while, but auto-
| closing system apps is a relatively recent change.
|
| 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.
| wtallis wrote:
| The ability for an app to keep running without a window
| was a godsend back in the days when we were all running
| on hard drives and large apps had splash screens to amuse
| you during their multi-second launch process. If you were
| done with a particular document but not done with the
| application as a whole, you could simply close the window
| and next time you needed to open a document in that app
| you wouldn't have to sit through the splash screen again.
| Unless it was an app with a cross-platform GUI that
| didn't support this model.
|
| 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.
| jonhohle wrote:
| Part of it is respecting your customers regardless of
| whether they are aware of your crappy electron app
| consuming all their RAM and draining their battery or
| not. If I went to a mechanic (car analogy incoming) that
| repaired pressurized lines with duct tape instead of hose
| clamps because I wouldn't care as long as the car worked,
| I would be upset, regardless of whether or not it got the
| job done.
|
| Take pride in your work and respect the people using it.
| brulard wrote:
| Absolutely. HN is unnecessarily full of "electron always
| bad" mindset. It makes sense for so many use cases.
| littlestymaar wrote:
| > "it looks good on my machine, so it looks good
| everywhere."
|
| 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).
| mort96 wrote:
| Well, they're right to point out that it removes a lot of
| inconsistency though. For example, today I was working on
| an app which used some Unicode characters as icons in
| buttons, and they look perfectly centered in the button
| in Firefox but weirdly off-Center in Chrome.
|
| 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.
| littlestymaar wrote:
| Sure, the closer your config is from the actual user
| config the fewer issues you'll get, but I wanted to
| highlight that even with electron you ought to test on
| different configurations.
| mort96 wrote:
| Oh, yeah, certainly. Even when I've made dinky little
| Electron apps I've had a Windows machine ready (I
| otherwise use Linux and macOS) just to make the Windows
| binary and do some rudimentary acceptance tests. You
| can't get away from testing on all your officially
| supported configurations.
| cosmic_cheese wrote:
| It's an unpopular take I'm sure, but I really have to
| question shipping binaries for platforms that I can't or
| won't personally test. Between platform intricacies I
| don't understand, unaddressed papercuts, and limited
| ability to debug issues, the end result is very likely to
| be underwhelming and/or frustrating for users of that
| platform, and as such if the app is paid those users are
| disproportionately unlikely to convert and more likely to
| churn. The only real benefit I see is an extra platform
| icon lined up on the marketing page.
| wtallis wrote:
| There's also the simple fact that shipping an identical
| UI on multiple operating systems is _obviously wrong_ for
| a least some of those operating systems (and maybe _all_
| of them). You don 't have to worry about "platform
| intricacies" because a web-based cross-platform UI
| toolkit is going to get _really basic_ UI conventions
| wrong.
| ChadNauseam wrote:
| At this point people are more accustomed to chrome's
| conventions than the native UI's conventions in most
| cases
| int_19h wrote:
| But there aren't really many "Chrome conventions" to
| speak of. Every web app (and Electron app) necessarily
| has to reinvent a lot of wheels that desktop apps get for
| free from the underlying OS. And sure, there are
| component libraries for that... way too many libraries,
| each of them doing everything slightly differently from
| others.
| cosmic_cheese wrote:
| It's not only UI design/conventions being covered, but
| also things like quirks with the system's audio,
| compositor, window manager, etc depending on what your
| app does and which technologies it uses. If the dev
| doesn't understand these things about a platform, they're
| walking into a minefield by supporting it.
| sureglymop wrote:
| Perhaps users have different standards for a desktop app
| they installed.. but it's just a possibility, I do not
| know.
| Klonoar wrote:
| Tauri does not do this in all cases, as WebkitGTK on
| Linux has performance issues and is often the ugly
| duckling of everything.
|
| 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)
| ameliaquining wrote:
| According to https://slack.engineering/building-hybrid-
| applications-with-..., Slack never used multiple
| different per-platform webviews. The earliest version of
| their desktop app was Mac-only and used the OS-native
| WebView API, but they switched to Electron at the same
| time they started work on making the app cross-platform.
| At the time, not only did Tauri not exist, but neither
| did the WebView2 API that it uses under the hood on
| Windows; they would have had to use the WebBrowser
| ActiveX control, which uses Internet Explorer's Trident
| engine and was already deprecated. So it's not so much
| that they rejected per-platform webviews, as that per-
| platform webviews were not yet really available as an
| option on desktop.
| mort96 wrote:
| Isn't Spotify using CEF (Chromium Embedded Framework)
| rather than Electron?
|
| Regardless, your point stands: it's a bundled Chromium on
| all platforms
| Klonoar wrote:
| https://news.ycombinator.com/item?id=18763449
|
| 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.
| paxys wrote:
| Chrome has _by far_ the most consistent cross-platform
| rendering.
| CommonGuy wrote:
| We are using system webviews for https://kreya.app (not Tauri,
| but a custom implementation) and the platform differences are
| seldom a problem...
|
| 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
| Sytten wrote:
| 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.
| keysdev wrote:
| 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.
| cvburgess wrote:
| 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.
| andrewstuart wrote:
| You're post honeymoon.
|
| "We moved from X to Y and were so in love." posts are often
| postcards from the honeymoon.
| correa_brian wrote:
| We love it here. We're staying together forever
| no1youknowz wrote:
| Just recently Tauri announced:
|
| > This year we've got a lot of exciting innovations in store
| for you, like CEF and SERVO based webviews...
|
| From their discord.
| ryanseys wrote:
| Blog post: https://v2.tauri.app/blog/tauri-verso-integration/
|
| HN discussion: https://news.ycombinator.com/item?id=43518462
| pikdum wrote:
| Looking forward to either being stable. I like the idea of
| Tauri, but I need it to work well on Linux too.
| NoelJacob wrote:
| I'm curious how Tauri causes different views on different
| platforms because Tauri frontends are websites and if websites
| function same way on platforms so should the apps. If websites
| use something to hide browser differences so should the app
| developer on Tauri.
| pjmlp wrote:
| I guess the Web would be all much better if ChromeOS Platform
| was everything that remained, who needs standards and multiple
| vendors.
| charcircuit wrote:
| It's much more convient for developers for there to be a
| dominant to open source browser engine. Open source reduced
| the need for these standards and multiple vendors. See what
| happened with how Linux largely replaced the slew of UNIXes.
| The ability for everyone to contribute to a single project
| paired with the ability to customize it where needed to suit
| the product you are building has shown to be a winning model.
| rs186 wrote:
| > Have you run into any cross platform UI bugs
|
| 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.
| lionkor wrote:
| 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.
| NeroVanbierv wrote:
| I would be willing to pay for this if it were available for
| Linux! Main use case: searching through my years of screenshots
| correa_brian wrote:
| Awesome! Linux version is on our roadmap and that use case is
| exactly why we started building this too. I can let you know
| when that version is ready
| mentos wrote:
| 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?
| correa_brian wrote:
| We considered it and decided all the wrangling wasn't worth it.
| Briefly also thought about adding in a python process to
| interact with our ML models, but figured it was worth
| streamlining this all into a single language/framework vs.
| creating frankenstein's monster.
| dzonga wrote:
| please write more about how you embedded redis in either electron
| or rust.
|
| this is good work & massive. nicely done
| katrinarodri wrote:
| thanks for checking it out.
|
| 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.
| zer00eyz wrote:
| > Redis for vector storage ... Redis bundling nightmares
|
| 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?
| correa_brian wrote:
| I did some prototyping with SQLite + VSS extension to handle
| embeddings and wasn't getting the same results as using the
| Redis search modules. My preference would be to run something
| that doesn't require a separate for the DB, but it still needs
| some tuning. Redis gets the job done but there are likely
| simpler solutions that could give us comparable performance
| that we'll discover.
| kirubakaran wrote:
| Launch post:
|
| 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
| correa_brian wrote:
| That's it! Almost one year anniversary for Desktop Docs!
| tcshit wrote:
| As a C++ developer I shrug at those size numbers, but I'm glad
| you are a happy with Rust.
| correa_brian wrote:
| Should we do a c++ rebuild
| the__alchemist wrote:
| As a rust developer, I do too! Those are not representative of
| rust GUI/3D etc desktop applications. I've made some pretty
| complicated stuff with 2D and 3D graphics, lots of
| functionality; expected size is 5-15Mb on Windows, and 10-25Mb
| on Linux. Less if you don't need 3D.
| correa_brian wrote:
| What do you think would be more in line with what you've seen
| in the past? There's definitely room to keep optimizing.
| the__alchemist wrote:
| <25Mb for the executable. For the use case the web page
| desribes, probably <15Mb. It usually comes down to
| dependencies used.
| katrinarodri wrote:
| Interesting. I'd love to get our app size down further,
| under 15MB would be great.
| tonyhart7 wrote:
| is there a UI framework production ready yet in rust???
| because for Tauri at least you can use JS which is fine
| _bent wrote:
| yeah slint, which is most similar to Qt
|
| see https://www.boringcactus.com/2025/04/13/2025-survey-of-
| rust-...
| fkyoureadthedoc wrote:
| lol when you click through to this site from HN it
| redirects to https://upload.wikimedia.org/wikipedia/commo
| ns/d/d4/Human_fa...
|
| if you open in new tab or copy/paste in new tab it does
| not.
| the__alchemist wrote:
| EGUI
| anthk wrote:
| Strip the Linux binaries with strip(1).
| airstrike wrote:
| That has nothing to do with Rust and everything to do with
| Tauri.
| wk_end wrote:
| OP's sort of being misleading when they say they "rewrote it in
| Rust", IMO. They're still using HTML and JS for their UI,
| rather than a native solution. The size/perf improvements
| mostly just come from using the OS' native engine instead of
| bundling Chromium.
| the__alchemist wrote:
| 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.
| correa_brian wrote:
| Desktop Docs needs a GPU to work well, so we started with the
| Silicon chip Macs since they are ideal candidates to handle the
| workload of indexing an entire media library.
| TheMiddleMan wrote:
| 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.
|
| 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.
| correa_brian wrote:
| Thanks for the feedback! Will get a demo video and contact info
| up shortly.
|
| De-duplicating images is on our roadmap. Shoot me your contact
| info at hello@desktopdocs.com. Would love to see if we can
| help.
| jdprgm wrote:
| For free/open source options I would suggest
| https://dupeguru.voltaicideas.net/ and
| https://github.com/0x90d/videoduplicatefinder
| zalebz wrote:
| 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.
| katrinarodri wrote:
| Happy to share the experience. It was something we debated for
| a long time. Rebuilding something that is already kind've
| working is daunting, but in this case we are happy with the
| results.
| minimaxir wrote:
| > Today the app still uses CLIP for embeddings
|
| Have you investigated multimodal embeddings from other models?
| CLIP is out of date, to put it mildly.
| correa_brian wrote:
| For sure. We've been prototyping embedding a vision model in
| desktop docs, but just needs more dev time to be stable. Went
| with CLIP for parity, but we are looking to upgrade soon. I
| tried Siglip and wasn't impressed. Do you know other open-
| source image embedding models you'd recommend?
| minimaxir wrote:
| nomic-embed-vision-1.5 (https://huggingface.co/nomic-
| ai/nomic-embed-vision-v1.5) is alignable with nomic-embed-
| text-1.5 for multimodal retrieval and implements some more
| modern LLM improvements, although it doesn't solve some of
| the problems CLIP has.
|
| 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.
| correa_brian wrote:
| I love Gemma. I use it on LM studio and am working on
| getting it into Desktop Docs. Thats for the nomic link.
| I'll do some testing...
| todotask2 wrote:
| > Trusted by Professionals Worldwide
|
| Who are they? as far as I see ProductHunt with only 11 votes.
| correa_brian wrote:
| Yeah we didn't get a lot of traction on PH unfortunately and
| they have a lot of rules about relaunching. As far as users go
| - it ranges from prosumers to producers at media companies.
| GardenLetter27 wrote:
| Tauri isn't really fully cross-platform in the same way as
| Electron due to the issues with webkit-gtk, etc. though.
| katrinarodri wrote:
| What kind of issues are those? We want to support Windows soon.
| With Electron we had some cross-platform issues where our
| bundled binaries wouldn't run reliably in different platforms
| (even when the binaries were bundled and loaded for those
| specific platforms).
| GardenLetter27 wrote:
| Just rendering a grey screen on Nvidia - https://www.reddit.c
| om/r/tauri/comments/16tzsi8/tauri_deskto...
|
| It's probably okay on Windows though as the backend is
| different, but that's part of the problem.
| katrinarodri wrote:
| I see
| CryZe wrote:
| I have an issue where I have two canvases that are
| overlapping and only WebKitGTK (not even just WebKit) just
| randomly stops showing one of the canvases.
| katrinarodri wrote:
| Strange. From the comments here sounds like there are a lot
| of issues with Tauri's UI being inconsistent.
| jeffchuber wrote:
| id be super curious to see if Chroma (written in Rust) can work
| better here!
| Hard_Space wrote:
| 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'.
| layer8 wrote:
| It's normal for one-time purchases to come with a limit on
| updates (for desktop applications). A subscription would mean
| that you can't continue using the functionality after the
| subscription is cancelled/expires, but you can continue to use
| a one-time purchase forever.
|
| 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.
| maz1b wrote:
| What was the most surprising thing you saw or learned in this
| rewrite process?
| correa_brian wrote:
| The move from Electron helped us remove "native libraries" in
| Node. Previously we were using Xenova transformers to
| instantiate the models. This forced us to use multiple
| package.jsons and added a lot of cognitive overhead to our
| development.
|
| 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.
| modzu wrote:
| 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
| katrinarodri wrote:
| sounds like you built a really useful app for working with
| large media libraries.
|
| 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.
| amendegree wrote:
| Interesting, do you have any write up on the app? What does
| your app do?
| hilti wrote:
| Better do a Google reverse image search before you put fake
| testimonials on your website:
|
| 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
| gozzoo wrote:
| 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.
| correa_brian wrote:
| I've heard good things about Flutter! We briefly considered it
| but just opted for Tauri out of preference.
| brulard wrote:
| You shall hear also about dark side of Flutter. It
| reimplements the whole UI rendering layer and UI components,
| so you lose all the flexibility, accessibility etc. of native
| components. On the other hand with Tauri or React Native you
| get browser or native OS components.
| correa_brian wrote:
| dont like the sound of reimplementing the whole UI
| components....
| satvikpendem wrote:
| You don't have to reimplement them yourself, they already
| come provided with the same components as on the web,
| like buttons, forms etc (and there are also custom UI
| frameworks like forui which clones shadcn/UI if you're
| familiar with that). The point being, Flutter apps can
| run much smoother precisely because they reimplement
| everything rather than dealing with the legacies of HTML
| and CSS. Since your UI seems fairly simple to make in any
| UI framework, you could take a look at Flutter as well.
|
| 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.
| GarettWithOneR wrote:
| I evaluated Flutter for my app before deciding to go with Tauri
| and wrote about it on my blog:
| https://arboretum.space/blog/why-arboretum-chose-tauri .
|
| 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.
| bredren wrote:
| 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?
|
| 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.
| rvz wrote:
| > TLDR; rebuilding in Rust was the right move.
|
| Smart choice.
| correa_brian wrote:
| Haven't looked back since
| tonyhart7 wrote:
| what vision/llm model you use???
| correa_brian wrote:
| For now we're using CLIP. We've also done testing with Siglip
| and Gemma for a full-blown vision model.
| pier25 wrote:
| 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.
|
| 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.
|
| It was a great decision.
| correa_brian wrote:
| Nice. How long did the migration take?
| pier25 wrote:
| 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...
| brulard wrote:
| This is the first time I see someone praising distribution and
| updates through native app stores. The time to get update to
| users and the uncertainty, that it gets through the approval
| process are just some of the reasons. I know nothing about
| Squirrel, but what were the things that improved moving to
| native?
| pier25 wrote:
| 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
| jdprgm wrote:
| - "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.
|
| - 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).
|
| - 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.
|
| - 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?
|
| - 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
|
| - 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)
|
| - 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)
|
| - 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
| correa_brian wrote:
| Appreciate the feedback! We haven't setup the infrastructure
| for a trial but maybe in the future.
|
| That's cool you built a similar tool - what kept you from
| releasing it?
|
| Plan is to ship a Windows and Linux version in the next few
| months if there's enough demand.
|
| We've gotten our users through various launches on HN and
| reddit with some minimal linkedin promotion. It's been mostly
| word of mouth, which has been very promising to see.
|
| Re: the electron and video processing performances - there's a
| lot to dive into. I don't claim to be an Electron expert, so
| maybe it was our misuse of workers that created a bottleneck.
| As part of the migration to rust we also implemented scene
| detection to help reduce the number of frames we indexed and
| this helped reduce processing loads a lot. We also added some
| GPU acceleration flags on ffmpeg that gave us meaningful gains.
| Batching processing image embedding generation was also a good
| improvement to a point, before it started crashing our model
| instance.
| willchen wrote:
| I recently built an Electron app (http://dyad.sh/) and I looked
| at other options like Tauri, but Electron has such a mature
| ecosystem (e.g. https://www.electronforge.io/) that I was able to
| ship a cross-platform app in a couple weeks (Mac+Windows) and
| then adding Linux support was pretty trivial.
|
| 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)
| terhechte wrote:
| Why did you bundle Redis and not use one of the many key value
| libraries available for Rust (or even sqlite)?
| correa_brian wrote:
| For vector search we couldn't get my results to return
| meaningful entries. My preference would have been to use
| sqlite. Any others you recommend besides sqlite with the vss
| extension?
| tayo42 wrote:
| How are you searching with redis?
|
| Aren't vector searches usuaully just like nearest values with
| some distance calculation? Are they not all implemented the
| same way?
| terhechte wrote:
| You could split it up in two separate entities. For vector
| search there's a myriad of good Rust projects. I've
| personally used:
|
| - https://crates.io/crates/lancedb -
| https://crates.io/crates/usearch -
| https://crates.io/crates/simsimd
|
| search and simsimd are fast and lightweight, but I'd advise
| to use lancedb if you're a bit new to Rust as the other two
| are a bit trickier to handle due to the C dependency (e.g.
| usearch needs Vec::with_capacity and will otherwise crash,
| etc).
|
| And then, you take the result of this query and can combine
| it with a sqlite `in` query.
|
| Or you use SQLite with a vector search extension:
| https://crates.io/crates/rig-sqlite
| turnsout wrote:
| Came here to post this. So curious about the choice to NOT use
| sqlite.
| correa_brian wrote:
| Would have loved to use sqlite if I could get good results.
| Maybe I botched the implementation.
| alexgarcia-xyz wrote:
| Creator of sqlite-vec here, happy to help debug anything if
| you do attempt to try out SQLite vector search again.
|
| You mentioned "VSS" in another comment, which if that was
| my sqlite-vss extension, I more-or-less abandoned that
| extension for sqlite-vec last year. The VSS extension was
| more unstable and bloated (based on Faiss), but the new VEC
| extension is much more lightweight and easy to use (custom
| C vector functions). The new metadata column support is
| also pretty nice, and can be used for push-down filtering.
|
| That being said, sqlite-vec still doesn't have ANN yet (but
| can brute-force ~10k's-100k of vectors quick enough), and
| I've fallen behind on updates and new releases. Hoping to
| push out a desperately-needed update this week
|
| link: https://alexgarcia.xyz/sqlite-vec/
|
| And there are a few other SQLite-based vector search
| extensions/tools out there, so the ecosystem is general
| might be worth another look.
| correa_brian wrote:
| Hey Alex - thanks for commenting. I'd be interested in
| giving this all another look. Like we mentioned in the
| post + comments, We went with redis because that's what
| got us the results we wanted. I'm open to revisiting our
| vector storage if it spares us needing to manage a
| separate db process.
| divan wrote:
| 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.
|
| Flutter would be much better choice for such a desktop app, for
| example.
| correa_brian wrote:
| How so?
| _bent wrote:
| you still can't have multiple windows with flutter, which
| disqualifies it for building desktop apps.
| Klonoar wrote:
| There is an unfortunate increasing trend to build desktop
| apps that only live in one window, so it's not really a
| "disqualification" - perhaps more a "complication".
| james2doyle wrote:
| True. But this is actively being worked on by Canonical:
| https://ubuntu.com/blog/multiple-window-flutter-desktop
| hombre_fatal wrote:
| On the other hand, they shipped, proved the product, and got
| their first paying customers with a web stack. And the top HN
| comment thread is people talking about the downsides of Tauri
| cross-platform.
|
| It's all trade-offs, unfortunately.
| zerr wrote:
| wxWidgets or QtWidgets if you want a proper desktop GUI app.
| johnisgood wrote:
| Heck, Tcl/Tk could work as well.
| iknowstuff wrote:
| that's funny, most of the time I don't even want to USE apps
| written in those because they're dated and janky as hell,
| must less write in them
| tonyhart7 wrote:
| should just use flutter from the start
| correa_brian wrote:
| why?
| tonyhart7 wrote:
| more mature and supported compared to Tauri???
|
| after Electron, flutter maybe comes second for multi platform
| thingy
| correa_brian wrote:
| seems like a lot of people in the comment disagree. good to
| know it exists
| Hikikomori wrote:
| The perfect hackernews headline.
| correa_brian wrote:
| :chefs-kiss
| ttoinou wrote:
| 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.
|
| And how come you don't charge any VAT or GST ? >
| Do you offer refunds? Once you download Desktop Docs it's
| yours forever, so it's non-refundable.
|
| Hum it's not really common to not offer refunds for software
| licenses. And you might have chargebacks anyways.
| sturges wrote:
| 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.
| katrinarodri wrote:
| Yes, it's nice that we can support the same functionality we
| were supporting in our Electron app using a much smaller binary
| with Tauri.
| t_mahmood wrote:
| For smaller tools, wouldn't iced-rs be a much better solution?
| It's much lighter than Tauri, and probably runs anywhere as
| it's self-contained. Initially, the code might seem daunting,
| and frustrating due to no hand holding nature, but gets easier.
|
| And last time I worked with it, it seemed much easier than
| previous versions.
|
| If you have complex UI, then, Tauri is better
| whatevermom wrote:
| 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?
| correa_brian wrote:
| Their vector search modules are the reason I embedded it. I
| tried sqlite and wasn't getting good search results with the
| vss extension. Maybe I wasn't configuring it correctly. Redis
| was just better than the alternatives (qdrant, sqlite, duckdb
| with vector search).
| zdrummond wrote:
| I would love to understand this in more depth. Any chance you
| could write up what you found?
| nemothekid wrote:
| Are you using Flat indexes? If so they should return the same
| results provided you are using the same distance function. If
| you aren't using Flat indexes, there might be more setup, but
| I'd recommend just using Flat indexes. They are plenty fast
| on most systems for searching ~1 million vectors (assuming
| 1024-32 bit float vectors).
|
| If you aren't doing anything crazy you could probably just
| get away with storing them all in a memory mapped file.
| twen_ty wrote:
| Or alternatively, why would SQLite be not as performant as
| Redis in embedded context?
| correa_brian wrote:
| I just wasn't able to get the similarity results to match
| redis. Probably my own error, but that's why I opted for it
| instead of SQLite. We'll revisit at some point.
| sillyboi wrote:
| It would be great to see an up-to-date benchmark comparing modern
| cross-platform frameworks like Tauri, Flutter, Electron, React
| Native, and others.
|
| Key metrics could include:
|
| - Target bundle size
|
| - Memory usage (RAM)
|
| - Startup time
|
| - CPU consumption under load
|
| - Disk usage
|
| - e.t.c.
|
| 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.
| katrinarodri wrote:
| I'd love to see a comparison like this.
| taroth wrote:
| Here's a great comparison, updated two weeks ago.
| https://github.com/Elanis/web-to-desktop-framework-compariso...
|
| Electron comes out looking competitive at runtime! IMO people
| over-fixate on disc space instead of runtime memory usage.
|
| Memory Usage with a single window open (Release builds)
|
| Windows (x64): 1. Electron: [?]93MB 2. NodeGui: [?]116MB 3.
| NW.JS: [?]131MB 4. Tauri: [?]154MB 5. Wails: [?]163MB 6.
| Neutralino: [?]282MB
|
| MacOS (arm64): 1. NodeGui: [?]84MB 2. Wails: [?]85MB 3. Tauri:
| [?]86MB 4. Neutralino: [?]109MB 5. Electron: [?]121MB 6. NW.JS:
| [?]189MB
|
| Linux (x64): 1. Tauri: [?]16MB 2. Electron: [?]70MB 3. Wails:
| [?]86MB 4. NodeGui: [?]109MB 5. NW.JS: [?]166MB 6. Neutralino:
| [?]402MB
| devwastaken wrote:
| 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.
|
| your application is now at the whim of version breaks by the OS
| browser.
| joshterrill wrote:
| 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.
| correa_brian wrote:
| We're using redis vector modules for cosine similarity. I'm
| sure there's more to optimize there. Your project sounds cool.
| How'd you reverse engineer apple's model?
| mac-mc wrote:
| 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?
| correa_brian wrote:
| The UX was a small part of the re-write. Since we started from
| scratch we had a blank slate and figured we'd go all in on
| Tauri/Rust/React vs. trying continue with Electron in the mix.
| rootnod3 wrote:
| "but the app was almost 1GB "
|
| 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.
| katrinarodri wrote:
| Yeah, we were talking about the app itself, it was way too big
| when we first started.
| gen2brain wrote:
| 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?
| katrinarodri wrote:
| Yeah, familiarity with the UI component libraries was a big
| driver in using web technologies for it.
| amelius wrote:
| The title is misleading. It gives the impression that Rust has a
| capable generic GUI library with expressive power like
| webbrowsers, but this is not the case.
| merb wrote:
| Wrong. There is at least slint. But it's not free.
| ogoffart wrote:
| Slint is free for desktop.
|
| Slint is under three licenses: GPL, or royalty-free on
| desktop/mobile, or paid for embedded. So you only have to pay
| if you sell hardware.
| binarymax wrote:
| 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?
| katrinarodri wrote:
| Yes, we were able to port the CLIP model to work with ONNX
| Runtime for inference
| binarymax wrote:
| May I ask, which version or ORT are you using? Were the
| outputs identical to PyTorch outputs for the same image?
| amelius wrote:
| [flagged]
| Svoka wrote:
| Did you try rust? Honestly feels like python rather than C if
| you got mental model internalized.
|
| Mostly because of very rich ecosystem of packages.
| dang wrote:
| This comment breaks both the site guidelines
| (https://news.ycombinator.com/newsguidelines.html) and the Show
| HN guidelines (https://news.ycombinator.com/showhn.html).
|
| Could you please review the rules and stick to them? We'd
| appreciate it because we're trying for something quite
| different here.
| aavshr wrote:
| 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?
|
| 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 (https://neon-rs.dev very grateful
| for this lib). This is a nice balance for us.
| correa_brian wrote:
| Thanks! We went with Rust because we weren't able to tune
| sqlite with a vector search extension to give me the results we
| wanted. I'm sure it's possible to use it instead of Redis but
| that's an optimization for another day. I'll check out Neon.
| Lienetic wrote:
| 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)?
| katrinarodri wrote:
| Now knowing how big Electron is off the bat compared to Tauri,
| I think I'd have to learn a lot more about how to optimize
| Electron to build with it again. That said, I think Electron is
| great for prototyping an idea and quickly getting it out.
| platevoltage wrote:
| 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.
| correa_brian wrote:
| That's pretty sick. Nice work. What's it called? We're working
| on the app store submission this week.
| platevoltage wrote:
| 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.
| djfergus wrote:
| I'd love to see something like this optimized for low end
| Android - old tablets are almost free and otherwise useless
| even for web browsing.
|
| Also, what is your recommendation for finding a cheap
| usable microscope? My brief forays to aliexpress have just
| resulted in frauds and trash.
| smusamashah wrote:
| What is the difference between Tauri and Electron. From what I
| understand both use browser for rendering, except electron
| ships the whole browser while Tauri use the browser already
| there on the system.
| SpaceL10n wrote:
| 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.
| amelius wrote:
| > If memory safety
|
| But Tauri is just a wrapper around WebKit, which is written
| mostly in C++.
| meindnoch wrote:
| Out of the frying pan into the fire.
| correa_brian wrote:
| :just-blaze
| jjcm wrote:
| 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.
|
| Another question - how long did it take for you to rewrite your
| app?
| contact9879 wrote:
| They note in-post that it took ~2 months
| dev_l1x_be wrote:
| This whole thread reads like it is really bad idea to use webtech
| for desktop applications.
| correa_brian wrote:
| What part?
| charcircuit wrote:
| Tauri uses webtech.
| djeastm wrote:
| I agree if your intention is to only make desktop applications.
| But if you have in mind a hybrid app or a team with web
| experience only who are ok with making compromises on
| performance and/or UI, it's a tradeoff that people are right to
| make, imo. It's of course not optimal, but that's engineering
| for you.
| backendEngineer wrote:
| the more I do with Rust the more I love this language, it just
| feels like comming home
| dotancohen wrote:
| How did you settle on Tauri, as opposed to e.g. egui? Is it
| because of the experience with Electron?
|
| 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.
| apitman wrote:
| What are your motivations for porting in the first place?
| dotancohen wrote:
| 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.
___________________________________________________________________
(page generated 2025-05-28 23:00 UTC)