13 ms·

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 th

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 people won't care. * What format are you using for email archives? Mbox, Maildir? Can I import my Thunderbird / Postbox Mbox archives of 21 years of email? * Can I turn off threaded & conversation views? * Do you support POP3? (You only mention IMAP... I'm sure that would be fine, but I still have accounts configured via POP3.) * Can I change priority of individual messages after they arrive? I sort my inbox by priority and then date-descending, not by date. I'm a hardcore Postbox user and email is critical infrastructure for me, so I probably won't try it or switch anytime soon... but I'm always keeping an eye on powerful desktop email clients, in case I ever need to switch, or find something dependable that really blows away Postbox. Well done! Looks very promising!

muszc-master 9y ago
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 view: not at this time. Do you prefer not having it in a conversation view? 4. No POP3 yet 5. I think you can achieve this using folders/labels in Ivelope Thanks for the positive encouragement! Edit: formatting
- yani 9y ago
  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?
  - muszc-master 9y ago
    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
    - wcarss 9y ago
      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.
      - muszc-master 9y ago
        Specifically the image bug, as another commenter linked to: http://seenaburns.com/debugging-electron-memory-usage/ http://seenaburns.com/debugging-electron-memory-usage/
        opencl 9y ago
        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.
  - Kliment 9y ago
    That's just the base cost of using electron (along with the associated CPU usage). It's terrifying but you get that much usage even if you're not storing anything in memory.
    - 9y ago
- s_kilk 9y ago
  Given that it's an Electron app, is there a chance that we could get a Linux build at some point in the future? Great work by the way!
  - muszc-master 9y ago
    Yes, multiple people have requested a Linux version and it is coming in the future!
- stedaniels 9y ago
  I think SyneRyder means what format are you storing emails on disk? If a user uses your email client to download all their pop3 email, is it available in a nice format on disk for whatever reason (backups/file recovery/migration to another client)? Or is it locked up in a custom file format.
  - muszc-master 9y ago
    Currently it is not a standard format so right now there is no easy import/export - however this is a feature that is coming.
    - ryan-c 9y ago
      Consider Dovecot's mdbox maybe?
    - BeetleB 9y ago
      I still have nightmares about Outlook's non-standard format from 15 years ago. What is the reason you do not store in a standard format?
  - SyneRyder 9y ago
    >* I think SyneRyder means what format are you storing emails on disk?* Yup, that's what I wanted to know. Since Thunderbird & Postbox both used the same Mbox Unix format for my 20 year email archive saved on disk, it was very easy to switch between them. And since it's an industry standard, I'm reasonably confident I could export/migrate it to a new email client when I have to - or find someone who has written software to do it.
    - sashk 9y ago
      Recent version of Postbox switched to the Maildir format, which is still, from what I've seen, not production ready in Thunderbird.
- herbst 9y ago
  > 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?
  - muszc-master 9y ago
    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.
  - deleted 9y ago
    [deleted]
  - sp332 9y ago
    How much RAM does your current mail client use?
    - herbst 9y ago
      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.
    - pwg 9y ago
      28mb But then it is mutt running inside a screen session in an xterm. Screen is using 4m, and the largest xterm open is using 2.4m. So even adding in screen and xterm overhead that's still only 34.4mb.
- dotancohen 9y ago
  > It's an Electron app, but it is built to use as little RAM as possible It's _either_ an Electron app, _or_ built to use as little RAM as possible. I'm not an Electron hater, but if you are starting out with Electron then you are already at a far disadvantage both technically (see aforementioned RAM usage) and politically (many people won't use them, mostly for the technical reasons). FWIW I use the Telegram client which is an Electron app, but I would never use a text editor (Atom), email client, or other Electron app given an equivalent app based on C[++], Python, or even Java.
  - blowski 9y ago
    Can't you build something "to use as little RAM as possible, given that it's using Electron"?
    - dotancohen 9y ago
      OP says that it uses "only 300 MB" of RAM. For an application that deals with primarily with downloading, uploading, and displaying text. How would you respond to someone saying "I raise small mammals, well small given that they are elephants"?
      - d-sc 9y ago
        I call the F150 pickup I drive small. It is compared to the F350’s and semi that I’ve also driven. In absolute terms it may be big. But for an electron app it’s probably not too bad.
      - justtopostthis3 9y ago
        This conversation seems more analogous: "I raise elephants, but they are bred to be as small as possible." "They're _either_ elephants, _or_ bred to be as small as possible."
        dotancohen 9y ago
        I'll accept that! Thank you for the perspective.
