300MB of ram sounds like a lot to me. What are you storing in memory that is that large? If I dont use the app for 1 hour will it stop using the memory?

I'm sure that a client like Mutt would use much less but considering that many emails have embed HTML and would ideally use a modern web view to render correctly, how much overhead is there from from using Electron/chromium if you're going to load all of that anyway?

I couldn't find exact figures for MS Outlook but Office 365 seems to require 1Gb as a minimum.

A quick look at the Gmail tab I have open in Chrome seems to be taking roughly 390Mb so this would seem to be an improvement over that.

As a genuine question, what sort of size would you expect for an optimised native app with the same functionality?

For reference, when settled, Gmail in Firefox uses 200MB or a bit more, while FastMail uses around 10MB.

I’m tempted to make a FastMail Electron app just to demonstrate that Electron/HTML/CSS/JS doesn’t need to mean slow and heavy (it just normally does).

Later: OK, so on Windows a trivial Electron “just load https://www.fastmail.com/login (and then log in)” app uses ~230MB of RAM. Not what I was hoping for, though it doesn’t surprise me a great deal—Chrome is quite happy to use lots of memory. Interestingly, when I reduce it from 3000×2000 to 1600×1200 (device pixels, it’s a 2× display), it goes down to about 160MB after a bit, and minimised to 180MB or 120MB for the two window sizes. Still very snappy despite this memory usage, though, for FastMail is fast.

> Gmail in Firefox uses 200MB or a bit more, while FastMail uses around 10MB.

Yes, but that’s not a fair apples to apples comparison with his 300mb number. Your looking at the memory used for that tab, not the shared memory used by the browser across tabs. Open Firefox with no sites open and check your baseline memory usage. Add that to the numbers above for a direct comparison.

I sought only to compare Gmail with FastMail, to indicate that Gmail is a poor baseline for memory comparisons.

Fair point, I agree there!

How exactly will you cut the fat in Electron? What’s a hello world like?

I’m tempted to make a FastMail Electron app just to demonstrate that Electron/HTML/CSS/JS doesn’t need to mean slow and heavy (it just normally does).

See my update to the comment. Its memory footprint is greater than I expected. I shan’t pursue it any further at present, I was mostly just curious to get an initial feel for it. Taking it (or something like it) to a polished product is something I’d like to do, but I’ve got other, much more important things to do on FastMail and Topicbox, and I don’t think anyone else in the company feels strongly about it, so it’s unlikely to ever actually happen.

One avenue would be to use a different, more light-weight engine; https://github.com/zserge/webview, for example, can use the local platform’s engine, which is likely to be somewhere between a little and a lot more efficient than Electron/Chrome. Running FastMail with the MSHTML renderer via the Rust bindings for that (DPI scaling issues, but meh), it starts at about 60MB but is easy to get over 80MB with some use. Still quite a lot less than Electron/Chrome.

Maybe you can help me understand the outcry over Electron memory usage, especially on HH. I can't remember the last time I ran out of memory on my laptop or desktop unintentionally. Seems to me battery life and jank should be main areas of focus. You can have a 2GB if you cut CPU usage and typing latency.

Just because you "can" use a bunch of memory without issues now doesn't mean you "should" not make any attempts to cut resource usage whenever possible.

Of course you're right. But why does it seem like memory usage takes precedence over battery life and latency? I may be in the minority, but it seems to me a native app's key advantage over Electron is performance/watt and I don't see how reduced memory usage would help.

I've run out of memory a few times this week on my Linux VM at work, and also at home on the beater laptop I use in the living room. Those are both stuck at 4GB of RAM, though.

On my laptop with 16GB, it's certainly been at least a few months since I've done anything that made it hit swap.

I said "unintentionally" as a hedge for corner cases like VMs where you are likely aware of the limits. I probably should have been more clear. I also prefer native apps, which is why I still mostly use Sublime over Code despite the latter's advantages. But it's because of speed and battery life, not memory consumption. If we're going to make a case for native apps, lets at least focus on the biggest pain points, as the proliferation of Electron indicates we're not making an impact.

