Live data from Hacker News

I've spent the last two years building a new email client

ivelope.com

321–330 of 608 posts

Re: I've spent the last two years building a new email client

#322
post #189

Earlier quoted context omitted.

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.

Re: I've spent the last two years building a new email client

#324
post #277
post #203

Earlier quoted context omitted.

Ask yourself why more people don't use Qt: (1) With web technologies you can write once and run everywhere including mobile to some extent. Writing a UI multiple times is monumentally expensive. Even huge companies don't like to do this, let alone indie efforts and startups. If Slack with its billion dollars doesn't do it what does that say? (2) The ecosystem is far more active. The web is the largest open source eco…

"Qt isn't that much less bloated than Electron, especially when you start styling it and get dynamic." Given how many smart people are working to make the browser techs as efficient as possible, and the way that things like QT get "bloated" as soon as they start trying to do what browsers do, I've pretty much arrived at the idea that once you have images and an engine that can reflow text and load fonts and so on, an…

I agree with that to some extend, but the fact is, except for some very specific cases like vscode, I not only don't need "styling and dynamic", but I don't want it to be.

My OS has UI semantics. I want most of the apps to work the same everywhere. Your app is not special. Stop reinventing a "visual identity". Give me congruency and features.

Re: I've spent the last two years building a new email client

#325

Earlier quoted context omitted.

> 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.

Re: I've spent the last two years building a new email client

#326
post #302

Earlier quoted context omitted.

One of the things we’re really hoping with JMAP is that, by drastically lowering the barrier of entry (because doing IMAP/POP3/SMTP well is hard ), people will be able to experiment much more, making things like Ivelope, because they can start making UI almost immediately rather than shaving IMAP yaks first. I have a talk planned entitled “building a fair dinkum email client in half an hour with JMAP”—because you gen…

It looks like JMAP is on top of HTTP - does this mean a normal browser could speak it directly? How is new mail notification handled? Polling?

Push subscription and EventSource: http://jmap.io/spec-core.html#push

The FastMail web UI will soon (later this year, we plan) be speaking JMAP. What it speaks at present is a precursor to JMAP.

Re: I've spent the last two years building a new email client

#327

This is just advertising... showing a product on HN, but requiring you to "invite" others? Too bad, I was actually willing to try the software. I'm not going to invite others if others can't use the software, or without trying it for myself first...

I'm sorry if it came across as advertising, let me clarify: you NEVER have to invite others to get access, however if you do, you have the chance to get access sooner - I think this is fair. I definitely understand your concern of not sharing it and you do not have to share it to get access.

That sounds reasonable enough, but how fast is your queue moving? I'm 3,800 something - will I remember this show HN when I get access? :)

Re: I've spent the last two years building a new email client

#328

Earlier quoted context omitted.

> Electron would be a deal breaker You say that like HTML emails don't exist. If the client has to embed a web view anyway...

My laptop has a limited amount of memory, CPU time and battery life.

So... you make it a point not to read html emails on it?

Re: I've spent the last two years building a new email client

#329
post #306

Earlier quoted context omitted.

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 i…

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.

Re: I've spent the last two years building a new email client

#330

Earlier quoted context omitted.

1. 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, which is less than what Finder consumes, and I consider everything over this limit to be a bug. 2. Currently not supporting Mbox/Maildir but downloading emails directly from the server, however an import of this is on the todo list 3. Re: turn off conversation v…

> 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 :/

How much RAM does your mail client use?
Post reply on HN