Live data from Hacker News

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

ivelope.com

191–200 of 608 posts

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

#191
post #86

This looks pretty cool, I'm really pleased to see people writing new email clients, and you've clearly worked very hard on this! I have a bunch of questions that I couldn't find out from the website (but are obscure enough that I shouldn't expect to): * Is this a purely native app, or an Electron / Javascript app? Personally I'm only interested in native apps & Electron would be a deal breaker - but I'm weird, most p…

You're not wrong on electron: this tech allow devs to be lazy and we all know that when we are allowed to be lazy, most of the time we are. That said, electron can have a small fingerprint if the dev team is carefull/good enough, and is hte best option when your app have to be able to read HTML (and copy HTML formatted string). To me, an email client is a good way to use electron for an app.

And let's not forget that thunderbird ui itself is rendered using gecko.

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

#192

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…

> Lastly since email today is pure HTML Where did you get that idea? If your email is pure HTML all I'll see is your markup, if it makes it through the spam filter to begin with which assigns a pretty stiff penalty for sending me HTML mail.

On a related note, any email that’s “pure HTML” or mostly HTML is something I don’t even open, mainly because such emails tend to be of the marketing and tracking kind, where viewing it would send various signals to the sender. If anyone has something important for me to read, they better put it in plain text.

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

#194
post #164

This looks pretty cool, I'm really pleased to see people writing new email clients, and you've clearly worked very hard on this! I have a bunch of questions that I couldn't find out from the website (but are obscure enough that I shouldn't expect to): * Is this a purely native app, or an Electron / Javascript app? Personally I'm only interested in native apps & Electron would be a deal breaker - but I'm weird, most p…

Every recent new app I can remember installing in the last year is Electron. Native UI is dead. It's more work and all it really buys you is the privilege of being tied forever to one platform or having to code your UI multiple times. The effort of writing your UI three times to use three different proprietary UIs would be better spent optimizing Electron for less resource use. In the long term web will totally repla…

Or you use qt. Which is cross plateform, native, fast and open source.

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

#196

Earlier quoted context omitted.

I think the largest inbox ever tried in Ivelope so far is around 10GB and from what I heard from that user, there were no major problems - but I haven't made any measurements. A few people have requested mbox import and it is on the todolist.

Since you responded elsewhere that your client stores mails in a proprietary format, one very important product goal should be an export mechanism that can export to one, if not more, of the common formats (mbox, maildir, etc.). After all, if you’re confident on your client’s features as the USP to get customers, you should also easily allow those who want to move out to do so. I personally wouldn’t try our client fo…

Of course, I haven't put my focus on this yet, but it is on the todo list.

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

#197
post #180

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…

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

[deleted]

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

#198

This looks interesting. One can see the two years of work that went into this. Is there a way to follow the development as a bystander? Something like a newsletter, blog, twitter or any other kind of feed?

Thank you for your feedback! If you sign up for an invite, I'll let you know once something like this is up and running.

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

#199
post #60

Earlier quoted context omitted.

Did someone review your code? 2 years working on your own sounds like a caveman.

Yes, I was basically a caveman, and I'm currently looking for more developers

Please don’t take this negatively. The “bus factor” here is 1. That’d be a concern for many users (especially ones who have used corporate email systems and have higher expectations on the longevity of a client). More so when combined with the other feedback I gave on having export options for the mail to standard formats.

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

#200
post #189

Earlier quoted context omitted.

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/
Post reply on HN