Battery life's something that I only rarely have to think about. All of my development has always been somewhere with convenient power. It irks me when the CPU's churning along on a process that should be near-idle, though.

> I said "unintentionally" as a hedge for corner cases like VMs where you are likely aware of the limits.

I was aware of the limited memory of the VM, but almost everything I run there is a text-mode application, so it usually doesn't matter. Honestly, I thought that Slack would fit easily in the free memory, but I'm logged into 3 teams, so it ate more than I expected. And it's a spinning rust drive; swapping sucks, and it slows down the host OS at the same time.

It's an avoidable situation; just run Slack under the host's Windows, instead of in the Linux VM. But it remains the case, in my uses, that memory has caused more issues than CPU, and that CPU has caused more issues than battery drain. I don't know why everyone else focuses on memory so much...I perceive my own issues as kind of a corner case.

That's it? My Gmail tabs used to take 2GB (the last time I checked, years ago).

Actually, that was just from just loading Gmail and letting it idle, a couple of weeks back, not actually using it. A year and a half ago, I recall it being more like 125MB, up towards 150MB as it was used. Gmail hasn’t really changed since then, but the Hangouts widget (which is pretty heavy!) might have, and the browser definitely has (I blame it for most of the increase). I haven’t actually used Gmail since around that time.

For reference, I’m using the explicit/window-objects/top(…) figure from about:memory. This is not an accurate representation of the full footprint, but is close enough.

> considering that many emails have embed HTML and would ideally use a modern web view to render correctly

It might be me, but i prefer them to be rendered incorrectly in a text-only view :-P. I use email since the 90s and so far i do not think i can come up with any case where the HTML in an email was actually useful and not used for fluff (which i do not mind but can do without), branding (which i do not care at all about) or -way way more often- advertisement.

Also almost all HTML mails i've seen come in text-only version too and any useful bits are attachments anyway.

My Outlook (2016) client is using ~300MB right now while displaying a full HTML spam mail (taking one for the team, guys). I wouldn't say I'm a heavy user, but there's shared calendars and mailboxes, OneNote integration, task list etc.

Concur, my Outlook (2016/365) is currently using 250Mb. That's with 4 mailboxes open, and a heavy HTML email displayed in the reading pane.

Outlook is using 46MB for me at the moment. I don't have a particularly large inbox though.

Outlook is using less than 220MB for me right now, and that's fairly standard. It seems to be fairly optimized.

My Claws Mail currently uses 56M, multiple IMAP accounts configured, a few thousand mails, just visited all accounts before measuring. I disabled HTML display, though (most HTML is either spam or newsletter fluff in my experience). Claws is GTK2.

Most of this comes from overhead in Chromium, which currently (the version used by Ivelope) suffers from a few bugs which increases memory usage. I think this will drastically go down as time progresses and new updates of Chromium becomes available

not intended to be a hostile ask here, but do you know any specific bugs to check out?

As a past (very minor) contributor to chromium+webkit I'm curious if there's anything one can do to help, but I haven't kept up with their status in a long time.

Specifically the image bug, as another commenter linked to: http://seenaburns.com/debugging-electron-memory-usage/

Is this even considered a bug by the Chromium team (i.e. is there any indication of plans to fix it, or is this just the image cache working as intended)?

It's a 10 year old project and memory usage has always been fairly high, I don't see any indication of a major focus on reducing it anytime soon.

I don't hate Electron apps or anything, but the ones I already have open are using up enough of my memory that there isn't much left to run more of them. I really do hope this improves in the future though. If not I may just have to buy more RAM.

Why in this day and age are electron apps this big? What happened to memory management? Is this a faulty aspect of JS or electron itself?

Electron is basically Google Chrome. High memory use has nothing to do with JS.

https://en.wikipedia.org/wiki/Electron_(software_framework)

