Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ivelope.com

Post reply on HN
Print view View original

351–360 of 608 posts

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

#351

Post by jchook »

muszc-master wrote: post #59
SyneRyder wrote: post #34

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…

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…

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.

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

#352

Post by herbst »

sp332 wrote: post #332
herbst wrote: post #180

Earlier quoted context omitted.

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

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.

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

#353

Post by ams6110 »

sp332 wrote: post #341
BeetleB wrote: post #339

Earlier quoted context omitted.

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

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

#354

Post by hjek »

newscracker wrote: post #192
jacquesm wrote: post #77

Earlier quoted context omitted.

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

Exactly. HTML email is a privacy hell[0]. However, many email clients can work around this, e.g. in Mutt you can let Lynx do a plaintext dump of the HTML email.

Also, the whole issue of JavaScript in HTML emails at least deserves a mention[1]. Since Ivelope is an Electron app, I'd guess it would go ahead and just run everything it receives, right?

[0]: https://freedom-to-tinker.com/2017/09/28/i-never-signed-up-f...

[1]: https://stackoverflow.com/questions/3054315/is-javascript-su...

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

#355

Post by rootlocus »

coldtea wrote: post #267
rootlocus wrote: post #177

Earlier quoted context omitted.

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

Which is what I use. But ST3 doesn't have the full power of a 20+ strong MS team behind it, but a single person (and another hired to help here and there), and so doesn't have the same momentum -- and it's getting behind in features as well.

I never kept tabs on the development effort on neither VSCode nor Sublime Text, but it was always my impression that much of the power either editor has comes from 3rd party extensions rather than the editor core. As such, I believe it was the hype around Atom and VSCode that drove people to write extensions for them, leaving ST behind.

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

#356

Post by hjek »

sp332 wrote: post #341
BeetleB wrote: post #339

Earlier quoted context omitted.

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.

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

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

#357

Post by ksk »

vijaybritto wrote: post #93
pjmlp wrote: post #72

Earlier quoted context omitted.

That is a matter of skills doing native UIs.

Yes, exactly! Not everyone has the hardcore skillset to make great cross platform software. So much so that even behemoths like Microsoft write electron apps to get work done. He is using his web skillset to make a product that runs everywhere. If anything, this shows some serious good qualities in the developer that he wants to get the product to multiple people and not ponder over perfection.

Giving up 1% of performance every day will give you an app that is twice as slow.

I think its a trade-off between productivity and performance. This skillset used to be non-hardcore just a few years back, just like programming using ASM used to be a non-hardcore skillset before that. The middle ground could be managed languages like C# or Java.

>So much so that even behemoths like Microsoft write electron apps to get work done.

But getting work done != release code. Sure, everyone writes ugly hacks to get stuff done, but usually its either an internal tool or a temporary stop-gap.

>If anything, this shows some serious good qualities in the developer that he wants to get the product to multiple people and not ponder over perfection.

If you're competing with other mail clients that already exist (not identical clones, but more or less similar) , would you want to release something that works or something amazing that takes time, but also has a high chance of not succeeding? Depends on your philosophy. Some people choose the latter.

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

#358

Post by boomlinde »

sp332 wrote: post #334
jlgaddis wrote: post #331

Earlier quoted context omitted.

FWIW, I can read HTML e-mails just fine via mutt in an SSH session. One doesn't need Chrome or Firefox to read them.

Could you go into a little more detail about this setup?

Not GP, but there are browsers that can render and dump HTML to plain text, like Lynx. You can of course also run remote X programs, but that seems a bit clunky.

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

#359

Post by saurik »

chrismorgan wrote: post #313
mike-cardwell wrote: post #220

Earlier quoted context omitted.

I'm not convinced that JMAP existing will make it easier for people to develop things like Ivelope. I don't know in this particular case, but if I were writing Ivelope I wouldn't first write an IMAP library of my own. I'd use an existing one. And all commonly used languages have pre-existing IMAP libraries anyway. I doubt the ability to do "var client = new JMAP()" instead of "var client = new IMAP()" will lead to a…

I perceive that you haven’t ever tried programming against IMAP or making a MUA, or not seriously at least. IMAP is a mess if you try to do much beyond the basic “retrieve list of folders, retrieve messages, now just leave it alone”; and most IMAP client libraries are worse than IMAP need be. There are many extensions for many features, poorly supported in various clients and servers, and various things that are slow…

(Yes: I have personally implemented IMAP, and SMTP, and in fact even Seieve, all from scratch. No: I did not find writing a fully compliant parser difficult, and I have no sympathy for people who seem incapable of writing one.)

> You can do it, and many clients have over the years, but you will sacrifice a lot, like the ability to search multiple folders efficiently.

By "folders", I will assume you mean "mailboxes" (as that is how most, if not all, existing clients and servers choose to represent "folders"). This was addressed in RFC 7377. I realize that you will argue "but what servers actually implemented that?", but the answer is "probably more than have decided to implement JMAP".

That said, JMAP has chosen to unify labels and folders into a term "mailboxes". The same solution applies to IMAP: I think a more correct usage of IMAP is to unify labels and folders into what IMAP calls "flags" (as opposed to what IMAP calls "mailboxes") at which point I think you will find that 90% of the struggles people have with IMAP disappear.

I realize that no IMAP server does this, but that is for historical reasons related to how mail was stored on disk and I think totally ignores what makes IMAP as a protocol interesting. I honestly feel like a lot of people just never took the time to understand either IMAP (or Mark Crispin) (or how to quickly write a parser :/) and then spent decades complaining about the annoying and limited ways people mapped semantics.

That all said, I would at least begrudgingly agree that for some simple use cases, JMAP is likely convenient for certain classes of mail consuming systems. But come on... to try to claim that IMAP is somehow not designed for online usage or is somehow broken for that usage is such a totally disingenuous claim that I will go so far as to say that it outright slanders the memory of Mark Crispin, who seriously seemed to believe people writing offline email clients with persistent caches that required synchronization were embarking on a "fools errand", and (for better or for worse) effectively assumed servers would always be better than local hardware.

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

#360

Post by saurik »

dogma1138 wrote: post #24

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…

Do you run any non-sandboxed software from any non-"first party" on your computer? If you do, that software also already has access to your entire email inbox.
Post reply on HN