Tauri vs. Electron Benchmark: ~58% Less Memory, ~96% Smaller Bundle – Our Findings and Why We Chose Tauri
Posted by kostakos14@reddit | programming | View on Reddit | 81 comments
ShinyHappyREM@reddit
cue Casey Muratori's VS rant
kostakos14@reddit (OP)
I have actually see his rant about performance here:
https://www.youtube.com/watch?v=MR4i3Ho9zZY&ab_channel=gamedevcuts
He is telling the truth, and I agree. However, start-up performance != runtime performance. While modern Electron apps can take a considerable amount of time to launch, this might result from small, incremental performance degradations accumulating over time. Fresh ones started super fast
somebodddy@reddit
I think they both stem from the same anti-optimization culture, where developers have no choice but to let these small, incremental performance degradations accumulate over time because if they try to fix them when they happen they'd be optimizing which apparently is always premature.
If you let startup time degradations accumulate, you'll probably also let general performance degradations accumulate.
smuve_dude@reddit
I'm very late to the game, but I'm somewhat in the anti-optimization culture strictly in terms of premature optimization. Every time I, or a team, try to "optimize" something as we build it, we usually end up wasting time trying to speed up things that weren't impactful to begin with, end up with spaghetti code, and actually end up causing more performance problems.
I'm at the point where I focus on building things with simple, clean, boring code, and naive to performance considerations unless they're well-documented best practices. We also make sure to have thorough test coverage (E2E tests being most important). Then, make it a cultural point to dedicate time towards optimization after a feature, or a set of features are built. We also don't play the guessing game on optimizations. We run our due diligence by profiling first to find where the true bottlenecks are and then have optimization tasks. I've learned firsthand how easy it is to be completely off as to what's eating up resources when I was younger, and not profiling is just making stabs in the dark as to what's going on.
When I say "we" I mean this is something I'm trying to encourage at work. I've started doing this with personal projects, and it's been gratifying. Especially when you have a strong suite of E2E tests to ensure everything still works pretty well from a user-facing perspective.
I'm not the greatest at it yet because I'm self-taught, and never took the time to learn algorithms and data structures. I think learning all the terms and the mindset behind these concepts are actually very useful at this point in my career when I'm building systems. For example, it's not very necessary to know algos/data structures to build an app using React, but it's vital to have a good grasp of those concepts when building React itself.
somebodddy@reddit
There is, or course, such a thing as "too much optimization" or "optimizing too early". But we are not there, and haven't been there for a long time now. We are far on the other side, where performance is avoided at all costs.
kaelima@reddit
My biggest issue with not thinking about performance at all while developing is that your code might get littered with inefficiency from bad practices or from a deeper problem in your architecture. Once that happens it's can be really difficult to find out what's slow, the profilers will struggle to find hotspots because the baseline is high and no single method will stand out dramatically against the others.
Ok-Bank9873@reddit
Yeah it’s never happening later. You have to get in on the ground floor and loosen the belt for essential feature.
The more likely thing is customers complain then suddenly we want to deprecate the product and start fresh but people will do the same thing.
“Oh but why use an enum when string parsing is so easy to understand”
“the compiler can optimize away my shitty code”
“I did this for read ability and not performance”
Then they’ll proceed to write a 200 line function and when you mention breaking it up into more functions or god forbid a class suddenly they want to give you lecture on performance.
ShinyHappyREM@reddit
yep
somebodddy@reddit
You'd probably be less motivated to do it, too. Cutting 10ms from a 2s startup time is much less rewarding and seems much less important than cutting the exact same 10ms from a 20ms startup time.
SkoomaDentist@reddit
Fixed that.
m-hilgendorf@reddit
It's not about performance so much as latency. And optimizing for startup latency leads to architectural patterns that are shared across your application which can wind up minimizing latency everywhere.
Stuff like lazily initializing resources that are expensive to create, defering releasing them until after returning indicators to the user, etc. It's hard to add that stuff later.
AcanthisittaScary706@reddit
things like vim, nano and helix would be unusable with a start up that long.
DrShocker@reddit
I'd say if they took that long to start up, they'd be just as usable as the tools that take that long to start up. Which is to say, people use them but I have no patience so I avoid them.
fojam@reddit
They should've showed their actual measurements. This made me think electron was slightly faster but they didn't want to say it. From the gif, it did seem negligible, but would've been worth including.
RandomName8@reddit
Tauri relies on a lie: "platform native webview". This doesn't exists. Cellphones might have one, windows forces edge and osx forces safari, but linux, bsd, chromebook, steamdeck and anything that's based on today's linux desktop doesn't.
When you say "bundle size is
8.6 MiB" that's a lie. If I download your tauri application it won't run on my machine, I don't have webkitgtk installed nor want to, so your application better includes it. According to my package manager, it has to download 246MB if I tried to install it.kostakos14@reddit (OP)
Indeed, it's like the Pareto principle; we know that 80% of Linux users will have WebkitGTK pre-shipped, as the majority of Linux folks use Ubuntu/Debian (not 80% market share, though, to be fair).
I mean, there are no free lunches, but still, I am fond of this decision from the Tauri team, as Webviews are designed to be lighter to operate
xlab_is@reddit
> 80% of Linux users will have WebkitGTK pre-shipped
what are you talking about lol
RandomName8@reddit
I'm curious, where does this metric come from? The reports I've seen recently places KDE users ahead of Gnome, and at least it would be a 50% thing, not 80/20.
Good for you, I'm simply annoyed at Tauri's lie. They could simply not advertise it for what it is not.
Alternatively, I've had the same success using directly CEF, and then the host language can be anything, you're not forced to node or rust or whatever. Furthremore CEF can download itself dynamically on first run so your bundle size is small.
BaitednOutsmarted@reddit
webkitgtk would have to be downloaded once and then it's shared amongst all Tauri apps. That's not the case for electron.
_zenith@reddit
This sort of thing is precisely why Linux will never be a popular desktop choice, sadly
emdeka87@reddit
So you guys are building an ultra low latency screen sharing service and then choose a web framework? Just why 😭 why is everyone obsessed with using web for native applications, it just sucks. Pretty sure the memory usage on windows will be much higher. Ms Teams has plenty of these WebView2 instances that hog memory like crazy
SnooPies8677@reddit
Why would somebody pick html over native languages?
For one button:
kostakos14@reddit (OP)
Indeed for Windows only it matches the Electron's memory footprint as WebView on Windows is based on Chromium (if we exclude NodeJS runtime footprint which is also higher).
The web technology does not affect the performance much the streaming speed, as the sharer is sharing from the back-end (Rust) so its pretty fast. Only thing running in the web view is the `
jaskij@reddit
Getting hardware video acceleration working in any browser on Linux is a pain. That could be an issue for you, if nothing else, because battery drain.
Programmdude@reddit
I think the non-uniform rendering engine would be a nightmare to deal with. Not only different engines (chromium vs safari vs webkit), but also different versions of the same engine.
Raunhofer@reddit
I've been working with large 3D modeling applications using Tauri and was also worried about this, but apparently worried for nothing. Not a single issue so far when the target has been macOS/Windows platforms.
It doesn't really differ from your average web application development; if you stick with the reasonable basics, and polyfills, every browser that matters, should work just fine.
Meepsters@reddit
We ran into massive problems when targeting Linux systems especially with 3D and animations. Worked great on Windows and Mac. We ended up switching back to Electron.
Dead_Internet_Theory@reddit
Maybe ship to Linux as a flatpack / appimage that has more recent Webkit?
It's against the Unix philosophy but valid given the complete disregard.
Meepsters@reddit
We did a version of that in our dev builds for a while. I agree it felt weird
jaskij@reddit
Don't most distros ship WebKit that's quite out of date?
Professional-Disk-93@reddit
Anything with animations runs 10x slower in tauri than in browsers of linux because they ship a 10 year old webkit fork without hardware acceleration. It's useless if you want to ship a cross-platform product.
_zenith@reddit
Tauri shouldn’t be shipping any WebKit, it’s what the OS supplies. So it will be distro dependent
Professional-Disk-93@reddit
Tauri developers themselves have recommended that tauri applications be shipped as appimages with bundled webkit due to incompatibility with the webkit shipped in distributions: https://github.com/tauri-apps/tauri/issues/9662#issuecomment-2489035485
Tauri 1 is incompatible with ubuntu 24.04. Tauri 2 is incompatible with ubuntu 23.10 and earlier.
They have also said that they want to replace webkitgtk with bundled chromium due to the bad performance: https://github.com/tauri-apps/tauri/issues/3988#issuecomment-2774950469
Affectionate_Fan9198@reddit
Sounds like a default “Linux user” issue to me.
raitucarp@reddit
Average users don't want you educate them. So we must do engineering their experience. Not the other way.
Affectionate_Fan9198@reddit
Linux users are not average, they are a minority with a tons of compatibility issues. You can’t target “Linux” like windows or macOS, you use tartget a fuckton of specific distributions and whatever configuration that specific user created for themselves, it is fragmented beyond insanity just in itself.
raitucarp@reddit
That's true. So now, it's all about your marketing strategy. Do you want support your software to run on as many OS as possible, or just wanna put minimum requirements (restrict old linux OS with their unsupported webview engine) and lost potential users, it's all about coverages after all. In my opinion forcing users to update their OS or their default browser is a bad move. We do the best for users by engineering their experiences (helping them to run our software), not the other way around.
Affectionate_Fan9198@reddit
Most of the times it is not economically viable to support Linux, there are too little of them and they will generate a ton of support overhead compared to over platforms (not as a development, as support tickets, something not working, and etc), so losing Linux users may be a good thing. In the end my company just dropped Linux support entirely for regular users, and enterprise receive their own builds because it is a controlled environment.
And if we are speaking about Electron/Tauri, why not just use PWA? PWA platform is quite mature nowadays, and unless you need to load some specific native code there is no point in marking a wrapper app.
Professional-Disk-93@reddit
Electron has no performance or compatibility issues.
Affectionate_Fan9198@reddit
Unless you use nvidia with wayland. :)
But I get your point, and IMO Tauri is in a weird position. They decided to use whatever is bundled with the host system and quickly discovered that anything that is no chrome is crap, while main os (Windows) switched to chrome, so unless you use Tauri specifically for easy of binding Rust to JS in a desktop app (not even as a generic rust to js bridge) it is rather pointless.
CandiceWoo@reddit
this is true - not sure why is it downvoted
Raunhofer@reddit
Sounds like it depends on what platforms you pick.
fojam@reddit
That's just typical web development though
matthieum@reddit
In fact, the Tauri community is making progress on Verso as an alternative WebView, powered by the Servo browser engine, precisely for this reason.
It would be the same model -- Verso would be installed once, no matter the number of Tauri-apps -- and they hope that in the end it could be automatically installed/distributed by the OS, like WebView. Minus the differences.
_zenith@reddit
It shouldn’t be any worse than any other webapp, no? At least for Windows and MacOS, which is almost all of your typical clients.
Parachuteee@reddit
The real problem is Safari tbh. If you work on a project with mostly Safari users, you'll see how painful it is to deal with its stupid bugs. However, desktop safari is much better than iOS safari.
jessepence@reddit
It's rapidly been getting better since Jen Simmons joined the team. They're still lagging on some PWA stuff, but Firefox has some deficiencies too.
When you have a group like the Chrome team who are rapidly blazing ahead all the time, it's not always easy to keep up.
ElvishJerricco@reddit
Sure but part of the selling point of Electron is that you don't have to build a web app that supports all of that.
kostakos14@reddit (OP)
I cannot lie this is what scared me in the beginning. But hopefully with proper polyfills when building if they are needed, and not extremely fancy super latest CSS features it should be fairly homogenous.
I am curious though how big Tauri projects ensure uniformity between OS platforms, if there is a way to test this out.
Ok_Butterfly2250@reddit
The memory benchmark is interesting. On windows memory usage and performance is negligable since electron and Tauri both use chromium. I recall testing on mac too and didn't think the memory difference was that crazy. In the terminal Tauri's memory usage is spread out across multiple processes, so that's what your results remind me of but I'll retest. I'm in the process of transitioning an app from Tauri to Electron. There are a handful of reasons but the most important were: Rust takes a long time to compile after any changes (20+ seconds when my app grew large), windows performance is the same (and it's the largest market), bundle size doesn't matter in 2025, issues with webkit versions that are impossible to debug (pretty sure you can't degrade your safari). After about a year working in this area I came to the conclusion that the only reason to use Tauri over Electron is if your core business logic is in Rust for speed.
kostakos14@reddit (OP)
Interesting points u/Ok_Butterfly2250 !
> a really good article by CERN that did scientific benchmarks into CPU, memory, etc
Did not know about this, thanks for sharing. I guess this is the one you refer?
https://inspirehep.net/files/0bba331a25acb3b6fa9b4071fd6ba9c5
> bundle size doesn't matter in 2025
For thousands of downloads bundle sizes mean egress costs that is compounding. Some companies care about this, as it means traffic cost.
> In the Tauri discord there were lots of talk around bundling a browser in the future
https://www.youtube.com/watch?v=6SO_hRDDGXs
Competitive_Jump4281@reddit
Numbers are insane! Still not going to make me learn Rust, but wow from afar 🤣
pur3pwnage@reddit
For I second I thought it was r/Stargate and I was confused by the title.
Weerdo5255@reddit
Jaffa Kree!
...
I did as well.
DrShocker@reddit
I concur
RealMadHouse@reddit
Why noone is talking about "ToDesktop" ?
kostakos14@reddit (OP)
If not mistaken ToDesktop is a wrapper of Electron?
RealMadHouse@reddit
I don't know, just saw it has its own api
WorkingSubstance7618@reddit
Might as well just benchmark Rust vs JS...
somebodddy@reddit
At the end of the Startup time section it says:
So I clicked that link, and scrolled down to the startup times table. And... and empty Tauri app, build in release mode, takes 25 seconds to start on Linux?
This can't be right...
kostakos14@reddit (OP)
I do not think so but it makes me want to go and try 🤔
vanbrosh@reddit
568% more segmentation fault errors in runtime and 1% probability that your binary which depends on this f*king os-native webview will launch on random machine (windows 7 - 0% probability)
_zenith@reddit
Segmentation faults? You really shouldn’t be getting those. Maybe rust panics if devs have been lazy and been using unwrap
vanbrosh@reddit
Yes, in my app it was not from tauri but from some pretty popular library, for making requests or something, it was terrible because app was running like 10 hours and then crashed randomly, and it was crasily hard to debug,
I just mean this is a whole rust world, because this post compares electron with tauri, so it tries to sell users idea to use rust instead of JS so I posted comment for some new users who should be ready to spend some time debugging segfaults instead of readable exceptions.
oln@reddit
Well the web views and javascript engines the resulting code end up running on are still mostly written in C++ (unless you can target servo somehow but that still relies on some external javascript engine that isn't in rust afaik). If you want the underlying backend to fully benefit from rusts memory safety you need to use a native rust toolkit, not something that does web rendering.
kostakos14@reddit (OP)
Agree, we did not had any seg faults. Again this can happen with C++, which we would use probably if we went with Electron for WebRTC streaming. Any low level implementation could break, with Rust having better chances from not breaking theoretically having better memory-safety
unaligned_access@reddit
Windows 7? What year is it? Electron dropped support too.
vanbrosh@reddit
I am a CEO of software dev team, and you can't imagine how many clients still want support for win 7 still, and this is unfortunately, still reasonable because there are a lot of users in medical/gov sector sits on windows. Electron ships perfectly there, probably not latest version but pretty fresh worked without issue
unaligned_access@reddit
IE6 and Cobol also perfectly ship there. Each tool has it's place.
Plasma_000@reddit
Why comment if you're just gonna make things up?
petereteq@reddit
Are you really sure that the memory consumed by the webview is showing up under same process and not elsewhere?
emdeka87@reddit
On windows it does pretty sure....
kostakos14@reddit (OP)
For MacOS yes, for other OS I am not sure will need to investigate more:
https://gethopp.app/blog/tauri-vs-electron#memory-usage
If you check the images of the post the 'tauri://localhost' is the Webview memory, and the executable path is:
`*/System/Library/Frameworks/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.WebContent.xpc/Contents/MacOS/com.apple.WebKit.WebContent`
Coffee_Ops@reddit
There's a stack of benchmarks that they included a link to which suggest higher memory usage for Tauri compared to electron.
Not only does this not make sense, but it contradicts the article's claims-- which make me wonder why they included it or whether their claims are accurate.
kostakos14@reddit (OP)
Could you share some links here please?
Coffee_Ops@reddit
kostakos14@reddit (OP)
After release (no Debug mode), Tauri has less memory footprint for MacOS + Linux and almost the same in Windows.
Did I miss something? https://share.cleanshot.com/HdQS8KcL
Coffee_Ops@reddit
Yeah its the "almost the same on Windows" that I was looking at.
AKMarshall@reddit
If you are targeting only one and the latest OS then Tauri is fine, else Electron is less trouble for the developers.
kostakos14@reddit (OP)
Depends on the trouble we are talking about. I think if the app you distribute is not having complex CSS or animations you can achieve uniform experience without many headaches.
twinklehood@reddit
There are other limitations due to the limited platform maturity. When I tried a few months back it went something like 'Want to make multiple windows? Use system hotkeys like CMD+Q? Well, pick one, they're incompatible'