Live data from Hacker News

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

ivelope.com

151–160 of 608 posts

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

#151

Of course I have to ask if you've looked at JMAP ( http://jmap.io/spec.html ). More because we're getting close to finishing the spec, and feedback from someone who's build a client recently about whether the spec suits their needs would be valuable!

Hi! I really like the initiative of JMAP, however I haven't been able to look into it properly - I can give you a better answer once I've done that, my email is in my profile

Thanks for that - I'll pop you an email.

I'll be in Munich in June for M3AAWG and then popping over to Paris to meet the Linagora team and chat with them about their JMAP work - don't think I can come up with an excuse to visit Sweden this trip sadly :(

My next trip after that is Montreal in July for IETF102. Hopefully we'll be finalising core and mail specs at that conference, hence the interest in getting feedback now! Easier to fix spec issues before publishing.

I've done a bunch of implementation on two different servers, so I'm comfortable with that half, but we only really have one client implementation in-house (hence wanting to chat to Linagora about theirs!)

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

#152

Earlier quoted context omitted.

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?

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

#153

No offense but unless it’s a 1st party client email clients are something that is very hard to trust. Who controls your client has access to your inbox with most services even the few that have separate IMAP/POP3 passwords like Hushmail can be compromised through it. If your client also integrates with encryption or worse takes charge of it my encryption key is also now at risk. Lastly since email today is pure HTML…

So unless you have the source or show an audit from a respected firm (c53, isec etc.) its going to be quite hard to recommend to anyone to take the dive and try this out.

Please. How many times a day do you enter a password somewhere on your computer? Do you look at the source or ask for an audit for every one of those apps?

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

#154

Earlier quoted context omitted.

For me, an additional concern is being tied to this client after using it. Every offline mail client has its own storage formats (mbox, maildir, SQLite, another database or a mix of these), and so moving across clients is not an easy exercise unless the clients support multiple formats for import. I would also like to see how the client behaves when one single mailbox is more than 20GB in size, with at least one of t…

> Claims that searches happen in milliseconds need to state the size of the mailbox I'd honestly outsource the indexing and searching to something like mairix which is designed purely for this purpose. (On my 4.5GB Maildir, 57 folders, 111k emails, mairix takes 205s to index from scratch. Incremental updates are <5s. Worst search I've yet done took 0.5s to return 13k hits for 'bank'.)

Or "notmuch" which has integration with Mutt and similar mailboxes, and it has GMail-like tagging and boolean searches.

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

#155
post #99

Earlier quoted context omitted.

It is not about popularity, it is about the resources Electron apps use vs native. The apps that you mentioned do not have good native alternatives. I cannot see anyone preferring a native app over Electron app if both offer the same features.

I prefer VS Code over native alternatives. Don't conflate your anecdotal evidence with facts. Many users don't know much RAM a process consumes or what an Electron app is, they just care about what the app can do, how fast it is, etc.

>I prefer VS Code over native alternatives.

That's because, as the parent said, there are no good (e.g. equivalent) native alternatives.

If there was a native editor with feature parity with VS Code (including the number of plugins and dedicated MS resources speeding up its development, and free), nobody would be using it.

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

#156
post #99

Earlier quoted context omitted.

It is not about popularity, it is about the resources Electron apps use vs native. The apps that you mentioned do not have good native alternatives. I cannot see anyone preferring a native app over Electron app if both offer the same features.

Do you mean, you cannot see anyone preferring an Electron app over a native app?

All other things being equal of course not.

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

#157

Earlier quoted context omitted.

Do you mean, you cannot see anyone preferring an Electron app over a native app?

That's almost never the choice though is it? Who offers an Electron app and a native app? So the choice becomes use an Electron app or something else entirely.

Nobody, but many offer an Electron app for things where equally good native apps exist.

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

#158

Earlier quoted context omitted.

That's almost never the choice though is it? Who offers an Electron app and a native app? So the choice becomes use an Electron app or something else entirely.

The choice is actually more interesting. Although big companies such as Slack potentially have resources to support development for multiple platforms, even they can implement new features faster due to Electron. Think about all those small teams that just wouldn’t be able to port their apps anywhere without it. So in some ways I’d probably prefer a good Electron app.

For this, a mail client, I doubt there'd actually be much saving going native - it's going to need browser level HTML either way. So here Electron may have negligible cost. Thunderbird easily goes over 300M when it's been running a while for instance.

For other things I'm far less keen as Electron is often a sign of a needless memory hog - 100M pomodoro timers and such like.

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

#159
post #38

God bless you for working in a space—native email clients—which seems utterly neglected nowadays.

It's not native, looks like an electron app

Bear in mind that any email client will need an HTML engine of some form for rendering HTML emails (even if it doesn’t use it for the entire UI), unless it makes the radical decision of being text-only.

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

#160
post #106

Earlier quoted context omitted.

> And considering the rumours about macOS, probably wise to avoid writing native Mac code just now. What rumors?

Apple is dropping Intel chips & replacing them with their own CPUs in Macs in 2020 [1], and working on a unified development API where you'll develop one app for iPhone & iPad that will also run on the Mac, so you won't need to write Mac specific apps anymore [2] [3]. It's all rumour & could be wrong. But there's some who feel macOS only has a couple of years left before being discontinued. In that climate, an Electr…

I wish them luck, but Microsoft tried this already (Universal Windows Platform).

One thing I fear is that keyboard shortcuts, particular the F-keys, will become a thing of the past.

Post reply on HN