https://en.wikipedia.org/wiki/Chromium_(web_browser)

That's just the base cost of using electron (along with the associated CPU usage). It's terrifying but you get that much usage even if you're not storing anything in memory.

Well that's just not accurate. With our Electron app, the main process consumes 40mb of RAM, with each window using 30mb of RAM, so if you have a windowed app, thats a minimum of under 70mb of RAM (results will differ, our app is quite large).

Yeah, this is realistic. I wish people would stop perpetuating the myth that "That's just how Electron is". It's perfectly possible to write Electron apps that don't automatically hog half a gig of RAM.

That's news to me, and people who make electron stuff tell me they can't get it down below a few hundred mb of memory usage. Can you point me to some resources about reducing that?

I'm curious too! I found one interesting article about Electron eating memory with images: http://seenaburns.com/debugging-electron-memory-usage/

Are there any examples of Electron apps that don't do that, though? I've never seen one that didn't like to eat at least a few hundred MB, and most of them seem at least somewhat leaky, too.

How are you measuring the RAM usage?

Thunderbird takes 425mo of my ram right now.

I switched from Thunderbird to Gmail because of that; it was quite bad on my laptop. It often started swapping requiring very long waits or a reboot to get back to work.

For comparison, my Thunderbird install with over 60k messages stored locally hits about 220MB.

Ask native thunderbird developers, why Thunderbird take 400 MB of RAM, only after start the programm.

Because Thunderbird is not actually native, it uses Electron's precursor XUL.

> Do you prefer not having it in a conversation view?

I strongly prefer to disable conversation view, because the time (recency) and time interval (frequency) are obscured, at least from the inbox view of most readers.

There is a big difference to me between a thread with 10 emails in one morning, versus one with 9 emails over a week, followed by one this morning.

Awesome app man.

150-300MB seems more than acceptable for a local email client. A pedantic, vocal minority may be over-represented in this thread (it IS HN after all).

IMO Electron apps present significant advantages that justify its negligible cost, eg skinnable with CSS, inspected live with a web inspector, cross platform etc.

> eg skinnable with CSS, inspected live with a web inspector, cross platform etc.

All of these have been possible with Qt circa 2006. (There is no inspector out-of-the-box, but KDAB made one that could be injected via LD_PRELOAD.)

Those are all advantages for the developer. I don't see anything that the user gets for the cost.

More features, faster. My gripe is that I pay 1000 euros for a laptop that will be for 50% consumed by 2 (sometimes even just Slack alone, don't worry) 'because it's convenient for the developer' created apps. The amount of money lost here is staggering ofcourse, but why would devs care as they are not on paying for that. I can totally understand it for a one person shop or an understaffed (underfunded) startup, but companies like Slack are just screwing their users here. Then again, if most of them don't mind that, who are we to complain; it seems to be where we are going. I began taking two laptops; a cheapo chromebook with chromeos to run slack, discord etc in the browser and another one to dev on. Works fine and I don't need to grind my teeth every time I look at top (there is no top as I just run chromeos for ease of use).

I think SyneRyder means what format are you storing emails on disk? If a user uses your email client to download all their pop3 email, is it available in a nice format on disk for whatever reason (backups/file recovery/migration to another client)? Or is it locked up in a custom file format.

>* I think SyneRyder means what format are you storing emails on disk?*

Yup, that's what I wanted to know. Since Thunderbird & Postbox both used the same Mbox Unix format for my 20 year email archive saved on disk, it was very easy to switch between them. And since it's an industry standard, I'm reasonably confident I could export/migrate it to a new email client when I have to - or find someone who has written software to do it.

Recent version of Postbox switched to the Maildir format, which is still, from what I've seen, not production ready in Thunderbird.

Currently it is not a standard format so right now there is no easy import/export - however this is a feature that is coming.

I still have nightmares about Outlook's non-standard format from 15 years ago.

What is the reason you do not store in a standard format?

Consider Dovecot's mdbox maybe?

> It's an Electron app, but it is built to use as little RAM as possible, when I run it on my old Macbook Air, it consumes only around 300mb of RAM maximum

I feel bad but you have already lost me there :/

That is maximum, normal is around 130 - 170 mb

I think the point is that it's better to have something using the native widgets of your OS if possible. It carries much less footprint and it integrates with your OS much more nicely in the end. Webapps running in Electron is just becoming too commonplace.

That also means building a separate UI for every supported OS, which isn't usually feasible for a single developer.

Just an fyi, it looks like you need to include the www for the link to load.

Qt also isn't truly native (it renders its own UI components) and shares many of Electron's drawbacks, so it's only marginally better (and means you have to learn an entirely new platform if you're already familiar with web dev).