- dotancohen 9y ago
  Some more questions, as I don't see them addressed on the site: 1. Is there an extension architecture, that I might be able to write my own extensions? 2. Can I edit the "From" address on outgoing mail, and will it remember my preferred "From" address on a per-recipient basis? 3. Does it have extensive keyboard shortcut support, or does it require a mouse? 4. Does it work well with both of the Linux clipboards, the standard system one and the X-provided middle-click one? (Other Electron apps, such as Postman, do not)
  - muszc-master 9y ago
    1) No extension architecture right now. Do you have anything in mind you'd like to build? 2) Not at the moment, but it supports multiple email accounts at once and you'll be able to move emails effortlessly between accounts in the near future. 3) Yes, it has extensive keyboard shortcut support 4) It hasn't been released for Linux yet, but once it will, I'll make sure to try to address this issue.
    - dotancohen 9y ago
      > 1) No extension architecture right now. Do you have anything in mind you'd like to build? Not yet, but I assure you that I will! Especially if the answer to the next question is negative... > 2) Not at the moment, but it supports multiple email accounts at once and you'll be able to move emails effortlessly between accounts in the near future. I have literally thousands of "accounts" as I have a catch-all domain that I've been using since 2001. I need the ability to edit the "From" address, minimum. And if I'm going to use the email client regularly, then it needs to remember the "From" address to use on a per-recipient basis. That is what extensions are for! > 3) Yes, it has extensive keyboard shortcut support Terrific! > 4) It hasn't been released for Linux yet, but once it will, I'll make sure to try to address this issue. You are welcome to contact me for testing. muszc-master splat dotancohen spot com.
- _o_ 9y ago
  Oh its electron :( Sorry not for me, please rather make a roundcube replacement out of it.
- gervase 9y ago
  > Do you prefer not having it in a conversation view? I strongly prefer to disable conversation view, because the time (recency) and time interval (frequency) are obscured, at least from the inbox view of most readers. There is a big difference to me between a thread with 10 emails in one morning, versus one with 9 emails over a week, followed by one this morning.
- on_and_off 9y ago
  > 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 :/
  - muszc-master 9y ago
    That is maximum, normal is around 130 - 170 mb
    - ekianjo 9y ago
      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.
      - RussianCow 9y ago
        That also means building a separate UI for every supported OS, which isn't usually feasible for a single developer.
        majewsky 9y ago
        https://qt.io https://qt.io
        sincerely 9y ago
        Just an fyi, it looks like you need to include the www for the link to load.
        RussianCow 8y ago
        Qt also isn't truly native (it renders its own UI components) and shares many of Electron's drawbacks, so it's only marginally better (and means you have to learn an entirely new platform if you're already familiar with web dev).
