It's unfortunate that this wasn't build with a cross-platform core, but native, first class UIs for each respective platform.
Edit: I realized this was worded very badly. I’m saying I wish this was written with a cross platform core, and native, platform specific UIs for each respective platform. For example, MS Office is written this way.
I'd personally think "amazing" is a better adjective than "unfortunate" here - the value of an e-mail client, at least to me, lies almost entirely in its user interface. If using a native stack can squeeze out a few more tidbits of usability here and there, that's a good job well done. There's still a lot of value in native if it's done properly.
Electron and similar technologies are in my opinion not quite at the point where they can compete with the best that native platforms can offer. I'm sure that will change one day, but we're not there yet.
GTK integration on windows and mac is also less than perfect - I've been using geany on multiple platforms a lot recently and it's a great tool, but there's small annoyances like that the "swipe to scroll" speed varies massively between it and Notepad++.
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.
Actually I meant that 2 years should be enough as well not 5+, given the adequate skillset.
As for Microsoft, I think that have been invaded by JS devs on their way to re-invent and refresh the company's culture.
Regarding the OP, yes he should be appreciated by taking the effort of spending two years doing this software, it is just a pity that it yet another Electron app.
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.
Looks great! I'm always curious what it means when people say they've worked x years on something. Was this a full time project @ 40/h a week every week, or more of a few hours on the weekends, or maybe something in the middle?
I agree! I'm frequently paying for software even if I won't use it after a year just to test how well it works. Unpaid is not sustainable. But having source code (Maybe GPL?) is also important.
If the choice is between paying with money and paying with my personal data, managing my e-mail is one of the things where I'm happy to pull out the credit card. (That's why my e-mail accounts are on places like fastmail instead of gmail.)
I get paid money for the software I develop too, after all.
For some of us, email is so important that we are prepared to pay a LOT for a really great client. I'm currently paying around $150/year for Photoshop - email is more important to me than Photoshop. For the right program, I would happily pay $99 for a major release. I think that's what I used to pay for Eudora many years ago.
Postbox currently only charges $40 for a lifetime free-upgrades license. In my case, they are definitely leaving money on the table, I would've paid a lot more.
What features of Postbox do you use that are not available in Claws (or derivatives) or Thunderbird? Serious question, I've love a better email experience.
In any case Postbox is not available on Linux, but I'd still like to know.
It's so long since I've switched that I'm not sure anymore, but Postbox tried to be more Mac-like and had native integration with macOS Contacts instead of separate address books. I think it had some filter rules Thunderbird didn't have, and faster indexed search.
But now, I use the keyboard driven Tagging & Quick Move features [1] a lot. They work a bit like Alfred [2]. To file a message in my Filtered folder, I type "v fil Enter" and by the time I've typed v, an Alfred-like window pops up that autocompletes the full folder names as I type - so by the time I get to 'fil', it's autocompleted to the right one and I can hit enter. Standard keyboard shortcuts too like j to junk, a to archive, etc. I'm sure Thunderbird also has these via extensions, but I like having it in the core product supported by the core developers.
There's a word count warning feature that I use a lot too, because I tend to type a lot. The word count turns red when I go over my suggested self-imposed limit, or you can set a timer for when you've been composing one email for too long.
EDIT: I saw you asked elsewhere about editing the From field, Postbox has a pulldown menu on each message you compose where you can choose from a list of profiles / aliases you create. Each can even have their own SMTP server details & default signatures & are separate from inbox accounts. You can switch signatures on individual messages too.
Thanks. In fact the time-limits on writing an email is a great idea! I should generalize that into a timer app for writing email, browsing HN, Wikipedia, etc.
Alfred looks interesting. Other than the workflows, almost everything it does is already integrated into KDE. However it looks easy to use and I will definitely check it out if I move to one of the company Macbooks. Thank you!
No problem for paying a good mail-client.
I use it every day and if it saves me time (e.g. conversiation view, or better search) i will pay for it.
Would be nice if a bigger company sponsors such a project, then a greater audience will use it and the Developer could concentrate on developing and not on selling.
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.
This looks very impressive. I'm currently looking for a new email app but my biggest concern with email applications is their longevity, do you have any plans for funding this? (I'm not so concerned what the model is, just that there is one.)
> Total privacy - we do not have access to your email account, Ivelope only sends your email data and password between your computer and your email server.
I wish this was the default assumption these days.
What is the reason to build it as a native software instead of a webapp? Seems like a lot of email clients are now webapps and I can see the arguments why.
Because of Privacy concerns! The thinking is that few people would enter their email and email password on a 3rd-party website, having it as a downloadable software ensures the privacy of users
On a desktop app, you can see what kind of request the program makes and which servers it contacts. With a webapp, you'll never know what the app does.
The logic is a native app can make a direct IMAP connection to the mail server and you can check it is doing so where as a web app has to send the login details to a server which does IMAP for the client and you can not see this last part.
You can do the same in your browser by opening the developer tools and in fact it comes built in to the browser whereas on a desktop you'd have to install another app like Wireshark/Fiddler to see those requests.
Nothing will. The vulnerability of what happens to your data after it is sent to a third party is the same for any app, web or native.
The biggest difference is that it's way easier to see where you're data is being sent in a browser, since it has built in tools. It's very hard to monitor native app traffic that is sent over SSL.
It's not possible to make a web-based email client that speaks to the IMAP/SMTP server directly. Only a "native" (electron can do this) client can use those protocols.
Running it locally is fine, but a hassle if I need to access my mail on someone else's hardware (or my phone). I think this is one of the main reasons Gmail is so popular.
You can still see to which servers the software connects, ostensibly the only servers would be those for sending and receiving your emails. If you're feeling particularly paranoid you could enforce this behaviour using a firewall. For web based email anything could happen and you would have no way of knowing, even after the fact.
This doesn't make any sense as a motivation, let alone the primary motivation, to build a native app in the age of web apps. There's no real difference in security here and the user perception gain is marginal and ephemeral.
What's the reason not to, other than not knowing how to build it as native software?
Possibly only to render the HTML in some emails (and why not, then, just open them in the user's existing browser window,) but otherwise, there seems (to me) to be little about email that requires the overhead of a browser engine and associated Node dependencies and whatnot.
A native app could be smaller, faster, and use less RAM.
Thank you! This is built using Electron, so it is basically JavaScript. Given the interest of this post I'll try to make a blog post later on all the challenges and lessons learned
This looks amazing, I can't wait to try it out. My main problem with Thunderbird is that it doesn't have a conversation-based UI, but this looks like it does. Good stuff!
(By the way, typo: "accessable" should be "accessible")
There is an extension for Thunderbird called Thunderbird Conversations [1] for a conversation based UI that provides a look similar to Gmail (though it may not look like chat, which is possible and would look nice only for those who exchange short one or two sentence emails). As that addon says, "Don't forget to hit View > Sort By > Threaded in the menus." to use it. Perhaps this extension would help you.
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 you also inherit all the possible vulnerabilities that come with having a DOM parser and a layout engine and even modem browsers still get both wrong.
And using something like Electron or even Chromium won’t implicitly save you because the way you implement them matters a lot and now you are tied with their update cycle which might break functionality forcing you to manually backport security fixes which is hard to accomplish.
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.
Unfortunately, I agree with you. I'm saying "unfortunately" because it's such a shame that this sector is so closed off to innovation from smaller players just because it has become too important in our lives.
I might try this client with a throwaway email account, but never with something important.
That is correct but it's a slightly different threat model that I don't want to tackle here.
I'm not going to make claims that a developer would maliciously embed code into their own product but I do care about the quality of their code and their security practices at large (specifically how secure is their code promotion and binary distribution supply chain).
> Total privacy - we do not have access to your email account, Ivelope only sends your email data and password between your computer and your email server.
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 the folders being around 3-4GB by itself. Claims that searches happen in milliseconds need to state the size of the mailbox and the folders (and also include enough variability in the content for the index to be large enough).
I certainly like the idea of new email clients, especially those that integrate with Exchange calender (a weak point for Thunderbird even with extensions). But in my view, building a fast, robust and feature rich email client would take about an effort of 10-30 person years or even more, depending on the feature set. This one seems to stand at a mere two person years, and so my expectations would be quite low (though it's still in beta and states upfront some of the important features it's missing).
> 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'.)
Interesting, thanks! Trying that now. Took twice as long (13m) to index my folders (and ignoring a whole bunch of fake-mbox files that seem to be coming from my gmail-to-local forwarding) but the searching is about the same kind of speed as `mairix`.
I had a very quick look at the mairix repo on GitHub, and I'm not sure what to make of at least one pull request (about large mailboxes) that has no comments on it for a few years. Though it's an old project, I just wanted to confirm that it's still good enough to use without too many issues and also check if you're using the main one [1] or any of the other forks. [2]
Couldn't tell you offhand, sorry - I'm using the Arch Linux community package which doesn't explicitly state where it's coming from. Currently v0.24-1 if that helps figure it out.
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.
I built a webmail client from scratch many years ago and I agree with the security concerns.
In my case the credentials were not a problem with displaying inline HTML securely was difficult to get right. Back then there was no CSP.
He isn't trying to take away from the achievement, just highlighting some legitimate security concerns.
IMHO this is justified since people often overlook how critical an attack vector this would be.
Imagine if a state-sponsored "hobbyist" posted a pet project like the OP to Reddit and started harvesting keys/password reset capabilities for huge amounts of users.
Hell, people flocked to use unroll.me and then it turned out they were (predictably) scraping your entire inbox and selling the data to advertisers.
I don't believe that worrying somebody's skepticism might hurt feelings is a legitimate reason to downvote (remember, downvotes aren't about whether you agree with somebody; it's about whether they add constructively to discussion).
Aside: Great work OP. Seems like an incredibly hard sector to make traction with though, so best of luck.
Well said. It's very impressive and I have a lot of hopes for the future but I feel the concerns are very valid and if OP wishes to take this to the next step, he/she needs to be aware of the security implications and possibly figure out a way to help address them.
Regardless, I'm really glad there are more people trying to fix the problem of email.
Security concerns are the one of the primary reasons why so many email clients died out mid to late 2000’s when every red team success story was “found XSS in email client pwned admin”.
No body is detracting anything from anyone but there is no way I’m trusting an application that can take contol of a large portion of my life without assurances.
If your email address gets compromised it’s game over for most people every service you’ve registered with is up for grabs which is also the reason why I don’t recommend anyone to use personal domains for email unless they are willing to pay for it till death do them part.
As time and time again after buying a domain that was used by someone else and setting up a catch all email address I got emails from Twitter, GitHub and the likes.
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?
Few webmail "clients" are open source and many native clients like e.g. Outlook are also not open source, yet these are very popular. Unless you use a highly trustworthy email provider, considerations about client programs are kind of moot anyway.
I'd personally be more picky about my mail provider and not use any offerings by Google or Microsoft, for instance, because they are stock market companies with interests that principally conflict with the interests of their users. In contrast to this, trusting individual developers and small companies makes much more sense. You check out their online presence and decide for yourself. I'd only be wary about individual developers who offer closed-source security applications (e.g. encryption) and have no prior history of working and posting in this field. But an email client? To be honest, I haven't even checked the vita of the maker of my preferred client, claws-mail, let alone those of any of the authors of the plugins I'm using.
On modern operating systems you basically have to trust every developer of any application anyway, since many installers require admin rights and even if they don't it wouldn't be hard for a malicious developer to exploit a security hole. Your kitchen timer application can get your email credentials almost as easily as your email client.
Outlook is trustworthy for the most part at least as far as security goes MSFT isn’t fooling around and it’s an enterprise product.
And yes choose your email provider based on your threat model but there is nothing wrong with Google or even MSFT for most people security wise privacy is a different concern but these are different threat models.
An email client won’t prevent my email provider from snooping on me (E2E maybe), and no email provider could prevent my client from snooping on me either.
You're already trusting hundreds of individual developers by running their software on your computer.
There is nothing wrong with running an email client made by an individual developer unless you have a particular reason to distrust that person.
>as far as security goes MSFT isn’t fooling around
They have a proven track-record of security bugs for the past 20 years and longer.
> there is nothing wrong with Google or even MSFT for most people security wise
I wouldn't use them as my main email provider security-wise and trust my current email provider way more than those companies. (Not because I think they are less secure, but because I think they are attacked more often.) But of course your mileage may differ, nothing to object to that.
The threat and trust models are completely different.
It's not just about using a piece of software it's about using a piece of software that can lock or unlock your life because essentially every service you use today is tied to an email address.
>There is nothing wrong with running an email client made by an individual developer unless you have a particular reason to distrust that person.
It's not that i distrust that person but it's that I know how unlikely it is for a single person to be able to validate the security of their product especially when it comes to something as complex as a product with a DOM parser and a layout engine, nor do I think they would be able to maintain it up to date when new attacks and vulnerabilities are discovered even they do use something like electron since electron isn't simplicity safe and plenty of electron based software even fairly well maintained one lags well behind it's update cycle including when security patches are concerned.
>They have a proven track-record of security bugs for the past 20 years and longer.
They also have a proven track record of finding and fixing those bugs.
>I wouldn't use them as my main email provider security-wise and trust my current email provider way more than those companies. (Not because I think they are less secure, but because I think they are attacked more often.) But of course your mileage may differ, nothing to object to that.
There are potentially more secure providers but being attacked more often isn't a really good sole metric threat model unless you can effectively estimate resilience responsiveness and compare it to other options.
I used Hushmail as my primary email (still somewhat do) because it was fairly secure and had integrated PGP, I switched to Proton Mail now.
There's not a lot of attack surface when JavaScript is disabled. If there's a HTML/CSS vulnerability in Chromium, then your email client is the last thing you have to worry about.
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?
Not as many times as you'd think and again that us utterly irrelevant.
It's not how many time you put it in it's into what and then what that thing can do with it.
Not all passwords are equal and for most people their primary email is the domain admin/root credentials for of their life.
And it isn't relevant if I personally audit every application or not I can build a trust model based on my risk appetite and the threat models that are relevant to me and the situation and everyone does it even if they are not aware of it.
I can put my trust in a specific vendor based on their business model, their reputation, the resources they have available and my experience with them and the legal frameworks surrounding the service/product. I can put my trust in the community at large in the case of open source products because while individually neither myself nor most other user validate every line of code and every commit it is possible and the community at large does do that.
Let me ask you this I this wasn't and email client but say a thick client for your online banking would you still ask me the same question? bare in mind that having your email compromised today is considerably more damaging than someone logging into your online banking as it's much easier to sort the latter and there are also considerable mitigating security controls around it.
The software runs completely on your desktop - your email & password is only sent between your computer and your email server. There are quite a few security measures in place that prevents HTML vulnerabilities, both built-in into Electron and others. I'd very much welcome an audit of the code from a respected firm!
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.
No offense but unless it’s a 1st party client email clients are something that is very hard to trust.
This seems an odd position to me.
Online clients are well known to be scanning your emails, necessarily involve giving access and control to third parties, are impossible to use while retaining control of private encryption keys, and so on.
Local clients might have some of those problems. If they're open source then in theory you could audit them and find out, but in practice even that gives a false sense of security because no-one has the resources and willingness to undertake that work every time they install a new version.
Ultimately software security is still all about who you trust, the same as always.
Pretty much everything you said is bullshit, fwiw. Nobody gives a shit about your name drop of firms, nor will not having an audit from any of them impact the target market for this app.
This looks fantastic, I was just thinking about so many of these features being released in gmail. Like the chat bubble. Those things really speed up reading information. Kudos!!
Thank you! Yes I was expecting some comments about Electron, however I don't think it is really deserved. It is possible to build Electron apps that doesn't use >1gb of RAM, and this is what I've also been trying to do, when I've tested it on my old Macbook Air, it consumes around 300mb of RAM
Yes exactly. Also, there are ways to offload some of the background tasks to Rust. If you can do that, your app is gonna be consuming way less memory even with new features. Please consider it!
I mentioned Electron in my comment, and Electron is a deal-breaker for me... but I would much rather encourage the work and effort that is going into this. If the product is successful and profitable, maybe it can be ported to native frameworks a few versions later. And considering the rumours about macOS, probably wise to avoid writing native Mac code just now.
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 Electron app is smart because it will be easy to port to iOS / newOS.
Apple has in the past been quite good at supporting old software even across hardware chip changes. Sometimes requiring only a recompile, sometimes not even that. Whether the Apple of today is the Apple of old, hard to say.
Seems difficult to make development choices today based on rumors, in any event.
I've been getting a few requests to release it for Linux, and as the other commenter here, since it is Electron, it will not be very long before it can be released on Linux (compared to if it were a 100% native app)
Looks very interesting. I personally would appreciate knowing I am entering my email into a waiting list rather than getting access. Also, why does there need to be a waiting list - to help stem the flow of analytics? Honestly curious.
I really want a good, modern email client and I hope this can be it.
The reason for having a waiting list is so that I can release it to a few people at a time. I don't want to release it to everyone at once, because if there is a large or annoying bug I haven't found. If I release it to a few people, let's say 50, only they will experience this possible bug and not everyone at once
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.
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
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.
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.
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.
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?
Are there any examples of Electron apps that don't do that, though? I've never seen one that didn't like to eat at least a few hundred MB, and most of them seem at least somewhat leaky, too.
I'm sure that a client like Mutt would use much less but considering that many emails have embed HTML and would ideally use a modern web view to render correctly, how much overhead is there from from using Electron/chromium if you're going to load all of that anyway?
I couldn't find exact figures for MS Outlook but Office 365 seems to require 1Gb as a minimum.
A quick look at the Gmail tab I have open in Chrome seems to be taking roughly 390Mb so this would seem to be an improvement over that.
As a genuine question, what sort of size would you expect for an optimised native app with the same functionality?
For reference, when settled, Gmail in Firefox uses 200MB or a bit more, while FastMail uses around 10MB.
I’m tempted to make a FastMail Electron app just to demonstrate that Electron/HTML/CSS/JS doesn’t need to mean slow and heavy (it just normally does).
Later: OK, so on Windows a trivial Electron “just load https://www.fastmail.com/login (and then log in)” app uses ~230MB of RAM. Not what I was hoping for, though it doesn’t surprise me a great deal—Chrome is quite happy to use lots of memory. Interestingly, when I reduce it from 3000×2000 to 1600×1200 (device pixels, it’s a 2× display), it goes down to about 160MB after a bit, and minimised to 180MB or 120MB for the two window sizes. Still very snappy despite this memory usage, though, for FastMail is fast.
Actually, that was just from just loading Gmail and letting it idle, a couple of weeks back, not actually using it. A year and a half ago, I recall it being more like 125MB, up towards 150MB as it was used. Gmail hasn’t really changed since then, but the Hangouts widget (which is pretty heavy!) might have, and the browser definitely has (I blame it for most of the increase). I haven’t actually used Gmail since around that time.
For reference, I’m using the explicit/window-objects/top(…) figure from about:memory. This is not an accurate representation of the full footprint, but is close enough.
> Gmail in Firefox uses 200MB or a bit more, while FastMail uses around 10MB.
Yes, but that’s not a fair apples to apples comparison with his 300mb number. Your looking at the memory used for that tab, not the shared memory used by the browser across tabs. Open Firefox with no sites open and check your baseline memory usage. Add that to the numbers above for a direct comparison.
See my update to the comment. Its memory footprint is greater than I expected. I shan’t pursue it any further at present, I was mostly just curious to get an initial feel for it. Taking it (or something like it) to a polished product is something I’d like to do, but I’ve got other, much more important things to do on FastMail and Topicbox, and I don’t think anyone else in the company feels strongly about it, so it’s unlikely to ever actually happen.
One avenue would be to use a different, more light-weight engine; https://github.com/zserge/webview, for example, can use the local platform’s engine, which is likely to be somewhere between a little and a lot more efficient than Electron/Chrome. Running FastMail with the MSHTML renderer via the Rust bindings for that (DPI scaling issues, but meh), it starts at about 60MB but is easy to get over 80MB with some use. Still quite a lot less than Electron/Chrome.
Maybe you can help me understand the outcry over Electron memory usage, especially on HH. I can't remember the last time I ran out of memory on my laptop or desktop unintentionally. Seems to me battery life and jank should be main areas of focus. You can have a 2GB if you cut CPU usage and typing latency.
Just because you "can" use a bunch of memory without issues now doesn't mean you "should" not make any attempts to cut resource usage whenever possible.
Of course you're right. But why does it seem like memory usage takes precedence over battery life and latency? I may be in the minority, but it seems to me a native app's key advantage over Electron is performance/watt and I don't see how reduced memory usage would help.
I've run out of memory a few times this week on my Linux VM at work, and also at home on the beater laptop I use in the living room. Those are both stuck at 4GB of RAM, though.
On my laptop with 16GB, it's certainly been at least a few months since I've done anything that made it hit swap.
I said "unintentionally" as a hedge for corner cases like VMs where you are likely aware of the limits. I probably should have been more clear. I also prefer native apps, which is why I still mostly use Sublime over Code despite the latter's advantages. But it's because of speed and battery life, not memory consumption. If we're going to make a case for native apps, lets at least focus on the biggest pain points, as the proliferation of Electron indicates we're not making an impact.
Battery life's something that I only rarely have to think about. All of my development has always been somewhere with convenient power. It irks me when the CPU's churning along on a process that should be near-idle, though.
> I said "unintentionally" as a hedge for corner cases like VMs where you are likely aware of the limits.
I was aware of the limited memory of the VM, but almost everything I run there is a text-mode application, so it usually doesn't matter. Honestly, I thought that Slack would fit easily in the free memory, but I'm logged into 3 teams, so it ate more than I expected. And it's a spinning rust drive; swapping sucks, and it slows down the host OS at the same time.
It's an avoidable situation; just run Slack under the host's Windows, instead of in the Linux VM. But it remains the case, in my uses, that memory has caused more issues than CPU, and that CPU has caused more issues than battery drain. I don't know why everyone else focuses on memory so much...I perceive my own issues as kind of a corner case.
My Outlook (2016) client is using ~300MB right now while displaying a full HTML spam mail (taking one for the team, guys). I wouldn't say I'm a heavy user, but there's shared calendars and mailboxes, OneNote integration, task list etc.
> considering that many emails have embed HTML and would ideally use a modern web view to render correctly
It might be me, but i prefer them to be rendered incorrectly in a text-only view :-P. I use email since the 90s and so far i do not think i can come up with any case where the HTML in an email was actually useful and not used for fluff (which i do not mind but can do without), branding (which i do not care at all about) or -way way more often- advertisement.
Also almost all HTML mails i've seen come in text-only version too and any useful bits are attachments anyway.
I switched from Thunderbird to Gmail because of that; it was quite bad on my laptop. It often started swapping requiring very long waits or a reboot to get back to work.
My Claws Mail currently uses 56M, multiple IMAP accounts configured, a few thousand mails, just visited all accounts before measuring. I disabled HTML display, though (most HTML is either spam or newsletter fluff in my experience). Claws is GTK2.
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.
>* 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.
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.
> 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.
Programs do a lot more than they used to. Even though they solve similar problems as their predecessors. 300MB is perfectly fine for a modern app when computer team is measured in GB.
>many people won't use them, mostly for the technical reasons
I really don't think that's true outside of the HN echo chamber. Like OP, I am using a Macbook Air which is hardly a supercomputer and vscode runs perfectly fine on it.
There is almost universal hatred of the Slack app in our client relations department, due to performace. All use Mac laptops or Windows desktops, none of them know the term "Electron".
I wonder why people run slack stand-alone. I run it as a pinned tab in my browser and with browser notifications it works great. Very few issues running it this way and performance seems good.
I have Chrome users for browsing, personal email, work email and Slack. I had Slack in a separate Chrome window, in a pinned tab. I noticed that changing to my communications space was slow. By eliminating windows one-by-one, I discovered, the culprit was the Slack pinned tab. I tried the Slack standalone app instead, and that slowness is gone. I can't explain why, but the standalone native app may actually perform better. I think it's worth checking out.
I've gone back and forth between in-browser and stand-alone, but as my number of Slack teams grows, browser tabs get considerably less appealing. (I have five I monitor regularly and four more I don't care much about.)
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)
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.
> 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.
> 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 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.
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).
I didn't say it's impossible (I've also done it), but for something that's not a full-time job/project, it's a lot of extra work that could be avoided by simply using Electron, especially if you are already familiar with web development but don't have any experience with any of the native platforms.
You're right, I missed the OP saying that. But I still disagree: prior experience with a platform is a great reason for using it. Maybe not for a company with lots of resources, like Slack or Microsoft, but definitely for a small team or individual developer. Any time you would have spent learning a new development platform can instead be spent building new features!
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).
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?
> 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.
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) though.
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.
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).
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.
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.
"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).
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.
(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.
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.
> 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.
Note that Qt does not have a pure native mode, it always draws its own controls - it just has a very good imitation of the native controls (especially on Windows).
"Qt isn't that much less bloated than Electron, especially when you start styling it and get dynamic."
Given how many smart people are working to make the browser techs as efficient as possible, and the way that things like QT get "bloated" as soon as they start trying to do what browsers do, I've pretty much arrived at the idea that once you have images and an engine that can reflow text and load fonts and so on, and you want this rather complicated functionality to perform at a reasonable level, you're looking at browser levels of resource consumption no matter what you do.
I mean, if you start working the math on what it looks like to have a bitmap of the screen in memory (which you may not literally have as a single flat plane, but we've got character caches, images, and all sorts of other things that add up to that pretty quickly, if not surpass it entirely very quickly), on a high-resolution display, a bit of extra memory left over from packing those resources, the dynamic scripting language space, the other support modules, various other bits of uncompressed media even if it's just windowed... you've gotten into the hundreds of megabytes pretty easily there. Maybe you could keep this below 100MB with a lot of work, but in a world where a single uncompressed 4K full-color image/framebuffer is running you at least 24 MB (for RGB, 32MB for RGBA), 10-50MB just isn't going to be an option.
I've got an emacs here with a couple dozen source code buffers loaded and it's running at about 60MB resident. That's a mere 1/5th of the Slack usage that everyone is incensed about, and while emacs can do a lot of things, it's still taking a pretty substantial capabilities hit vs. Electron to get that small.
Yes, I know emacs can have a web browser in it and such. And if I use eww to load news.ycombinator.com, emacs resident usage just jumped 15MB for what is, frankly, a terrible rendering. It isn't even rendering my jerf.org terribly well, which in modern terms is basically built by rubbing two sticks together and sending the resulting sparks down the wire. That's what 15MB on top of the already-loaded emacs bought me.
Modern UIs with support for themes, complex interactions, multiple screen and pixel formats, and every language spoken by Homo Sapiens since Gobekli Tepi was built are large and complex. It's not avoidable. That is the problem domain. If you're doing less than that you'll regret it when more and more users start requesting features you don't have or complaining that your product doesn't look right on X or with X language/font/etc. That's my problem with all these ultralight immediate mode UI libs like nuklear. It's like going back to MS-DOS or CP/M and saying "wow that's simple and fast!" Yeah but it lacks a lot of stuff you will need.
The web's rendering layer isn't perfect but it's better than many alternatives and isn't going anywhere, so putting a lot of effort into making it more efficient and robust is very logical.
I agree with that to some extend, but the fact is, except for some very specific cases like vscode, I not only don't need "styling and dynamic", but I don't want it to be.
My OS has UI semantics. I want most of the apps to work the same everywhere. Your app is not special. Stop reinventing a "visual identity". Give me congruency and features.
"I agree with that to some extend, but the fact is, except for some very specific cases like vscode, I not only don't need "styling and dynamic", but I don't want it to be."
Actually, I'm not referring to things like colors or fonts. What I'm referring to is the fact that had the web-browser style layout algorithms not been already invented by web browsers, they would have been invented by the inexorable progression of the pressures and features in desktop toolkits by now. If the people using web toolkits want to be able to lay things out without having to laboriously bundle things into horizontal and vertical scaling groups and specify flexing ratios and all the other crappy layout mechanisms used in desktop toolkits since they first came out, but to use a simple (to use, not implement), powerful HTML-esque layout mechanism, you're going to pay for that on the resource consumption.
And the people writing these programs want that, and will use toolkits that offer that, and if that's bothering you, well, spend some time writing this stuff yourself and you'll stop being bothered, you'll happily spend 100MB of the user's RAM to make the pain end. As neat as it is in some ways, and as much as it has been made to sing and dance over the last 50 years, that style of layout really stinks to use.
> you'll happily spend 100MB of the user's RAM to make the pain end.
And users, at least the savvy ones who hang out here, are saying that this RAM isn't ours to spend. Is there no way that we could spend more resources on our dev machines instead, at build time, to take a piece of code that was pleasant to write and convert it into something that's frugal with resources on the user's machine? C++ and Rust promise abstractions with zero runtime cost compared to the best that you could hand-code. I wonder if the same can be applied to multi-platform GUI toolkits, perhaps through compile-time metaprogramming.
Nr. 1 implies that they (or their users) don't care about efficiency. It doesn't tell us anything about native cross platform development being expensive.
> Writing a UI multiple times is monumentally expensive.
I'm confused by this statement. The point of Qt is that you write the UI once. Your controller back-end might have platform-related pragmas, but not the UI.
> If Slack with its billion dollars doesn't do it what does that say?
When you give programmers freedom to choose what makes life easy for them, end-user experience suffers?
I really think all dev companies should have a lab of 'consumer-grade' laptops with 4GB of RAM and 20Mbit/sec networking. And QC shouldn't let anything ship until it runs adequately on those. Particularly for a company like Slack that is targetting corporate users, the bulk of whom aren't software architects with 2017 MBPs ( who make the choice ) but small-cogs with a five-year-old Dell.
You're right about my first statement. Was a bit of a thinko in that it's talking more about the conditions that lead people to choose Electron in general than responding to Qt specifically.
As others have pointed out in this thread: Qt is not really that much lighter than the web. It draws its own controls and even has css-like styling. I remember Qt apps being relatively slow on small machines... maybe not quite as slow as Electron but the latter could be tuned and improved and made competitive IMHO.
Your main point is valid, but you shouldn't be focusing your anger at Electron or at programmers for choosing it. You should be focusing your anger at desktop vendors for refusing to offer a better way to develop cross-platform apps in favor of an ultimately foot-blasting quest for platform lock-in. By refusing to play with each other desktop vendors have doomed all their platforms to obsolescence and abandonment.
> Trouble is everyone I show [libui] to says "ugly" as their first comment. Everyone wants styled apps today with polished UIs
I don't think I'll ever understand this. What about consistency between apps? Sticking to the OS's native widgets and style will get you that. Do people really like it when each app has its own look?
Of course, I'm no judge of aesthetics. Being visually impaired, my idea of a perfect UI is something with high contrast and large text.
> Every recent new app I can remember installing in the last year is Electron. Native UI is dead.
In terms of Electron, I have installed: Slack and VS Code (although I later uninstalled VS Code, and will have to put Slack on a machine with more memory than the VM it's in now).
I can usually spare the memory, at least on my non-crap machines, but I haven't really had the need to.
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.
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.
I'm an extreme niche, so I recognize that an email client that intends to be used by the general population would need it, but why would I even want to see HTML emails? Those are 105% of the time just marketing bullshit. Emails are either in plaintext with friends/families/clients/people or have a single link that I can copy/paste to verify an account on a website. As it stands, I never download images in my emails anyway. A few sites have tried serving the account verification code as an image and I just won't validate my account if that's the case.
Designed emails using HTML are used by marketing teams - not by people. I don't care to read emails from marketing teams "as intended to be viewed". Show me the email and let me read an email that's just a bunch of plaintext markup.
Not sure if there is a common agreement about terminology, but my distinction is
- web app: loads from a server and connects to a backend to perform its activities. Business logic is on the server. If at all, very limited offline capabilities
- desktop app: is installed on the local machine, doesn't need any connection to a backend to work, works offline.
I don't mind at all which technology the dev used to implement. Even nerdy metrics like memory and CPU consumption cannot be predicted from the used technology. So why should I care?
This is a simple definition but I think it lacks a couple important things:
1. It doesn't match the words. If that defines a "web app" then where does the web come in? I would think part of being a web app is that you can access it via the web and don't have to install it on your device.
2. Usefulness of the distinction to users. The specific nature of the bundled runtime for the code doesn't matter to anybody. It strikes me as pedantic to insist that because under the hood a thing is running in a browser we should call it a "web app".
I think the most practical distinction is that web apps have a URL as the entrypoint. If you want to use it, you can visit the URL from any browser that supports the app. Web app requires a URL and a compatible browser.
If instead you install the thing on your computer and run it from there, it's not a web app. It's a native app. No URL and it doesn't care what other browser you have installed because it comes with everything it needs. It's independent.
How and why would users be expected to understand anything else?
You didn't really have to. I guess I made my point badly. The fact that a "web browser" is somewhere in the chain of what is reading an application does not mean that the application itself has anything to do with "the web", so I think calling it a web app is confusing and pointless. And again, seems like a technicality.
> As for the second issue: users care because performance is worse, accessibility is by and large non-existent and platform features don’t work.
I agree with this in general. It doesn't mean it helps the user to call it a web app. Maybe we need a third, generic term for electron apps and others like them. A name that refers to the potential differences in performance, accessibility, and performance that users may notice?
Web app doesn't work for what you are talking about as far as I can tell. Of course this is an industry where terms and definitions change a lot.
> The fact that a "web browser" is somewhere in the chain of what is reading an application does not mean that the application itself has anything to do with "the web", so I think calling it a web app is confusing and pointless.
In a discussion of 'native apps vs web apps' it absolutely makes a difference that Electron apps are rendered by a browser's web view - they're basically a web page rendered by a local source not remote, but without any of the sandboxing that proper browsers employ for security.
> Maybe we need a third, generic term for electron apps and others like them. A name that refers to the potential differences in performance, accessibility, and performance that users may notice?
> In a discussion of 'native apps vs web apps' it absolutely makes a difference that Electron apps are rendered by a browser's web view - they're basically a web page rendered by a local source not remote, but without any of the sandboxing that proper browsers employ for security.
Those are also reasons not to call them web apps though: web apps run in your browser of choice (ish) with all of the associated security and accessibility defaults, plus your extensions and whatnot. They are apps on the web.
> - web app: loads from a server and connects to a backend to perform its activities. Business logic is on the server. If at all, very limited offline capabilities
You're confusing web apps and client/server apps. Web apps are generally thought of as apps written using web technologies. This means that a web app may not even interact with a back-end server, or a native app may exclusively interact with a back-end server.
I think this is not correct. According to https://en.wikipedia.org/wiki/Web_application, Web applications are applications running in a Web browser. The term was introduced to distinguish Web _apps_ from Web _pages_, not to distinguish _Web_ apps from _native_ apps.
> Web applications are applications running in a Web browser
And Electron embeds an instance of Chromium, to provide a webview for the 'application' interface.
How is that not a web app? It's written in HTML, CSS and JS, it runs inside a browser.
Just because the user can't choose the browser doesn't mean shit. Users couldn't choose the browser to run a lot of Microsoft-stack Web Apps in the early 2000's either, because they only worked in MSIE.
Analogy: when people are deadly allergic to peanuts, they make very very sure the food they buy doesn't contain peanuts before buying it. If they can't get an answer, they go buy food from someone who can answer their question.
The OP clearly means not hosted remotely / not requiring a server to set up, but somehow everyone thinks this is a great opportunity to mention that since it uses the same underlying front-end technology, there's no distinction, and it's actually worse.
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.
There is a lot of convenience in being able to log into any computer and access your mail. Plus Gmail search beats the search in native clients most of the time.
This is often heard but I don't think there is legal justification for it. It is pretty clear that it is your data, hosted on someone else's server that you pay by looking at ads and allowing them to read your mail. It is your mail nevertheless.
Additionally, if we are really picky, only mail written by you is your mail. All mail received is normally copyrighted by someone else and belongs to the sender or/and his/her company. Very strictly speaking in some countries you are not legally allowed to forward someone else's mail if it bears any artistic value.
Yes I know, it is off topic. But it was fun, thanks for the spark!
I agree regarding the convenience, but I'm not impressed at all by the Gmail search function. It doesn't even have any fuzzy matching – which seems crazy given what company we're talking about.
It works for almost everything I try to find. It might take a few tries, but I can usually find the mail I was looking for.
Usually when I change jobs I have had another non Gmail account but I have never found the search as good.
I have an outlook web client at work and that doesn't find things. Maybe its me being dumb and remembering different phrases from what is actually stored, but I almost always manage to finds what i am looking for in Gmail. I can't say the same with other clients.
Its just a pity that I have to give up my privacy to Google for it.
Thank you! Version 0.9 is out right now, and I have released it to a few people in the waiting list, I'm fixing bugs and iterating, so expect to get a download link pretty soon
> "Ask HN: What requirements should I consider before writing a new email client?"
Oh boy. I've written a mail client [1] (two actually) and I've found that people have widely conflicting requirements.
Me? I wanted to replace mutt with something that was similarly console-based, and would use the same Maildir hierarchies.
Other people demand GUI access, sometimes with IMAP, sometimes with POP3, and sometimes (very rarely) with just local Maildirs.
If I were to begin again I'd probably abandon Maildirs, and instead just work via notmuch, or some other indexed-store. That would allow "virtual folders", and other neat things.
I don't think I've got the patience to start again though, as my current client is already the second version.
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.
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.
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.
Not true. Look at the various Skype clients, e.g. for Linux. Memory usage ballooned after they wrote their Electron based client. It uses 4 to 5 times the amount of memory of the old Qt based client and idle CPU usage is through the roof, too. And it can't even handle long conversations smoothly.
Absolutely equal no, or else it would be the same app. But that's contrived.
My point is that given two apps that both have the features a user considers "must have", few, if any, would pick the Electron one over the native, precisely because of the extra burden in cpu/memory/speed of Electron.
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.
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.
> 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.
Is it possible that VS Code (for example) exists (in its feature specific incarnation ) only because Electron is a cost cutter in terms of portable development?
In other terms: Maybe the portable native full featured VS Code is the middle of the cheap-fast-good venn diagram.
>Is it possible that VS Code (for example) exists (in its feature specific incarnation ) only because Electron is a cost cutter in terms of portable development?
It could -- though I doubt it.
But I was concerned with a more limited question: if there was a good VS Code alternative that's native, would many still prefer an Electron version?
> But I was concerned with a more limited question: if there was a good VS Code alternative that's native, would many still prefer an Electron version?
I understood what you meant. I respect you disagreeing with my premise, but in the scenario where that premise is true, your question is not applicable.
Scenario: Would anyone choose MDF boards at IKEA if they could choose plywood or natural wood, or assemble their own furniture if given the choice (at the same price)? Barring a few applications, probably not. But IKEA wouldn't be IKEA if they were just another producer of wood furniture, meaning they got to market and stayed there because of the shortcuts and limitations they could justify when reaching a price.
Same thing here (IMHO). VS Code could have some cross-platform code and some platform specific code, but the cost would be higher and the output velocity would likely be lower. Assuming that is true, your question is misleading, albeit not on purpose.
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.
>but it was always my impression that much of the power either editor has comes from 3rd party extensions rather than the editor core
A lot of it, yes. But VSCode also invests a lot in core functionality (in what in other platforms would be plugins). The Git integration is one such example -- or the ability to debug Chrome in it.
>That's because, as the parent said, there are no good (e.g. equivalent) native alternatives.
But that's not true. I use Sublime Edit and have happily used BBEdit and TextMate. Emacs is fine for many people, and I still use vim for fast edits in terminal mode all the time. There are plenty of other great native editors for just about all platforms.
An electron-apps can use and call native code. I see Rust getting some attraction being bundled with electron apps. This should be a thing every electron app maker out there. Rust or otherwise.
Please stop censoring views that don't align with the hackernews majority. Just because these complaints are so common that HN hipsters now like to hate on them does not invalidate them.
Well, I am curious. Seems so hard to get an email client right. I would not mind paying (GPG integration is a must).
If you don't go the mutt/alpine route, there aren't much options. Basically Thunderbird and Evolution. Never really got Clawsemail and iscribe to work with my IMAP server settings.
To make things worse, people do understand email less and less. Often, all ports except 80 and 443 are blocked and you can't even use IMAP/SMTP. And if you complain they tell you "What are you talking about? Gmail works...."
Actually, there is another feature from Evolution you may want to offer for Gmail accounts.
Evolution somehow stores a cookie or can log in via webbrowser or something like that. Evolution will never get you logged out of your Gmail account (yes, I have one that I use for some things). I travel a lot and Thunderbird will always get blocked by Gmail (Please log-in via Webbrowser to confirm your identity).
I think GPG might be a killer feature. Well, for some people, I'm not totally sure how many people care.
I care... but the convenience of a webmail client accessible on any device is just so great. But there's no good way to really have secure end-to-end encryption in a webmail client. That's about the only thing that would make me seriously consider a desktop client.
Really, I'm not sure what the audience size is for email you can't see on your phone though.
607 comments
[ 3.0 ms ] story [ 349 ms ] threadEdit: I realized this was worded very badly. I’m saying I wish this was written with a cross platform core, and native, platform specific UIs for each respective platform. For example, MS Office is written this way.
I would've said the same thing with joy!
From the title I was immediately hoping that this was not yet another bloated electron thing.
Electron and similar technologies are in my opinion not quite at the point where they can compete with the best that native platforms can offer. I'm sure that will change one day, but we're not there yet.
GTK integration on windows and mac is also less than perfect - I've been using geany on multiple platforms a lot recently and it's a great tool, but there's small annoyances like that the "swipe to scroll" speed varies massively between it and Notepad++.
Electron apps' installation process is just madness. It breaks every convention. You can't even choose the install path FFS!
I think of Electron apps as BonziBuddy for today's hipsters.
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.
As for Microsoft, I think that have been invaded by JS devs on their way to re-invent and refresh the company's culture.
Regarding the OP, yes he should be appreciated by taking the effort of spending two years doing this software, it is just a pity that it yet another Electron app.
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.
I get paid money for the software I develop too, after all.
Postbox currently only charges $40 for a lifetime free-upgrades license. In my case, they are definitely leaving money on the table, I would've paid a lot more.
In any case Postbox is not available on Linux, but I'd still like to know.
But now, I use the keyboard driven Tagging & Quick Move features [1] a lot. They work a bit like Alfred [2]. To file a message in my Filtered folder, I type "v fil Enter" and by the time I've typed v, an Alfred-like window pops up that autocompletes the full folder names as I type - so by the time I get to 'fil', it's autocompleted to the right one and I can hit enter. Standard keyboard shortcuts too like j to junk, a to archive, etc. I'm sure Thunderbird also has these via extensions, but I like having it in the core product supported by the core developers.
There's a word count warning feature that I use a lot too, because I tend to type a lot. The word count turns red when I go over my suggested self-imposed limit, or you can set a timer for when you've been composing one email for too long.
EDIT: I saw you asked elsewhere about editing the From field, Postbox has a pulldown menu on each message you compose where you can choose from a list of profiles / aliases you create. Each can even have their own SMTP server details & default signatures & are separate from inbox accounts. You can switch signatures on individual messages too.
[1] https://www.postbox-inc.com/features
[2] https://www.alfredapp.com/
Alfred looks interesting. Other than the workflows, almost everything it does is already integrated into KDE. However it looks easy to use and I will definitely check it out if I move to one of the company Macbooks. Thank you!
Would be nice if a bigger company sponsors such a project, then a greater audience will use it and the Developer could concentrate on developing and not on selling.
I wish this was the default assumption these days.
The biggest difference is that it's way easier to see where you're data is being sent in a browser, since it has built in tools. It's very hard to monitor native app traffic that is sent over SSL.
You, Your mail (provider) server.
Vs
You, the server hosting the web app, your mail (provider) server.
Unless you run uMatrix or uBlock Origin (same code in both as far as this feature is concerned), of course.
Possibly only to render the HTML in some emails (and why not, then, just open them in the user's existing browser window,) but otherwise, there seems (to me) to be little about email that requires the overhead of a browser engine and associated Node dependencies and whatnot.
A native app could be smaller, faster, and use less RAM.
What would be the reason to cram the mail client into the browser instead of making it a first-class application on the same level?
Which frameworks/libraries and languages did you use?
What were the main challenges you came across?
(By the way, typo: "accessable" should be "accessible")
[1]: https://addons.mozilla.org/en-US/thunderbird/addon/gmail-con...
It's the ultimate email management tool. And I hope you can add it fast.
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 you also inherit all the possible vulnerabilities that come with having a DOM parser and a layout engine and even modem browsers still get both wrong.
And using something like Electron or even Chromium won’t implicitly save you because the way you implement them matters a lot and now you are tied with their update cycle which might break functionality forcing you to manually backport security fixes which is hard to accomplish.
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.
I might try this client with a throwaway email account, but never with something important.
What does it change if you have an c53 audit of Version 1.0.0 and 1.0.1 has malicious code?
I'm not going to make claims that a developer would maliciously embed code into their own product but I do care about the quality of their code and their security practices at large (specifically how secure is their code promotion and binary distribution supply chain).
> Privacy & Security
> Total privacy - we do not have access to your email account, Ivelope only sends your email data and password between your computer and your email server.
If you're really paranoid but still want to try it out, you could run something like Little Snitch to verify the connections the program makes.
I certainly like the idea of new email clients, especially those that integrate with Exchange calender (a weak point for Thunderbird even with extensions). But in my view, building a fast, robust and feature rich email client would take about an effort of 10-30 person years or even more, depending on the feature set. This one seems to stand at a mere two person years, and so my expectations would be quite low (though it's still in beta and states upfront some of the important features it's missing).
P.S.: I'm a supporter of Thunderbird and donate money to the project. https://donate.mozilla.org/en-US/thunderbird/
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'.)
[1]: https://github.com/rc0/mairix/
[2]: https://github.com/rc0/mairix/network
This is a person who's worked 2 years on a project, in a neglected space where companies don't go because they can't make money.
He deserves praise for taking the time, creating something that's different, and thinking through the idea. Well done!
IMHO this is justified since people often overlook how critical an attack vector this would be.
Imagine if a state-sponsored "hobbyist" posted a pet project like the OP to Reddit and started harvesting keys/password reset capabilities for huge amounts of users.
Hell, people flocked to use unroll.me and then it turned out they were (predictably) scraping your entire inbox and selling the data to advertisers.
I don't believe that worrying somebody's skepticism might hurt feelings is a legitimate reason to downvote (remember, downvotes aren't about whether you agree with somebody; it's about whether they add constructively to discussion).
Aside: Great work OP. Seems like an incredibly hard sector to make traction with though, so best of luck.
Regardless, I'm really glad there are more people trying to fix the problem of email.
No body is detracting anything from anyone but there is no way I’m trusting an application that can take contol of a large portion of my life without assurances.
If your email address gets compromised it’s game over for most people every service you’ve registered with is up for grabs which is also the reason why I don’t recommend anyone to use personal domains for email unless they are willing to pay for it till death do them part.
As time and time again after buying a domain that was used by someone else and setting up a catch all email address I got emails from Twitter, GitHub and the likes.
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.
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...
I'd personally be more picky about my mail provider and not use any offerings by Google or Microsoft, for instance, because they are stock market companies with interests that principally conflict with the interests of their users. In contrast to this, trusting individual developers and small companies makes much more sense. You check out their online presence and decide for yourself. I'd only be wary about individual developers who offer closed-source security applications (e.g. encryption) and have no prior history of working and posting in this field. But an email client? To be honest, I haven't even checked the vita of the maker of my preferred client, claws-mail, let alone those of any of the authors of the plugins I'm using.
On modern operating systems you basically have to trust every developer of any application anyway, since many installers require admin rights and even if they don't it wouldn't be hard for a malicious developer to exploit a security hole. Your kitchen timer application can get your email credentials almost as easily as your email client.
And yes choose your email provider based on your threat model but there is nothing wrong with Google or even MSFT for most people security wise privacy is a different concern but these are different threat models.
An email client won’t prevent my email provider from snooping on me (E2E maybe), and no email provider could prevent my client from snooping on me either.
There is nothing wrong with running an email client made by an individual developer unless you have a particular reason to distrust that person.
>as far as security goes MSFT isn’t fooling around
They have a proven track-record of security bugs for the past 20 years and longer.
> there is nothing wrong with Google or even MSFT for most people security wise
I wouldn't use them as my main email provider security-wise and trust my current email provider way more than those companies. (Not because I think they are less secure, but because I think they are attacked more often.) But of course your mileage may differ, nothing to object to that.
>There is nothing wrong with running an email client made by an individual developer unless you have a particular reason to distrust that person.
It's not that i distrust that person but it's that I know how unlikely it is for a single person to be able to validate the security of their product especially when it comes to something as complex as a product with a DOM parser and a layout engine, nor do I think they would be able to maintain it up to date when new attacks and vulnerabilities are discovered even they do use something like electron since electron isn't simplicity safe and plenty of electron based software even fairly well maintained one lags well behind it's update cycle including when security patches are concerned.
>They have a proven track-record of security bugs for the past 20 years and longer. They also have a proven track record of finding and fixing those bugs.
>I wouldn't use them as my main email provider security-wise and trust my current email provider way more than those companies. (Not because I think they are less secure, but because I think they are attacked more often.) But of course your mileage may differ, nothing to object to that.
There are potentially more secure providers but being attacked more often isn't a really good sole metric threat model unless you can effectively estimate resilience responsiveness and compare it to other options.
I used Hushmail as my primary email (still somewhat do) because it was fairly secure and had integrated PGP, I switched to Proton Mail now.
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?
It's not how many time you put it in it's into what and then what that thing can do with it.
Not all passwords are equal and for most people their primary email is the domain admin/root credentials for of their life.
And it isn't relevant if I personally audit every application or not I can build a trust model based on my risk appetite and the threat models that are relevant to me and the situation and everyone does it even if they are not aware of it.
I can put my trust in a specific vendor based on their business model, their reputation, the resources they have available and my experience with them and the legal frameworks surrounding the service/product. I can put my trust in the community at large in the case of open source products because while individually neither myself nor most other user validate every line of code and every commit it is possible and the community at large does do that.
Let me ask you this I this wasn't and email client but say a thick client for your online banking would you still ask me the same question? bare in mind that having your email compromised today is considerably more damaging than someone logging into your online banking as it's much easier to sort the latter and there are also considerable mitigating security controls around it.
This seems an odd position to me.
Online clients are well known to be scanning your emails, necessarily involve giving access and control to third parties, are impossible to use while retaining control of private encryption keys, and so on.
Local clients might have some of those problems. If they're open source then in theory you could audit them and find out, but in practice even that gives a false sense of security because no-one has the resources and willingness to undertake that work every time they install a new version.
Ultimately software security is still all about who you trust, the same as always.
Btw where are the electron haters?!
Hi! I'm here! ;)
I mentioned Electron in my comment, and Electron is a deal-breaker for me... but I would much rather encourage the work and effort that is going into this. If the product is successful and profitable, maybe it can be ported to native frameworks a few versions later. And considering the rumours about macOS, probably wise to avoid writing native Mac code just now.
What rumors?
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 Electron app is smart because it will be easy to port to iOS / newOS.
[1] https://www.bloomberg.com/news/articles/2018-04-02/apple-is-...
[2] https://www.bloomberg.com/news/articles/2017-12-20/apple-is-...
[3] https://mjtsai.com/blog/2018/05/01/scuttlebutt-regarding-app...
One thing I fear is that keyboard shortcuts, particular the F-keys, will become a thing of the past.
Seems difficult to make development choices today based on rumors, in any event.
I really want a good, modern email client and I hope this can be it.
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!
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
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.
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.
I couldn't find exact figures for MS Outlook but Office 365 seems to require 1Gb as a minimum.
A quick look at the Gmail tab I have open in Chrome seems to be taking roughly 390Mb so this would seem to be an improvement over that.
As a genuine question, what sort of size would you expect for an optimised native app with the same functionality?
I’m tempted to make a FastMail Electron app just to demonstrate that Electron/HTML/CSS/JS doesn’t need to mean slow and heavy (it just normally does).
Later: OK, so on Windows a trivial Electron “just load https://www.fastmail.com/login (and then log in)” app uses ~230MB of RAM. Not what I was hoping for, though it doesn’t surprise me a great deal—Chrome is quite happy to use lots of memory. Interestingly, when I reduce it from 3000×2000 to 1600×1200 (device pixels, it’s a 2× display), it goes down to about 160MB after a bit, and minimised to 180MB or 120MB for the two window sizes. Still very snappy despite this memory usage, though, for FastMail is fast.
For reference, I’m using the explicit/window-objects/top(…) figure from about:memory. This is not an accurate representation of the full footprint, but is close enough.
Yes, but that’s not a fair apples to apples comparison with his 300mb number. Your looking at the memory used for that tab, not the shared memory used by the browser across tabs. Open Firefox with no sites open and check your baseline memory usage. Add that to the numbers above for a direct comparison.
I’m tempted to make a FastMail Electron app just to demonstrate that Electron/HTML/CSS/JS doesn’t need to mean slow and heavy (it just normally does).
One avenue would be to use a different, more light-weight engine; https://github.com/zserge/webview, for example, can use the local platform’s engine, which is likely to be somewhere between a little and a lot more efficient than Electron/Chrome. Running FastMail with the MSHTML renderer via the Rust bindings for that (DPI scaling issues, but meh), it starts at about 60MB but is easy to get over 80MB with some use. Still quite a lot less than Electron/Chrome.
On my laptop with 16GB, it's certainly been at least a few months since I've done anything that made it hit swap.
> I said "unintentionally" as a hedge for corner cases like VMs where you are likely aware of the limits.
I was aware of the limited memory of the VM, but almost everything I run there is a text-mode application, so it usually doesn't matter. Honestly, I thought that Slack would fit easily in the free memory, but I'm logged into 3 teams, so it ate more than I expected. And it's a spinning rust drive; swapping sucks, and it slows down the host OS at the same time.
It's an avoidable situation; just run Slack under the host's Windows, instead of in the Linux VM. But it remains the case, in my uses, that memory has caused more issues than CPU, and that CPU has caused more issues than battery drain. I don't know why everyone else focuses on memory so much...I perceive my own issues as kind of a corner case.
It might be me, but i prefer them to be rendered incorrectly in a text-only view :-P. I use email since the 90s and so far i do not think i can come up with any case where the HTML in an email was actually useful and not used for fluff (which i do not mind but can do without), branding (which i do not care at all about) or -way way more often- advertisement.
Also almost all HTML mails i've seen come in text-only version too and any useful bits are attachments anyway.
https://en.wikipedia.org/wiki/Electron_(software_framework)
https://en.wikipedia.org/wiki/Chromium_(web_browser)
Great work by the way!
What is the reason you do not store in a standard format?
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.
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?
When I use mutt I doubt it goes over 20mb.
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.
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.
How would you respond to someone saying "I raise small mammals, well small given that they are elephants"?
In absolute terms it may be big. But for an electron app it’s probably not too bad.
"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."
Why do we have to make this complicated? The creator is using Electron, and within that given framework putting focus on RAM optimization. Moving on.
Emails have become much more than that. They can contain almost everything a webpage can.
Most browsers use a ton more ram than 300 MB.
I really don't think that's true outside of the HN echo chamber. Like OP, I am using a Macbook Air which is hardly a supercomputer and vscode runs perfectly fine on it.
If you mean this, it's written in Swift https://macos.telegram.org/
What OS are you using Telegram in?
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)
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.
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.
I feel bad but you have already lost me there :/
Not in terms of resources (CPU/RAM). It's way better than Electron.
And I don't believe that only having experience in web development is a good enough excuse for shoehorning web dev things everywhere else.
Before that I used mutt - also very little.
Native Emacs in a GUI can also show inline images (but not when running in a terminal, obviously).
[0]: https://senglehardt.com/papers/pets18_email_tracking.pdf
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.
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.
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.)
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.
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.
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).
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.
(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
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.
Note that Qt does not have a pure native mode, it always draws its own controls - it just has a very good imitation of the native controls (especially on Windows).
Given how many smart people are working to make the browser techs as efficient as possible, and the way that things like QT get "bloated" as soon as they start trying to do what browsers do, I've pretty much arrived at the idea that once you have images and an engine that can reflow text and load fonts and so on, and you want this rather complicated functionality to perform at a reasonable level, you're looking at browser levels of resource consumption no matter what you do.
I mean, if you start working the math on what it looks like to have a bitmap of the screen in memory (which you may not literally have as a single flat plane, but we've got character caches, images, and all sorts of other things that add up to that pretty quickly, if not surpass it entirely very quickly), on a high-resolution display, a bit of extra memory left over from packing those resources, the dynamic scripting language space, the other support modules, various other bits of uncompressed media even if it's just windowed... you've gotten into the hundreds of megabytes pretty easily there. Maybe you could keep this below 100MB with a lot of work, but in a world where a single uncompressed 4K full-color image/framebuffer is running you at least 24 MB (for RGB, 32MB for RGBA), 10-50MB just isn't going to be an option.
I've got an emacs here with a couple dozen source code buffers loaded and it's running at about 60MB resident. That's a mere 1/5th of the Slack usage that everyone is incensed about, and while emacs can do a lot of things, it's still taking a pretty substantial capabilities hit vs. Electron to get that small.
Yes, I know emacs can have a web browser in it and such. And if I use eww to load news.ycombinator.com, emacs resident usage just jumped 15MB for what is, frankly, a terrible rendering. It isn't even rendering my jerf.org terribly well, which in modern terms is basically built by rubbing two sticks together and sending the resulting sparks down the wire. That's what 15MB on top of the already-loaded emacs bought me.
Modern UIs with support for themes, complex interactions, multiple screen and pixel formats, and every language spoken by Homo Sapiens since Gobekli Tepi was built are large and complex. It's not avoidable. That is the problem domain. If you're doing less than that you'll regret it when more and more users start requesting features you don't have or complaining that your product doesn't look right on X or with X language/font/etc. That's my problem with all these ultralight immediate mode UI libs like nuklear. It's like going back to MS-DOS or CP/M and saying "wow that's simple and fast!" Yeah but it lacks a lot of stuff you will need.
The web's rendering layer isn't perfect but it's better than many alternatives and isn't going anywhere, so putting a lot of effort into making it more efficient and robust is very logical.
And don't forget accessibility. That's the part that makes me want to scream whenever I see a new lightweight UI toolkit on HN.
My OS has UI semantics. I want most of the apps to work the same everywhere. Your app is not special. Stop reinventing a "visual identity". Give me congruency and features.
Actually, I'm not referring to things like colors or fonts. What I'm referring to is the fact that had the web-browser style layout algorithms not been already invented by web browsers, they would have been invented by the inexorable progression of the pressures and features in desktop toolkits by now. If the people using web toolkits want to be able to lay things out without having to laboriously bundle things into horizontal and vertical scaling groups and specify flexing ratios and all the other crappy layout mechanisms used in desktop toolkits since they first came out, but to use a simple (to use, not implement), powerful HTML-esque layout mechanism, you're going to pay for that on the resource consumption.
And the people writing these programs want that, and will use toolkits that offer that, and if that's bothering you, well, spend some time writing this stuff yourself and you'll stop being bothered, you'll happily spend 100MB of the user's RAM to make the pain end. As neat as it is in some ways, and as much as it has been made to sing and dance over the last 50 years, that style of layout really stinks to use.
And users, at least the savvy ones who hang out here, are saying that this RAM isn't ours to spend. Is there no way that we could spend more resources on our dev machines instead, at build time, to take a piece of code that was pleasant to write and convert it into something that's frugal with resources on the user's machine? C++ and Rust promise abstractions with zero runtime cost compared to the best that you could hand-code. I wonder if the same can be applied to multi-platform GUI toolkits, perhaps through compile-time metaprogramming.
I'm confused by this statement. The point of Qt is that you write the UI once. Your controller back-end might have platform-related pragmas, but not the UI.
> If Slack with its billion dollars doesn't do it what does that say?
When you give programmers freedom to choose what makes life easy for them, end-user experience suffers?
I really think all dev companies should have a lab of 'consumer-grade' laptops with 4GB of RAM and 20Mbit/sec networking. And QC shouldn't let anything ship until it runs adequately on those. Particularly for a company like Slack that is targetting corporate users, the bulk of whom aren't software architects with 2017 MBPs ( who make the choice ) but small-cogs with a five-year-old Dell.
As others have pointed out in this thread: Qt is not really that much lighter than the web. It draws its own controls and even has css-like styling. I remember Qt apps being relatively slow on small machines... maybe not quite as slow as Electron but the latter could be tuned and improved and made competitive IMHO.
Your main point is valid, but you shouldn't be focusing your anger at Electron or at programmers for choosing it. You should be focusing your anger at desktop vendors for refusing to offer a better way to develop cross-platform apps in favor of an ultimately foot-blasting quest for platform lock-in. By refusing to play with each other desktop vendors have doomed all their platforms to obsolescence and abandonment.
I don't think I'll ever understand this. What about consistency between apps? Sticking to the OS's native widgets and style will get you that. Do people really like it when each app has its own look?
Of course, I'm no judge of aesthetics. Being visually impaired, my idea of a perfect UI is something with high contrast and large text.
In terms of Electron, I have installed: Slack and VS Code (although I later uninstalled VS Code, and will have to put Slack on a machine with more memory than the VM it's in now).
I can usually spare the memory, at least on my non-crap machines, but I haven't really had the need to.
You say that like HTML emails don't exist. If the client has to embed a web view anyway...
http://stromberg.dnsalias.org/~strombrg/mutt-html.html
Designed emails using HTML are used by marketing teams - not by people. I don't care to read emails from marketing teams "as intended to be viewed". Show me the email and let me read an email that's just a bunch of plaintext markup.
Guess I'm weird too.
- web app: loads from a server and connects to a backend to perform its activities. Business logic is on the server. If at all, very limited offline capabilities
- desktop app: is installed on the local machine, doesn't need any connection to a backend to work, works offline.
I don't mind at all which technology the dev used to implement. Even nerdy metrics like memory and CPU consumption cannot be predicted from the used technology. So why should I care?
1. It doesn't match the words. If that defines a "web app" then where does the web come in? I would think part of being a web app is that you can access it via the web and don't have to install it on your device.
2. Usefulness of the distinction to users. The specific nature of the bundled runtime for the code doesn't matter to anybody. It strikes me as pedantic to insist that because under the hood a thing is running in a browser we should call it a "web app".
I think the most practical distinction is that web apps have a URL as the entrypoint. If you want to use it, you can visit the URL from any browser that supports the app. Web app requires a URL and a compatible browser.
If instead you install the thing on your computer and run it from there, it's not a web app. It's a native app. No URL and it doesn't care what other browser you have installed because it comes with everything it needs. It's independent.
How and why would users be expected to understand anything else?
As for the second issue: users care because performance is worse, accessibility is by and large non-existent and platform features don’t work.
For example: macOS has tabbed windows at the core - any document based app gets it automatically.
How does that work out for electron apps?
You didn't really have to. I guess I made my point badly. The fact that a "web browser" is somewhere in the chain of what is reading an application does not mean that the application itself has anything to do with "the web", so I think calling it a web app is confusing and pointless. And again, seems like a technicality.
> As for the second issue: users care because performance is worse, accessibility is by and large non-existent and platform features don’t work.
I agree with this in general. It doesn't mean it helps the user to call it a web app. Maybe we need a third, generic term for electron apps and others like them. A name that refers to the potential differences in performance, accessibility, and performance that users may notice?
Web app doesn't work for what you are talking about as far as I can tell. Of course this is an industry where terms and definitions change a lot.
In a discussion of 'native apps vs web apps' it absolutely makes a difference that Electron apps are rendered by a browser's web view - they're basically a web page rendered by a local source not remote, but without any of the sandboxing that proper browsers employ for security.
> Maybe we need a third, generic term for electron apps and others like them. A name that refers to the potential differences in performance, accessibility, and performance that users may notice?
Sure. Shit Apps (tm).
Those are also reasons not to call them web apps though: web apps run in your browser of choice (ish) with all of the associated security and accessibility defaults, plus your extensions and whatnot. They are apps on the web.
> Shit Apps
You can do better.
More importantly, so can desktop application developers.
You're confusing web apps and client/server apps. Web apps are generally thought of as apps written using web technologies. This means that a web app may not even interact with a back-end server, or a native app may exclusively interact with a back-end server.
And Electron embeds an instance of Chromium, to provide a webview for the 'application' interface.
How is that not a web app? It's written in HTML, CSS and JS, it runs inside a browser.
Just because the user can't choose the browser doesn't mean shit. Users couldn't choose the browser to run a lot of Microsoft-stack Web Apps in the early 2000's either, because they only worked in MSIE.
In my view, Electron does not embed a browser, it does embed a HTML/CSS/JS renderer.
Like buy one, get two for free.
There is a lot of convenience in being able to log into any computer and access your mail. Plus Gmail search beats the search in native clients most of the time.
And gmail isn't your mail, it's Google's mail. A mailserver that you host yourself is your mail.
Additionally, if we are really picky, only mail written by you is your mail. All mail received is normally copyrighted by someone else and belongs to the sender or/and his/her company. Very strictly speaking in some countries you are not legally allowed to forward someone else's mail if it bears any artistic value.
Yes I know, it is off topic. But it was fun, thanks for the spark!
Source please? Shouldn't there be a creative aspect about it? Which is probably not the case for lots of emails.
>[...] if it bears any artistic value.
Source: As this depends on the country you live in you would have to look up your country's copyright law and see if it's true for your country.
Why do you think it is good?
There is nothing that says that you can't have both web and native mail clients.
Usually when I change jobs I have had another non Gmail account but I have never found the search as good. I have an outlook web client at work and that doesn't find things. Maybe its me being dumb and remembering different phrases from what is actually stored, but I almost always manage to finds what i am looking for in Gmail. I can't say the same with other clients.
Its just a pity that I have to give up my privacy to Google for it.
It's what you'd expect of a cloud service though, they really don't want to go through all of that data.
Any native client though will just go at it and return proper results.
By the way, when do you plan to release the beta?
Where is the corresponding "Ask HN: What requirements should I consider before writing a new email client?"
Oh boy. I've written a mail client [1] (two actually) and I've found that people have widely conflicting requirements.
Me? I wanted to replace mutt with something that was similarly console-based, and would use the same Maildir hierarchies.
Other people demand GUI access, sometimes with IMAP, sometimes with POP3, and sometimes (very rarely) with just local Maildirs.
If I were to begin again I'd probably abandon Maildirs, and instead just work via notmuch, or some other indexed-store. That would allow "virtual folders", and other neat things.
I don't think I've got the patience to start again though, as my current client is already the second version.
1 - https://lumail.org/
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.
So the choice becomes use an Electron app or something else entirely.
But I agree, it's almost never a choice, but it's a hypothetical
So in some ways I’d probably prefer a good Electron app.
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.
All other things will never be equal.
My point is that given two apps that both have the features a user considers "must have", few, if any, would pick the Electron one over the native, precisely because of the extra burden in cpu/memory/speed of Electron.
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.
Is it possible that VS Code (for example) exists (in its feature specific incarnation ) only because Electron is a cost cutter in terms of portable development?
In other terms: Maybe the portable native full featured VS Code is the middle of the cheap-fast-good venn diagram.
It could -- though I doubt it.
But I was concerned with a more limited question: if there was a good VS Code alternative that's native, would many still prefer an Electron version?
I understood what you meant. I respect you disagreeing with my premise, but in the scenario where that premise is true, your question is not applicable.
Scenario: Would anyone choose MDF boards at IKEA if they could choose plywood or natural wood, or assemble their own furniture if given the choice (at the same price)? Barring a few applications, probably not. But IKEA wouldn't be IKEA if they were just another producer of wood furniture, meaning they got to market and stayed there because of the shortcuts and limitations they could justify when reaching a price.
Same thing here (IMHO). VS Code could have some cross-platform code and some platform specific code, but the cost would be higher and the output velocity would likely be lower. Assuming that is true, your question is misleading, albeit not on purpose.
There is sublime text.
A lot of it, yes. But VSCode also invests a lot in core functionality (in what in other platforms would be plugins). The Git integration is one such example -- or the ability to debug Chrome in it.
>That's because, as the parent said, there are no good (e.g. equivalent) native alternatives.
But that's not true. I use Sublime Edit and have happily used BBEdit and TextMate. Emacs is fine for many people, and I still use vim for fast edits in terminal mode all the time. There are plenty of other great native editors for just about all platforms.
If you don't go the mutt/alpine route, there aren't much options. Basically Thunderbird and Evolution. Never really got Clawsemail and iscribe to work with my IMAP server settings.
To make things worse, people do understand email less and less. Often, all ports except 80 and 443 are blocked and you can't even use IMAP/SMTP. And if you complain they tell you "What are you talking about? Gmail works...."
Evolution somehow stores a cookie or can log in via webbrowser or something like that. Evolution will never get you logged out of your Gmail account (yes, I have one that I use for some things). I travel a lot and Thunderbird will always get blocked by Gmail (Please log-in via Webbrowser to confirm your identity).
I care... but the convenience of a webmail client accessible on any device is just so great. But there's no good way to really have secure end-to-end encryption in a webmail client. That's about the only thing that would make me seriously consider a desktop client.
Really, I'm not sure what the audience size is for email you can't see on your phone though.
- Is this open-source? What is the license and where is the source-code?
- When can we expect a linux version?