> marginally better

Not in terms of resources (CPU/RAM). It's way better than Electron.

I've done it.

I didn't say it's impossible (I've also done it), but for something that's not a full-time job/project, it's a lot of extra work that could be avoided by simply using Electron, especially if you are already familiar with web development but don't have any experience with any of the native platforms.

But the poster did say this was a full-time project.

And I don't believe that only having experience in web development is a good enough excuse for shoehorning web dev things everywhere else.

You're right, I missed the OP saying that. But I still disagree: prior experience with a platform is a great reason for using it. Maybe not for a company with lots of resources, like Slack or Microsoft, but definitely for a small team or individual developer. Any time you would have spent learning a new development platform can instead be spent building new features!

How much RAM does your mail client use?

I use notmuch with Emacs - so very little.

Before that I used mutt - also very little.

Does that support HTML email and images? If not, it seems like a different domain entirely. Other people in this thread have posted Thunderbird numbers and they're in the ballpark. After all, it is rendered in Gecko similarly to how ivelope is rendered in Electron.

Not directly. You can configure w3m to display HTML email, and it does a nice job within the constraints of text mode. Most normal mail, even with tables, renders well. If you get something really crazy you can pipe the message to a graphical web browser to view.

Native Emacs in a GUI can also show inline images (but not when running in a terminal, obviously).

Remote images in email is an anti-feature[0]. And if the images are attached to the email, why not just use an image viewer? Does your email client support video playback?

[0]: https://senglehardt.com/papers/pets18_email_tracking.pdf

That's fine, but there's no point comparing RAM usage between completely different apps like video players and email clients.

Because sometimes discussion centers in and around the images, as in discussion of analysis figures.

Given that it's an Electron app, is there a chance that we could get a Linux build at some point in the future?

Great work by the way!

Yes, multiple people have requested a Linux version and it is coming in the future!

> only around 300mb of RAM maximum

For a email client that is still more than I ever would accept. Do you hold all conversations in the RAM for searchability or something?

Nope, most is Chromium overhead and a bug that the Chromium team are working on. (300mb is maximum, when it's just running and doesn't run into any of the bugs it consumes around 170mb on my computer) I expect Chromium to use less and less memory as time progresses, so RAM will probably decrease in the future.

How much RAM does your current mail client use?

Inbox seems to use about 200mb right now. However this is within Chrome and runs several additional plugins.

When I use mutt I doubt it goes over 20mb.

28mb

But then it is mutt running inside a screen session in an xterm.

Screen is using 4m, and the largest xterm open is using 2.4m. So even adding in screen and xterm overhead that's still only 34.4mb.

Some more questions, as I don't see them addressed on the site:

1. Is there an extension architecture, that I might be able to write my own extensions?

2. Can I edit the "From" address on outgoing mail, and will it remember my preferred "From" address on a per-recipient basis?

3. Does it have extensive keyboard shortcut support, or does it require a mouse?

4. Does it work well with both of the Linux clipboards, the standard system one and the X-provided middle-click one? (Other Electron apps, such as Postman, do not)

1) No extension architecture right now. Do you have anything in mind you'd like to build?

