Hello,
I am writing cause I wanted to get some opinions from folks here that have actually built and shipped with Electron (or Tauri).
Background: Building an API IDE on Electron. Not really “just an API client”, and not a(nother) thin wrapper around a webapp either. It’s a pretty original desktop tool with a lot of editor/IDE-like behavior - not the typical form centric behavior that postman or others have: local workflows, richer interactions, and some things that honestly would have been much harder for us to build and iterate on this quickly in a more constrained setup. Thats why Electron.
this is the tool: github.com/voidenhq/voiden
Now, as adoption is growing, we are starting to get the usual questions about memory footprint and app size.
The (slightly) frustrating part is this:
When the app is actually being used, the app-side memory is often pretty reasonable. In many normal cases we are seeing something like 50–60 MB for the actual usage we care about (even added it in the app itself for people to check it out).
But then people open Activity Monitor, see all the Chromium/Electron-related processes, and the conversation immediately becomes:
“yeah but Tauri would use way less”
And then, without realizing, I suddenly end up talking and philosophizing about Electron, instead of discussing the tool itself (which is what I am passionate about :)
And of course, I get it. The broader footprint is real. Chromium is not free. Electron has overhead. Pretending otherwise would be foolish. So we are constantly optimizing what we can, and we will keep doing so…
At the same time, I do feel that a lot of these comparisons feel weirdly flattened. For example people often compare:
full Electron process footprint VS the smallest possible Tauri/native mental model
…without always accounting for development speed, cross-platform consistency, ecosystem maturity, plugin/runtime complexity, UI flexibility, and the fact that some apps are doing much more than others. Which is by the way the reason that we went with Electron.
So all this context to get to my real question, which is:
- How do you explain this tradeoff to users in a way that feels honest and understandable, without sounding like you are making excuses for Electron?
And also, for those of you who have had this conversation a hundred times already:
-
What do you say when people reduce the whole discussion to “Electron bad, Tauri good”?
-
Have you found a good way to explain footprint in practical terms?
-
Where do you think optimization actually matters, vs where people are mostly reacting to the idea of Electron?
Mostly trying to learn how others think about this , especially those who have built more serious desktop products and had to answer these questions in the wild.
Would love your thoughts and advice!
I would make an FAQ. I think for getting tone it is important to know what things are hard facts, what things are more subjective preferences, and what’s things are “we had to make a choice between options with no clear ‘best’ option”.
yes thats a good idea, we actually made an FAQ that sits with our docs…I want to monitor to see if this helps people navigate some of these questions:)
The best thing to do is ignore anything anyone on Lemmy tell you, and use the tools the let you deliver the highest quality software. Those tools may be different for you than they are to me. People here have too many strong opinions, and you will never find a stack that makes them happy.
thanks! well, the feedback and the questions did not come from lemmy per se but in general. And yes, I agree with you. People do have strong opinions and this is more a question for me - as I often feel that perhaps there is some “better” way to explain or show the impact of the decision. (and explain the trade off). But I think that ultimately you are saying one simple (but very important) thing: that you can not please everyone :)
Yeah. And if you like talking about the stack, that’s cool, but you should be able to talk about the project you’re passionate about without people criticizing some stack choice you made. If it’s a good app, then the stack is good enough imo.
You don’t have to. If they have an issue with it they can fork it build the tool how they like it.
cynically true :)
without always accounting for development speed, cross-platform consistency, ecosystem maturity, plugin/runtime complexity, UI flexibility, and the fact that some apps are doing much more than others
From the perspective of a user, why would they care about development speed? A user, by sheer definition of wanting to use the software, can only use software that is already developed. If it’s not actually developed yet… they can’t use it. So either they see the software at the end of the development cycle, or they never see it at all. Development speed simply isn’t relevant to a user at that point. (exception: video games, but I’m not aware of any desktop game developed using a web framework)
As for platform consistency, again, why would the user care? Unless each user is actually running the same software on multiple platforms (ie a Windows user at work, Arch at home, and BSD at their side-gig), this is a hard sell to get users to care. A single-platform user might never see what the same software looks like on any other platform. Even mobile apps necessarily differ in ways that matter, so consistency is already gone there.
What I’m getting at is that the concerns of developers will not always be equally concerning to users. For users to care would be to concern themselves with things outside of their control; why would they do that?
hm…great points, thanks for taking the time to answer.
From the perspective of a user, why would they care about development speed?
Yes, the tool is already developed but it will continue evolving right? I mean, we almost make 2-3 releases every month since we shipped the first version and then open sourced. So the speed still counts. Plus, the users who create the tickets and expect them to be tackled are actually developers themselves. So yeah, the ability to deliver (at a good pace) to these folks matters a lot.
However - YES, if at some point the tool is at a state that the speed becomes less meaningful or useful, then indeed a change might be needed?
As for platform consistency, again, why would the user care?
Yes, since our users are Dev (and QA) folks, we thought that yeah, maybe someone could have different systems for work vs home vs side project (as you said). But another aspect that we thought is teams and collaboration. We didn’t want to have a scenario in which a team can not use it before some of the devs are using macs, others linux vs the QA folks using windows etc.
What I’m getting at is that the concerns of developers will not always be equally concerning to users.
Thats the heart of the discussion:) I guess because our users are also developers. :)
How do you explain this tradeoff to users in a way that feels honest and understandable, without sounding like you are making excuses for Electron?
To people who dislike Electron due to its size, I don’t think you can. To someone with that mindset, saying “we are seeing something like 50–60 MB for the actual usage” itself sounds disingenuous.
However most people don’t seem to care that much about the size of Electron. Most people I know expect a modern system to have enough ram for it to not matter.
Yeah, honestly, sometimes I feel frustrated trying to explain it, because I know some people will never be satisfied. I just want to be transparent about the tradeoffs and let people SEE the actual usage (even if it will indeed not convince everyone).
It’s the usage they see used, not what the app itself is using. It’s like someone borrowed your car and paid for for just the gas and not the wear and tear. It matters to the PC user that they have less to go around and would rather use something without the overhead. I’m not against overhead when it makes sense, I use docker at home and kubernetes at work.
nice metaphor:) but unlike a car, these Electron processes aren’t slowly eating your tires or draining your oil. Maybe a better metaphor would be that the car you rent comes with a few extra cup holders you that you didn’t ask for? :)
Ehh, I dislike electron as I don’t like chrome and it uses up more of the computer, especially with a low powered laptops and thin clients. I would rather just have something hosted on a server, preferably my own, and use a webpage. Cupholders don’t get in the way usually or take up performance of the car.