- WrtCdEvrydy 9y ago
  Consider Electrino (https://medium.com/dailyjs/put-your-electron-app-on-a-diet-with-electrino-c7ffdf1d6297 https://medium.com/dailyjs/put-your-electron-app-on-a-diet-w...)
  - muszc-master 9y ago
    Sounds very interesting, although Ivelope interacts a lot with the OS, and a lot of the Electron API would need to be added.
  - maemilius 9y ago
    From what I can tell, Electrino is a dead project. Looks like someone picked up the idea and is making another called Quark (https://github.com/jscherer92/Quark https://github.com/jscherer92/Quark) though.
- jchook 9y ago
  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.
  - majewsky 9y ago
    > eg skinnable with CSS, inspected live with a web inspector, cross platform etc. All of these have been possible with Qt circa 2006. (There is no inspector out-of-the-box, but KDAB made one that could be injected via LD_PRELOAD.)
  - s73v3r_ 9y ago
    Those are all advantages for the developer. I don't see anything that the user gets for the cost.
    - tluyben2 8y ago
      More features, faster. My gripe is that I pay 1000 euros for a laptop that will be for 50% consumed by 2 (sometimes even just Slack alone, don't worry) 'because it's convenient for the developer' created apps. The amount of money lost here is staggering ofcourse, but why would devs care as they are not on paying for that. I can totally understand it for a one person shop or an understaffed (underfunded) startup, but companies like Slack are just screwing their users here. Then again, if most of them don't mind that, who are we to complain; it seems to be where we are going. I began taking two laptops; a cheapo chromebook with chromeos to run slack, discord etc in the browser and another one to dev on. Works fine and I don't need to grind my teeth every time I look at top (there is no top as I just run chromeos for ease of use).
orwin 9y ago
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.
- sametmax 9y ago
  And let's not forget that thunderbird ui itself is rendered using gecko.
- lallysingh 9y ago
  Re: lazy: some would call that get more stuff done faster and cheaper.
- dspillett 9y ago
  I prefer to use the word "efficient"! Or for advanced situations "selectively efficient" - using something other than Electron for an app that is intended to be cross-platform because [insert-alternative-here] is smaller/faster/other may be an example of premature optimisation and using something else (especially where that involves learning something else) could mean trading off elsewhere.
- c-smile 9y ago
  "this tech allow devs to be lazy" Not just Electron but Sciter too in that sense. "electron can have a small fingerprint if the dev team is carefull/good enough" Only to some extent. You will have two separate process (at least) in any case and so two sets of the same system libraries loaded in them, IPC between them, etc. Main task of browser engine is to provide safe browsing experience. Presenting HTML is only second its task and so browser based UI will always be sub-optimal (at best).
api 9y ago
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 replace desktop UI. This could have been avoided if Apple, MS, and Linux would have agreed on a common desktop UI API 5-10 years ago but the ship sailed.
- gsich 9y ago
  One could have used e.g Qt.
- sametmax 9y ago
  Or you use qt. Which is cross plateform, native, fast and open source.
  - api 9y ago
    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 ecosystem in history. There is code to do literally everything and an embarrassment of riches when it comes to libraries, frameworks, connectors, etc. (3) Qt isn't that much less bloated than Electron, especially when you start styling it and get dynamic. (4) Long build times mean that I have to wait a lot longer between dev/test. UI development tends to be a whole lot of iterative hack-test-hack-test. With web tech it's literally edit-refresh, which is much faster than edit-make-wait-launch. (5) To make Qt look good you have to start styling and using its weird surprisingly web-like stylesheets, which takes you out of pure native mode and into a hybrid rendering mode. At that point I'm halfway to browser rendering. (6) If you code UIs with web tech you also get the web, meaning your app could be run remotely in a browser as well as locally. This is the networked app promise of X11, Citrix, etc., and you get it for free. Electron is popular because it delivers a ton of value in terms of cross-platform compatibility, reduced effort, rapid development, consistency, and ecosystem. Performance and memory use problems can be fixed. I have been watching this project: https://github.com/andlabs/libui https://github.com/andlabs/libui It's a genuinely lightweight wrapper that looks really promising. Trouble is everyone I show it to says "ugly" as their first comment. Everyone wants styled apps today with polished UIs and that takes you down a path that looks increasingly like CSS whether you like it or not. I also have this strong feeling that if I wrote with it I'd be rewriting in 5 years after desktop UIs are abandoned in favor of 100% web technology everywhere. Of course web UIs shift a lot too. Maybe the fate with UIs is to rewrite every 5 years no matter what.
callahad 9y ago
> 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...
- jasonkostempski 9y ago
  An small library for viewing static HTML is nothing compared to a virtual machine and dynamic rendering engine constantly causing unnecessarily high demand on memory, CPU and battery.
- darpa_escapee 9y ago
  My laptop has a limited amount of memory, CPU time and battery life.
  - dentemple 9y ago
    So... you make it a point not to read html emails on it?
    - jlgaddis 9y ago
      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.
      - sp332 9y ago
        Could you go into a little more detail about this setup?
        boomlinde 9y ago
        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.
        pwg 9y ago
LandR 9y ago
> Electron would be a deal breaker - but I'm weird Guess I'm weird too.

muszc-master 9y ago

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 view: not at this time. Do you prefer not having it in a conversation view? 4. No POP3 yet 5. I think you can achieve this using folders/labels in Ivelope Thanks for the positive encouragement! Edit: formatting

yani 9y ago
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?
- muszc-master 9y ago
  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
  - wcarss 9y ago
    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.
    - muszc-master 9y ago
      Specifically the image bug, as another commenter linked to: http://seenaburns.com/debugging-electron-memory-usage/ http://seenaburns.com/debugging-electron-memory-usage/
      - opencl 9y ago
        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.
- Kliment 9y ago
  That's just the base cost of using electron (along with the associated CPU usage). It's terrifying but you get that much usage even if you're not storing anything in memory.
  - 9y ago
s_kilk 9y ago
Given that it's an Electron app, is there a chance that we could get a Linux build at some point in the future? Great work by the way!
- muszc-master 9y ago
  Yes, multiple people have requested a Linux version and it is coming in the future!
stedaniels 9y ago
I think SyneRyder means what format are you storing emails on disk? If a user uses your email client to download all their pop3 email, is it available in a nice format on disk for whatever reason (backups/file recovery/migration to another client)? Or is it locked up in a custom file format.
- muszc-master 9y ago
  Currently it is not a standard format so right now there is no easy import/export - however this is a feature that is coming.
  - ryan-c 9y ago
    Consider Dovecot's mdbox maybe?
  - BeetleB 9y ago
    I still have nightmares about Outlook's non-standard format from 15 years ago. What is the reason you do not store in a standard format?
- SyneRyder 9y ago
  >* I think SyneRyder means what format are you storing emails on disk?* Yup, that's what I wanted to know. Since Thunderbird & Postbox both used the same Mbox Unix format for my 20 year email archive saved on disk, it was very easy to switch between them. And since it's an industry standard, I'm reasonably confident I could export/migrate it to a new email client when I have to - or find someone who has written software to do it.
  - sashk 9y ago
    Recent version of Postbox switched to the Maildir format, which is still, from what I've seen, not production ready in Thunderbird.
herbst 9y ago
> 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?
- muszc-master 9y ago
  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.
- deleted 9y ago
  [deleted]
- sp332 9y ago
  How much RAM does your current mail client use?
  - herbst 9y ago
    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.
  - pwg 9y ago
    28mb But then it is mutt running inside a screen session in an xterm. Screen is using 4m, and the largest xterm open is using 2.4m. So even adding in screen and xterm overhead that's still only 34.4mb.
dotancohen 9y ago
> It's an Electron app, but it is built to use as little RAM as possible It's _either_ an Electron app, _or_ built to use as little RAM as possible. I'm not an Electron hater, but if you are starting out with Electron then you are already at a far disadvantage both technically (see aforementioned RAM usage) and politically (many people won't use them, mostly for the technical reasons). FWIW I use the Telegram client which is an Electron app, but I would never use a text editor (Atom), email client, or other Electron app given an equivalent app based on C[++], Python, or even Java.
- blowski 9y ago
  Can't you build something "to use as little RAM as possible, given that it's using Electron"?
  - dotancohen 9y ago
    OP says that it uses "only 300 MB" of RAM. For an application that deals with primarily with downloading, uploading, and displaying text. How would you respond to someone saying "I raise small mammals, well small given that they are elephants"?
    - d-sc 9y ago
      I call the F150 pickup I drive small. It is compared to the F350’s and semi that I’ve also driven. In absolute terms it may be big. But for an electron app it’s probably not too bad.
    - justtopostthis3 9y ago
      This conversation seems more analogous: "I raise elephants, but they are bred to be as small as possible." "They're _either_ elephants, _or_ bred to be as small as possible."
      - dotancohen 9y ago
        I'll accept that! Thank you for the perspective.
dotancohen 9y ago
Some more questions, as I don't see them addressed on the site: 1. Is there an extension architecture, that I might be able to write my own extensions? 2. Can I edit the "From" address on outgoing mail, and will it remember my preferred "From" address on a per-recipient basis? 3. Does it have extensive keyboard shortcut support, or does it require a mouse? 4. Does it work well with both of the Linux clipboards, the standard system one and the X-provided middle-click one? (Other Electron apps, such as Postman, do not)
- muszc-master 9y ago
  1) No extension architecture right now. Do you have anything in mind you'd like to build? 2) Not at the moment, but it supports multiple email accounts at once and you'll be able to move emails effortlessly between accounts in the near future. 3) Yes, it has extensive keyboard shortcut support 4) It hasn't been released for Linux yet, but once it will, I'll make sure to try to address this issue.
  - dotancohen 9y ago
    > 1) No extension architecture right now. Do you have anything in mind you'd like to build? Not yet, but I assure you that I will! Especially if the answer to the next question is negative... > 2) Not at the moment, but it supports multiple email accounts at once and you'll be able to move emails effortlessly between accounts in the near future. I have literally thousands of "accounts" as I have a catch-all domain that I've been using since 2001. I need the ability to edit the "From" address, minimum. And if I'm going to use the email client regularly, then it needs to remember the "From" address to use on a per-recipient basis. That is what extensions are for! > 3) Yes, it has extensive keyboard shortcut support Terrific! > 4) It hasn't been released for Linux yet, but once it will, I'll make sure to try to address this issue. You are welcome to contact me for testing. muszc-master splat dotancohen spot com.