2) Not at the moment, but it supports multiple email accounts at once and you'll be able to move emails effortlessly between accounts in the near future.

3) Yes, it has extensive keyboard shortcut support

4) It hasn't been released for Linux yet, but once it will, I'll make sure to try to address this issue.

> 1) No extension architecture right now. Do you have anything in mind you'd like to build?

Not yet, but I assure you that I will! Especially if the answer to the next question is negative...

> 2) Not at the moment, but it supports multiple email accounts at once and you'll be able to move emails effortlessly between accounts in the near future.

I have literally thousands of "accounts" as I have a catch-all domain that I've been using since 2001. I need the ability to edit the "From" address, minimum. And if I'm going to use the email client regularly, then it needs to remember the "From" address to use on a per-recipient basis. That is what extensions are for!

> 3) Yes, it has extensive keyboard shortcut support

Terrific!

> 4) It hasn't been released for Linux yet, but once it will, I'll make sure to try to address this issue.

You are welcome to contact me for testing. muszc-master splat dotancohen spot com.

Consider Electrino (https://medium.com/dailyjs/put-your-electron-app-on-a-diet-w...)

From what I can tell, Electrino is a dead project. Looks like someone picked up the idea and is making another called Quark (https://github.com/jscherer92/Quark) though.

Sounds very interesting, although Ivelope interacts a lot with the OS, and a lot of the Electron API would need to be added.

Oh its electron :( Sorry not for me, please rather make a roundcube replacement out of it.

>many people won't use them, mostly for the technical reasons

I really don't think that's true outside of the HN echo chamber. Like OP, I am using a Macbook Air which is hardly a supercomputer and vscode runs perfectly fine on it.

There is almost universal hatred of the Slack app in our client relations department, due to performace. All use Mac laptops or Windows desktops, none of them know the term "Electron".

I wonder why people run slack stand-alone. I run it as a pinned tab in my browser and with browser notifications it works great. Very few issues running it this way and performance seems good.

I have Chrome users for browsing, personal email, work email and Slack. I had Slack in a separate Chrome window, in a pinned tab. I noticed that changing to my communications space was slow. By eliminating windows one-by-one, I discovered, the culprit was the Slack pinned tab. I tried the Slack standalone app instead, and that slowness is gone. I can't explain why, but the standalone native app may actually perform better. I think it's worth checking out.

I've gone back and forth between in-browser and stand-alone, but as my number of Slack teams grows, browser tabs get considerably less appealing. (I have five I monitor regularly and four more I don't care much about.)

Can't you build something "to use as little RAM as possible, given that it's using Electron"?

This conversation seems more analogous:

"I raise elephants, but they are bred to be as small as possible."

"They're _either_ elephants, _or_ bred to be as small as possible."

I'll accept that! Thank you for the perspective.

That is a tough question but if presented to me in the context of this thread I would probably respond, that it is a poor analogy.

Why do we have to make this complicated? The creator is using Electron, and within that given framework putting focus on RAM optimization. Moving on.

Programs do a lot more than they used to. Even though they solve similar problems as their predecessors. 300MB is perfectly fine for a modern app when computer team is measured in GB.

> For an application that deals with primarily with downloading, uploading, and displaying text.

Emails have become much more than that. They can contain almost everything a webpage can.

Most browsers use a ton more ram than 300 MB.

I call the F150 pickup I drive small. It is compared to the F350’s and semi that I’ve also driven.

In absolute terms it may be big. But for an electron app it’s probably not too bad.

Telegram is not an Electron app. It's a Qt app written in C++.

At least on Mac you can get the telegram app, or something called Telegram Desktop, which is Electron-based

If you mean this, it's written in C++ https://desktop.telegram.org/

If you mean this, it's written in Swift https://macos.telegram.org/

Telegram is not an electron app. It's native C++ and QT

The official telegram desktop client is Qt.

>FWIW I use the Telegram client which is an Electron app

What OS are you using Telegram in?

CentOS 7.3