Oh goodness, another electron app...
...another electron app that wouldn't exist if the UI has to be done with a GL based UI lib by a single person.
I've spent the last two years building a new email client
181–190 of 608 posts
Re: I've spent the last two years building a new email client
#182You are not weird. More and more people think that Electron is bad
This is an "all my friends voted for..." argument. Electron applications such as Slack, Discord, and VS Code have ballooned in popularity over the last year or two. Hacker News comments are not representative of the whole.
Popular does not mean good. In fact, it often means the opposite.
Re: I've spent the last two years building a new email client
#183Thanks for your interest in local email clients, more choice there is welcome!
In the description it is said one can file email with a key, by associating folders to keys. Keyboard operation is very important to me. However direct key/folder association doesn't scale to a large number of folders. Have you considered a feature like the "Nostalgy" extension for Thunderbird? [1]
With Nostalgy one type "s" to file/save an email, then a string which is matched to folder names. It's a bit like helm for emacs (except it's exact match, space is not interpreted as an "AND" like with helm). The commands are go/save/copy, and then string match. This scales very well. That could be an advanced feature, as for beginners the direct key/folder association is simpler. But I guess you will target advanced users too, and for them it may be an important feature.
[1] https://addons.mozilla.org/en-US/thunderbird/addon/nostalgy/
Re: I've spent the last two years building a new email client
#184Earlier quoted context omitted.
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.
Probably. Spark takes up around 200M on my laptop, so it's not that big of a deal.
Re: I've spent the last two years building a new email client
#185Earlier 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?
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.
Re: I've spent the last two years building a new email client
#186I have a side question for those who dislike electron apps (or prefer native):
1. Which OS do you use use? I'd love to know if it's skewed to a particular OS to know which platform to prioritize a native client.
Re: I've spent the last two years building a new email client
#187Earlier 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…
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 for serious use otherwise.
Re: I've spent the last two years building a new email client
#188how did you sustain yourself working on this fulk time for free?
Re: I've spent the last two years building a new email client
#189Earlier quoted context omitted.
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?
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.
Re: I've spent the last two years building a new email client
#190Thanks for your interest in local email clients, more choice there is welcome! In the description it is said one can file email with a key, by associating folders to keys. Keyboard operation is very important to me. However direct key/folder association doesn't scale to a large number of folders. Have you considered a feature like the "Nostalgy" extension for Thunderbird? [1] With Nostalgy one type "s" to file/save a…
Sounds cool, will check it out!