I would not recommend that with any email clients. Most are built with the assumption that you have around 3 to 8 accounts. UI, speed, and configuration may become an issue. Esp. the unified inbox in Thunderbird was slow in my personal use.
What are these mailboxes? Are they changing a lot? That's also a factor to decide in your setup.
If you have hundreds of mailboxes, and you're posting on HN here, chances are you are technically competent. I would recommend a local IMAP server like Dovecot or Stalwart installed as Docker, and then fetchmail or similar to pull (copy) all the mail into a single inbox. And then your email client uses only that one account which has all emails.
Back then, did we have an app that can do email and calendar, and sync that with our phone?
Did that app work on all operating systems that were in use at that time? With a simple install? On DOS, Amiga, Apple, Acorn, Unix? The same app, with the same functionality?
If not: Would you rather live in a world dominated by native Windows applications, written in C with Win32?
Which cross-platform email+calendar GUI app existed back then, which could sync with these phones, and works with feature-partity on all of Windows, Mac and Linux, and was not built with web technologies?
> The right choice would be by Fastmail to cooperate directly with Evolution, Thunderbird, K-Mail, Apple Mail and help them were needed.
Funny, I've actually been sitting literally right next to the Apple Mail developers when Fastmail developers (who were sitting on my other side and across from me) helped them make Apple Mail work better with Fastmail and other modern mail servers, in various ways.
Fastmail is very active in the IETF, creating new RFCs that standardize modern email protocols [1] and adapting existing protocols to user needs [2].
Unlike Gmail and Outlook/Exchange coughcough, who I cannot even reach for serious bugs.
> native application (Gtk, Qt, Cocoa)
Do you know a cross-platform app (Windows, Mac, and Linux) that has many millions of users and is implemented natively on each of these platforms (Gtk, Qt, Cocoa, Win32 etc., respectively), not with JavaScript? I can't think of any.
There are limits in the real world. Software teams don't scale well. Corporate agendas are set 5 management levels above the developers. Most of the apps you mention have very serious technical dept that would require a complete rewrite to get out of. I speak from first hand experience of 25 years working on 3+ different mail clients, most of them with millions of users. Seasoned developers usually made their decision after much deliberation. The "right choice" (your words above) is often far more complex than an observer can possibly know.
Please don't throw peanuts at the developers from the peanut gallery [3][4].
> Do you know a cross-platform app (Windows, Mac, and Linux) that has many millions of users and is implemented natively on each of these platforms (Gtk, Qt, Cocoa, Win32 etc., respectively), not with JavaScript? I can't think of any.
If you consider Mac and Windows sufficiently cross-platform, any of the major Adobe apps.
I listed native apps for all of these platforms. That’s the solution.
A less efficient alternative would be using one of these toolkits on the others platforms. Lets say Gtk? Common well known Gtk apps like Gimp or Inkscape excel well on all of these. And are better on macOS and Windows than any kind of Electron.
Back when Chrome wasn’t considered a memory hog it used native toolkits of each platform! Yes. Gtk, Coca and Win32. That was a an effort. And yes. It was fast and convenient.
Put back to begin. Nobody asked for a fat Electron build. They searched and found a bad solution for a problem which doesn’t exist. You gave the very best example for the way to go.
PS: And ** Apple for turning off the APIs for Push Mail Notification on iOS. Now mail providers need to consider own apps for iOS. APPLE! Just turn on Push Mail for all other than iCloud!
We’re living in a world with hacks for problems that never should have existed.
Actually, Thunderbird is using the Mozilla browser as a runtime for the UI and a lot of its code, in exactly the same way as Electron apps are using Chrome and node.js. Even a lot of non-UI code in Thunderbird is implemented in JavaScript, including some of the protocols like POP3 [1].
The same is true for Firefox: Almost the entire Firefox UI is written as HTML page with JavaScript. In fact, Firefox, Thunderbird and their predecessor Mozilla Suite were the first desktop apps written as webapps, and are the direct precedessors of Electron. And they also show that it can be done well. You just have to do it well, which is not easy.
There was a reason for that decision: Netscape tried to implement all its UI natively on 3 platforms - Windows, Mac and Unix -, which was too difficult in practice to keep them in feature parity. The big new thing about Mozilla - apart from the Gecko engine - was to implement the UI of the desktop app as web app, and run the same code on all platforms. That idea is the technical foundation of Mozilla.
Electron is just using that same idea with Chrome and node.js.
The only reason why using Linux as desktop today is realistic, is that web apps put an end to the monopoly of native Windows apps - which was the ultimate goal the whole time.
/Ben Bucksch Long-time core developer of Thunderbird
I would not recommend that with any email clients. Most are built with the assumption that you have around 3 to 8 accounts. UI, speed, and configuration may become an issue. Esp. the unified inbox in Thunderbird was slow in my personal use.
What are these mailboxes? Are they changing a lot? That's also a factor to decide in your setup.
If you have hundreds of mailboxes, and you're posting on HN here, chances are you are technically competent. I would recommend a local IMAP server like Dovecot or Stalwart installed as Docker, and then fetchmail or similar to pull (copy) all the mail into a single inbox. And then your email client uses only that one account which has all emails.