_o_ 9y ago
Oh its electron :( Sorry not for me, please rather make a roundcube replacement out of it.
gervase 9y ago
> Do you prefer not having it in a conversation view? I strongly prefer to disable conversation view, because the time (recency) and time interval (frequency) are obscured, at least from the inbox view of most readers. There is a big difference to me between a thread with 10 emails in one morning, versus one with 9 emails over a week, followed by one this morning.
on_and_off 9y ago
> 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 :/
- muszc-master 9y ago
  That is maximum, normal is around 130 - 170 mb
  - ekianjo 9y ago
    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.
    - RussianCow 9y ago
      That also means building a separate UI for every supported OS, which isn't usually feasible for a single developer.
      - majewsky 9y ago
        https://qt.io https://qt.io
        sincerely 9y ago
        Just an fyi, it looks like you need to include the www for the link to load.
        RussianCow 8y ago
        Qt also isn't truly native (it renders its own UI components) and shares many of Electron's drawbacks, so it's only marginally better (and means you have to learn an entirely new platform if you're already familiar with web dev).
WrtCdEvrydy 9y ago
Consider Electrino (https://medium.com/dailyjs/put-your-electron-app-on-a-diet-with-electrino-c7ffdf1d6297 https://medium.com/dailyjs/put-your-electron-app-on-a-diet-w...)
- muszc-master 9y ago
  Sounds very interesting, although Ivelope interacts a lot with the OS, and a lot of the Electron API would need to be added.
- maemilius 9y ago
  From what I can tell, Electrino is a dead project. Looks like someone picked up the idea and is making another called Quark (https://github.com/jscherer92/Quark https://github.com/jscherer92/Quark) though.
jchook 9y ago
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.
- majewsky 9y ago
  > eg skinnable with CSS, inspected live with a web inspector, cross platform etc. All of these have been possible with Qt circa 2006. (There is no inspector out-of-the-box, but KDAB made one that could be injected via LD_PRELOAD.)
- s73v3r_ 9y ago
  Those are all advantages for the developer. I don't see anything that the user gets for the cost.
  - tluyben2 8y ago
    More features, faster. My gripe is that I pay 1000 euros for a laptop that will be for 50% consumed by 2 (sometimes even just Slack alone, don't worry) 'because it's convenient for the developer' created apps. The amount of money lost here is staggering ofcourse, but why would devs care as they are not on paying for that. I can totally understand it for a one person shop or an understaffed (underfunded) startup, but companies like Slack are just screwing their users here. Then again, if most of them don't mind that, who are we to complain; it seems to be where we are going. I began taking two laptops; a cheapo chromebook with chromeos to run slack, discord etc in the browser and another one to dev on. Works fine and I don't need to grind my teeth every time I look at top (there is no top as I just run chromeos for ease of use).

orwin 9y ago

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.

sametmax 9y ago
And let's not forget that thunderbird ui itself is rendered using gecko.
lallysingh 9y ago
Re: lazy: some would call that get more stuff done faster and cheaper.
dspillett 9y ago
I prefer to use the word "efficient"! Or for advanced situations "selectively efficient" - using something other than Electron for an app that is intended to be cross-platform because [insert-alternative-here] is smaller/faster/other may be an example of premature optimisation and using something else (especially where that involves learning something else) could mean trading off elsewhere.
c-smile 9y ago
"this tech allow devs to be lazy" Not just Electron but Sciter too in that sense. "electron can have a small fingerprint if the dev team is carefull/good enough" Only to some extent. You will have two separate process (at least) in any case and so two sets of the same system libraries loaded in them, IPC between them, etc. Main task of browser engine is to provide safe browsing experience. Presenting HTML is only second its task and so browser based UI will always be sub-optimal (at best).

api 9y ago

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 replace desktop UI. This could have been avoided if Apple, MS, and Linux would have agreed on a common desktop UI API 5-10 years ago but the ship sailed.

gsich 9y ago
One could have used e.g Qt.
sametmax 9y ago
Or you use qt. Which is cross plateform, native, fast and open source.
- api 9y ago
  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 ecosystem in history. There is code to do literally everything and an embarrassment of riches when it comes to libraries, frameworks, connectors, etc. (3) Qt isn't that much less bloated than Electron, especially when you start styling it and get dynamic. (4) Long build times mean that I have to wait a lot longer between dev/test. UI development tends to be a whole lot of iterative hack-test-hack-test. With web tech it's literally edit-refresh, which is much faster than edit-make-wait-launch. (5) To make Qt look good you have to start styling and using its weird surprisingly web-like stylesheets, which takes you out of pure native mode and into a hybrid rendering mode. At that point I'm halfway to browser rendering. (6) If you code UIs with web tech you also get the web, meaning your app could be run remotely in a browser as well as locally. This is the networked app promise of X11, Citrix, etc., and you get it for free. Electron is popular because it delivers a ton of value in terms of cross-platform compatibility, reduced effort, rapid development, consistency, and ecosystem. Performance and memory use problems can be fixed. I have been watching this project: https://github.com/andlabs/libui https://github.com/andlabs/libui It's a genuinely lightweight wrapper that looks really promising. Trouble is everyone I show it to says "ugly" as their first comment. Everyone wants styled apps today with polished UIs and that takes you down a path that looks increasingly like CSS whether you like it or not. I also have this strong feeling that if I wrote with it I'd be rewriting in 5 years after desktop UIs are abandoned in favor of 100% web technology everywhere. Of course web UIs shift a lot too. Maybe the fate with UIs is to rewrite every 5 years no matter what.

callahad 9y ago

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

jasonkostempski 9y ago
An small library for viewing static HTML is nothing compared to a virtual machine and dynamic rendering engine constantly causing unnecessarily high demand on memory, CPU and battery.
darpa_escapee 9y ago
My laptop has a limited amount of memory, CPU time and battery life.
- dentemple 9y ago
  So... you make it a point not to read html emails on it?
  - jlgaddis 9y ago
    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.
    - sp332 9y ago
      Could you go into a little more detail about this setup?
      - boomlinde 9y ago
        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.
      - pwg 9y ago

LandR 9y ago

> Electron would be a deal breaker - but I'm weird Guess I'm weird too.