Hacker News Reader

Comment by fabiospampinato | Hacker News Reader

As a developer of an Electron app to me a competing framework that doesn't bundle its own rendering engine doesn't make sense, why would I want to trade control over how my app is rendered for ~100MB of disk space?

I might as well just ship a website at that point, almost everything that makes Electron appealing comes from shipping your own rendering engine.

View on HN

Apple's brand new iMacs with the M1 CPU only have 8 GB of RAM.

If every little desktop widget loads its own browser engine, most of that RAM will be spent on redundant copies of Chromium.

If your Electron app is something that you expect users to run almost exclusively, then no problem. If it's just another little client app for some service, please consider a solution that would reduce its memory footprint.

That's a fair point, but just ship a website then, much easier and pretty much same result.

It makes sense to use frameworks like Electron if they enable new capabilities for your app, and Electron is very good at that, bundling Node.js with it, which allows you to share code between frontend and backend and tap into the same ecosystem of packages, plus chances are you already know Node.js, Tauri is enabling 0 of this, at least presently.

> much easier and pretty much same result.

Actually better results even, because under macOS for example the webview is provided by Safari, but if you are using Chrome/Firefox as your browser of choice and you are using a Tauri app now you are using 2 browsers effectively, while if you ship a website you can use that website with whatever browser you prefer.

And with WebView, RAM will be spent on redundant copies (instances) of WebView.

If it's the same system dll, then it'll share all of the RO segments.

That's not how system frameworks work.

Order of magnitude memory reduction, not disk space, was the selling point last time I heard. And given how often I hear users complaining about memory consumption in Electron apps, I think that is something pretty attractive, if it pans out.

> Order of magnitude memory reduction

That doesn't make sense to me, you are still using a browser at the end of the day. Sure you can save some memory by not bundling Node (at the cost of making even reading a file much more difficult), but that's not orders of magnitudes.

Also electron require multiple node backend services which each eat memory like crazy (based on electron app I use).

Have one, real Multithreaded +, more efficient backend, will reduce memory and offer better performance.

Wails is also an alternative that does just that. Shared Web UI engine + Go compiled backend.

> Also electron require multiple node backend services which each eat memory like crazy (based on electron app I use).

AFAIK Electron requires 1 Node instance (you can disable it for renderer processes and you can have 0 WebWorkers or only WebWorkers with Node.js disabled) which consumes like ~50MB or something like that, which probably accounts for stuff other than Node.js too, if the app you are using require multiple Node processes that use huge amounts of memory they are just badly written.

> Have one, real Multithreaded +, more efficient backend, will reduce memory and offer better performance.

You can't just share Node.js across multiple apps, Tauri just doesn't bundle it at all, which is a whole different story with mostly downsides from my point of view.

> just badly written.

Ins't the easy answer. Each time a dev want to ignore valid comments.

I have the following electron app running: Spotify, Figma, VS Code, Discord, Slack. They all use more than 1 helper. Consuming between 600mb to 3.5gb.

Slack is much better than it was. But I wish they switch to something like Tauri or Wails in the future.

Of those apps I can only say that VS Code is well written and that Spotify is junk.

Is 600mb too much for VS Code? I guess it depends on what you are doing with it and which extensions you have installed etc., if you are running a pretty bare-bones installation and seeing 1GB+ memory usages in VS Code please open an issue in their issue tracker and tag me (same username as in HN).

> Slack is much better than it was.

And that didn't happen by switching to the website approach, I think you'll be disappointed if any of these apps end up switching to Tauri or Wails without significantly improving their code too. Which is why I'd predict no major player will jump ship.

for my work, vscode take between 1.5 to 2.5gb. Nothing has change since start using it 4 years ago, and my experience is consistent with my coworkers. I keep using it because it 'feels' the best overall. No magical issue will fix that, node is memory hungry as is java.

Calling an app junk to justify is argument is unconvincing. Its still a widely used app that works as good as the competition. In the case of slack, their optimisation endeavour seems to cost them quite a lot. But sure I don't have the number. If they would have start the project in Tauri or Wails at the beginning, would that saved them the refactoring? I don't now. But we will need more team using that kind of alternative to gain the knowledge and real benefit.

At this point I rewriting a toy project from electron to wails and its great. But well, it's only a toy project.

> for my work, vscode take between 1.5 to 2.5gb.

That sounds like a lot, you are probably running some heavy extensions or too many of them I guess, could you post a screenshot of the "process explorer" window for your instance of vscode?

> Calling an app junk to justify is argument is unconvincing.

I couldn't care less about what you think about Electron, that's just what I think.

Now it's a browser that was probably already in memory for one reason or another, not necessarily a process per Tauri app.

That's a good point, that will save you some memory unless you happen to be in a scenario where for example you use Chrome under macOS and a single Tauri app, which would then use Safari under the hood, meaning still multiple browsers.

But I think that would save much less memory than people think. A bare-bones hello-world Electron app consumes about ~100MB of RAM (rough figure since it depends on many factors), maybe you can bring that down to ~20MB by sharing a common browser instance (I doubt it, a Chrome tab takes like ~50MB for me right now), but if your app uses 1GB+ of memory that has way more to do with how the app is coded than by having to spawn another instance of the browser. Basically you won't get a memory hungry app consuming 10x less memory by running it as a website.

Not if you take one of the biggest selling points of Electron.

Im working on something not quite the same thing but that deal with all this, and being able to ship with a web rendering engine and not using whatever its on the system is actually better giving all the power, bindings, compromise you can make that you are unable when you can only deal with a abstract wrapper to every web rendering engine out there.

Lower memory footprint but with much less features and a generic "no sir, cant do such a thing.." as a answer to users that will need important features to ship applications with this.

Of course it's less convenient for developers not to ship a rendering engine. But should developers' need always come before users' needs, especially for applications that live and run on their own PCs?

Its not also about user needs, given the final application will have access to more functionality, also guaranteeing things will work.

I agree that Electron is user hostile in the way it uses memory, but there's an answer in between the Electron and what Tauri is offering here.

Tauri could have a embedded engine and yet propose a better architecture and better use of memory in consequence. The best of both worlds.

In Chrome for instance, each tab is equivalent to a app, giving is a whole isolated process and yet it doesnt kill your machine even with many tabs open.

you can't ship your own rendering engine on ios

> why would I want to trade control over how my app is render for ~100MB of disk space?

it depends how much you respect your users

> you can't ship your own rendering engine on ios

That's irrelevant, just because I can't do some things on iOS doesn't mean that I shouldn't do them under desktop OS' too.

Just one example: file system watching, if I need to do that with Electron I'll just use `chokidar` and have it working in no time, plus I can share whatever frontend code with the backend too, good luck doing the same with Tauri (given the current state of things anyway).

> it depends how much you respect your users

I don't know what kind of users you've got but mine care about me iterating quickly on the app, care about having new features, care about having a faster app. Most of them would consider trading any of that for ~100MB of disk space stupid.

As I said, if disk space is all you care about you might as well just ship a website.

100 MB on disk is less than 0.1% of a typical consumer SSD. Memory and processor usage is the concern.

It's about memory management more than it is binary size. Rust is notorious for being turbo-charged with every LLVM optimization on gods green earth, so much so that the actual syntax of the language is beholden to the opinion of the compiler. Either way, I see it as a great step in the right direction, and would be perfect for apps like Discord or Spotify.

Most of the memory usage will come from the renderer process, which in a Tauri app is still a browser.

And most people have problem eith Electron's ram usage, which I don't think this addresses. No one really cares about 100mb

Reply on news.ycombinator.com