I guessed it was built with Electron (or at least a WebView) even before seeing the screenshots.
Creating a fully native desktop app takes a huge amount of engineering effort. When you factor in their target platforms (Windows, macOS, and Linux) you’re looking at multiplying that effort several times over. No one in their right mind would build a fully native desktop mail app these days, unless that’s the one thing that sets them apart from the dozens of other web-based mail services out there.
The only real benefit I see in this Electron app is system notifications for new emails, assuming people keep the app running in the background or minimized most of the time. Other than that, the web version will almost always be better and more up to date, since it’s clearly the main product.
I can totally picture people buying MacBook Pros with 128GB of RAM just to run a bunch of Electron apps, hehe.
That's simply not true. "we" are misusing HTML to create applications because the tooling and distribution are so good. ReactNative / NativeScript, and probably more allow you to create apps using native or html implementations of the interface.
It's just that people start with HTML, and then it's just easy so slap Electron around it.
Think of ReactNative / NativeScript like QT/wxWidgets but they are compatible with html too
I assume that this app is not a mailing app, its an app to control your fastmail service, which includes email, file storage, webhosting, various dns controls, notes, contacts, billing etc. They already contributed JMAP. It would be impossible for them to get all of those features into k-mail - k-mail wouldn't want them.
And packaging the app in electron is relatively easy and a nice convenience for some users.
For us technical people "native" means something different than it does for regular users. It just means they have an app for their platform and not just a web app.
Most people can not differentiate between a web app in a browser and if an app they start through an icon on their computer is a wrapper around a website. People on HN who care if it’s built with Rust, Swift or an Electron app aren’t really the core audience for most companies.
That's a disappointment, and in the screenshots, the app actually doesn't look native at all. The new Liquid Glass design, with the round search boxes and transparency, is nowhere to be seen.
Therein lies a detraction to making native apps. Binding yourself to how native apps look now will be a liability. People will judge you as outdated when the operating system moves on to a new groove.
I pay for Fastmail and I'm using the Fastmail desktop app right now.
It's much faster than Thunderbird so far for me, and more convenient than a browser tab for me, and I'm especially liking the interconnections among mail, contacts, and calendar. The best feature for me is being able to click an email link anywhere on any web page, and have it lead to the Fastmail app.
I do have two questions. The app on my macOS system is using 700MB RAM; is that for Electron? The majority of RAM is showing as GPU rendering; is that for font smoothing?
It is Electron. Sadly this is usual for Electron applications, the company saves developers and you pay with hardware. Software scales well, so investing in development would be much more efficient.
It is not strictly necessary to waste so much resources with Electron. But usually it is, because optimization also requires developer time. Even rather good Electron applications like Signal require much more resources than a native application (Gtk, Qt, Cocoa).
The right choice would be by Fastmail to cooperate directly with Evolution, Thunderbird, K-Mail, Apple Mail and help them were needed.
Strange that you’d feel entitled to how they spend their money. Imagine if they spent most of the money sipping pina coladas instead - would it make sense for a teetotaller to be upset about that?
You paid them for services rendered. They’ve offered an additional service they didn’t previously for no extra charge. Now you’re upset, even though you’re still getting the same service you were previously at the same price?
People sometimes pay for these things like email and search which they can get for “free” because they want to conduct business with reasonable people who will provide good custodianship of their data and be a reliable partner long term. I don’t want to have to change email provider when my next invoice comes up because they put 6 devs on building an electron app for a year. Hyperbole obviously but their actions are an important indicator of how sane and grounded management is and will continue to be into the future.
I don't think that is what they are talking about. Users can be sad. But they cannot claim ownership of a money they "spent". It is not their money anymore.
As a paying user, I am also beyond saddened that companies work on features I don't use, but I realize I'm not their only customer and different people need different things.
Electron in almost every case means the user’s hard earned money is being wasted by more power consumption and more use of RAM (which increases disk I/O). Considering that it’s across many users, the hyperbolic statement would be that it’s an environmentally unfriendly option.
Or do what the rest of us have done and configure our usual clients with IMAP access.
I’d rather Fastmail ship their web client in Electron than waste engineering resources on reinventing the wheel for a client that’d get it’s own share of endless complaints from people wanting it to be more like Outlook or Thunderbird or Mutt.
I'm pretty sure the GP was talking about their subscription payments to Fastmail.
But I admit that you got me curious, do you really expect a substantial increase in power consumption due to Fastmail getting a % of their customers to run Electron instead of Thunderbird? I'm really bad at this kind of back-of-the-envelope math but I struggle to imagine that it's substantial.
Like wouldn't one kid in Nebraska playing an AAA game in anger for half an hour, on one computer, once a day, use more energy than all those electron installs combined?
Do you see a regular user researching, downloading and setting up a third party email client or is it more likely they click the download button on Fastmail and log in with their account?
That’s the beauty of open standards, everyone can choose their favorite tool for the job depending on their preferences and skill levels.
No, I see them using the web interface actually, just like they've done so up until now.
I don't think for instance this was keeping a lot of people from switching to Fastmail from let's say Gmail, which also doesn't offer a desktop client.
If Fastmail has an adoption problem it's still from people not wanting to pay for their email, a desktop app is not going to change that.
That's a lot of assumptions unless you know their internal numbers and customer feedback. I've talked to many people building products and often they themselves are surprised what's needed to get certain larger customers, even if they would never use certain features themselves.
I could very easily imagine that if a company wants to switch over their employees from another provider where the users had an app that had email / calendar /contacts all in one app that they would like to have that same setup again on Fastmail. In the end packaging their web app in a wrapper to satisfy that need of certain customers groups doesn't seem like something that should be very controversial.
Spending your money on this brings them in more money which could potentially be used on features you do want.
Not certainly, because that’s not how paying a subscription works. You would have to contact them too discuss directly paying for a specific feature. But potentially!
Are there any desktop apps that support Fastmail's label implementation? Also, a Fastmail web app bundled in Electron would still be MUCH faster than Thunderbird with its bundled Mozilla components.
Evolution added some nifty features lately (Markdown integration). And allows to use Client-Side-Decoration annd classic menus - usability wise awesome. Thunderbird got this year a complete redesign.
I avoid Electron apps because in every case that I've used one, they have completely in-house UI and window management. Thunderbird is ugly as sin, I'll give you that, but, but at least it mostly let's me manage windows the way I want. Slack, on the other hand, won't even let me have tabs for two different channels. Let alone open the preferences while not navigating away from a chat I'm in the middle of.
* Non-native UI toolkit
* Massive waste of resources (CPU, RAM, Battery, Disk). Consumption of 500 MB RAM for idle is the norm.
* Slow.
* Often issues with autonomous, local operation.
* Security -> Browser Engine
It is always better to use a well-working application with your native UI-Toolkit:
* Linux: Evolution, Geary, K-Mail, Claws, whatever TUI application you prefer. And Thunderbird.
* macOS: Apple Mail or Thunderbird.
* Windows: Please. Stop using Windows. You harm other people. Start with using Thunderbird :)
The “Electron” from Signal is one of the best applications using Electron. It is fat. Even in this case people resist. Signal isn’t supporting a stable API but:
https://github.com/boxdot/gurk-rs
TUI :)
Electron is used, when a company wants to save on developer. All users pay with suffering from bad UI and their hardware resources. In this case it is something nobody asked for?
Thunderbird is no different than Electron apps, though. It's built on a browser engine, renders UI written in HTML + CSS (+ XUL partially), consumes ~500MB of RAM on idle, etc.
I use Thunderbird everywhere, but I want to contribute this to the conversation: you don’t have to have your email client open all day long. I open my email client few times a day, and that’s it. I do the same with my chats, but with the chats (especially the work ones) I’m expected to reply within minutes, unfortunately. And, well, that’s another topic.
For email, I mostly don’t care whether it takes too much RAM, if the app is usable. I work with it, then I close it. That’s my workflow, at least. I believe I’m not alone in this. My iPhone is the mini server that gets all the notifications for the emails I need. (By being connected with the default email client.) So, if I want to reply from my laptop, I’ll open my app. Otherwise it’s closed.
I guess you can do that. I have my Thunderbird open 24/7 for days on end. It does seem to occupy 700MB of RAM after a while. Firefox is way worse of course... I keep Signal desktop open too, sits around 160MB.
Flash was awesome. It was proprietary, unstable, insecure, but in other regards it was much better than competition at the time.
Electron is open-source, stable and secure (as long as you stay up to date).
You’re making a compliment.
> * Non-native UI toolkit
That’s a drawback, not a plus. You can’t easily style the app with CSS the way you want it (VSCode, Obsidian).
> * Massive waste of resources (CPU, RAM, Battery, Disk). Consumption of 500 MB RAM for idle is the norm.
Nonsense. Obsidian is sitting at 115 MB right now, zero CPU.
> * Slow.
Define slow.
> * Often issues with autonomous, local operation.
???
> * Security -> Browser Engine
The only real drawback so far. Can be mitigated by staying up to date.
> It is always better to use a well-working application with your native UI-toolkit
It is always better to use whatever works best for you and solves your problems. Not OCDing around technology and not playing identity wars with crazy people online.
> Electron is used, when a company wants to save on developer.
Also a big plus. Features are being delivered to all platforms with less money spent. Win-win.
> All users pay with suffering from bad UI and their hardware resources. In this case it is something nobody asked for?
You need to seek therapy if you’re “suffering” from application using the toolkit.
P.S. Thunderbird performs worse than ANY Electron app I’ve ever used, and I’ve been using Electron since its inception.
> I do have two questions. The app on my macOS system is using 700MB RAM; is that for Electron?
Shall we discuss any of the other claims? Your security solution are constant updates?
Invests in efficiency scales with users. Most things which suck are caused by laziness and cost saving. It would be far more efficient to help either Evolution, K-Mail and Thunderbird with access to special APIs and keep them stable.
You know what does have theming? Win32, GTK and QT. GTK even uses CSS for it.
And unlike electron apps, when you change how a button looks in your GTK theme it affects all GTK apps rather than just the single electron app.
> Nonsense. Obsidian is sitting at 115 MB right now, zero CPU.
I just downloaded obsidian for the first time and launching it spawns 8(!) processes using a total of 827.3 MB of RAM. That's at the launch screen, before it's doing anything.
Of course it's using no CPU when idle. That's basically the bare minimum bar for any application. It's well known that javascript is at least an order of magnitude slower than C. That's where it's wasting CPU, not when it's idle.
> Define slow.
Well to start off with, I can count the seconds obsidian takes to start up. Most native apps I have installed (other than browsers) start faster than I can reasonably react.
I love Fastmail, but this feels like a waste of time. I'd rather just leave Fastmail open in a browser tab, rather than install Flatpak just to load an Electron app with the web client in it.
Indeed what I do as well; gives me apps for Youtube, Netflix, etc. The only downside is that you have to login if you do not use the "app" for a while. Would Electron get around this?
Understandably, as technologists we are in uproar at yet another Electron app due to the widely-accepted performance concerns many have with them. But if you don't want to run this, you can always just run it in the browser as before. Nobody is forcing you to install it.
I sometimes think we forget that Electron would have allowed them to ship this to customers super quickly, across all desktop platforms, and get a nice-looking application in to the hands of their customers (who probably have been requesting this for years).
Internet comments are all kinda insufferable in this way, because most of what you get are complainers while the happy people stay silent. There must be a name for this phenomenon.
I don’t get the negative sentiment here. I know that as someone who uses a third party email client to use Gmail / Fastmail via manually configured IMAP I’m a very tiny minority. Most people probably use the web interface or the Gmail app on their phone.
Nothing wrong with offering an option for people who prefer a desktop app, you don’t have to feel like you are the target audience for everything.
This has been the standard way to distribute software across platforms for a while now. I'm not sure I understand this kind of objection anymore. What's the alternative?
Fastmail also have a decent API if you're keen to glue together a better client yourself.
Agreed, Fastmail works so much better than GMail/Google Workspaces, moved my personal domains to Fastmail a while ago, and it's painful to use my work GMail during my day job...
There is no connection between whether an app is native or electron based and its UX so not sure why you'd bring this up. There's enough and more native apps with horrible UX and plenty of electron apps with excellent UX.
Yes. I'm over the hatred for Electron too. Programmers have few options if they want cross-platform compatibility without Electron. What else are they going to use? QT? Please, give me a break. Some angelic developers like the KeepassXC guys still use QT, but that is a tough road to go down on. For the rest of them, Electron Or Bust I'm afraid.
I would unironically rather have nothing than an Electron app in most cases. They are that bad. And in this case the app doesn't even add anything of value. Literally any email application will let you do the same thing.
> I would unironically rather have nothing than an Electron app in most cases.
So let me understand something: you obviously have a free will to not use something, but you would prefer something TO NOT exist and NOT solve problems for users, because you hate the technology so much?
Whoa. This looks very interesting. Does it support maths? Are the images stored locally? Can fonts and typography be changed? How does it differ from your open-source version which looks similar?
- Not yet, but adding support for Math blocks is planned.
- Yes, images are stored locally in the ~/user/.config/Awesomeness/attachments folder
- Yes, but only for pre-defined fonts. This is by design - I wanted the app to be opinionatingly simple. But since I got many requests for that, I'm gonna add an option in the settings for that.
- My FOSS version uses a simple plaintext editor (QTextEdit) with some Markdown highlighting. Daino Notes uses a block editor (a la Notion) I wrote from scratch[1] - this allows me to add complex blocks *in the middle of the documents* - so things like Kanban, Images - any custom component that I wish basically - so also math blocks, tables, etc in the future. It's also allows me to do nifty things like cool drag & drop[2] and the editor is even more performant than QTextEdit (especially on large texts).
In order to abide by QT's license, you have to follow the appropriate set of rules, depending on how you use it. You can use it LGPL, at which point you need to release the QT source you used and dynamically link it in your program. You can use it GPL but you have to release the source to your app. Finally, you can give QT money, and use it closed source. Okay, that wasn't that complex, but those are the rules if you want to use and distribute QT legally.
> You can use it LGPL, at which point you need to release the QT source you used and dynamically link it in your program.
This is wrong. There's a misconception that you can't statically link your app when using the open-source LGPL version of Qt. From my reading of the LGPL license this doesn't appear to be the case[1]. The LGPL allows you to statically link your app as long as you provide the object files and allow users to relink your app with a different version of Qt.
I've observed many people spreading this misinformation about only being able to dynamically link with the LGPL version of Qt. Please stop this.
I've used similar webview solutions before and they can break even on Windows (example: needing edge webview2 but not available on the user install). I get why people are pissed off by Electron but I also get why it's the de facto standard in its field.
I am already using fmail3 [1] and before that fmail2 which is also a web wrapper but feels more native to mac than Electron apps. And I think it is written in swift. So I don't know why fastmail cannot do something similar after all these years.
I find it rather strange that so many email providers have to develop their own "app".
There are so many good clients out there, and I'd rather have 1. The team focus on their core offering, and 2. the existing email client is for the same reason (limited developer time, and matureness) a much better choice for security
> I find it rather strange that so many email providers have to develop their own "app".
It's probably because people want easy access, and have all features supported flawlessly. Mail has come a long way, but there are always specific features not integrated well.
Also, most of those apps are more a thin wrapper around the web-interface, adding some interface-sugar for desktop-integration and serving as a playground for devs to test the web-apps offline-abilities.
> There are so many good clients out there, and I'd rather have 1.
I've yet to see any good client for me. They all are kinda flawed and limited, many suffering from age or not fitting modern demands. Thunderbird seems to be the only trustable Linux-compatible one which is still actively developed, and even this is app is lacking on many corners. Add-ons are supposed to fill and round up the corners, but without anyone developing them, what's the worth in having them?
Fastmail at least seems to work on developing the mail-standards, and having their own client is probably helping them in figuring out how well those improvements are working and where they are lacking.
One reason could be that they need one if there are unique differentiators on the roadmap that cannot be added into regular clients. I dont know if this is the case.
This is basically where I'm at. I love Fastmail, but going to the effort of trying to get JMAP standardized and then investing development effort to NOT put it in Thunderbird feels like there's no real intent to make email better for everyone, which is disappointing.
It's very practical when you use a lot of different devices. It's nice to use native built in email apps, but when using multiple different OSes and device types, it can be very annoying to have the different clients play nice with each other.
Chief Product Officer of Fastmail here. I see a lot of comments here from people that don't appear to have actually tried using the app, which is a little disappointing; don't knock it 'til you've tried it! Happy to answer any questions, but to answer the main ones that are popping up:
# Why Electron?
Because it lets us build an app that works well across all major platforms with the resources we have available. Building an email/contacts/calendar app is a huge undertaking. Doing it from scratch on each platform is just not feasible for us.
With Electron, we can maintain a single code base across all platforms so we can move faster, and keep feature parity everywhere. More than that though, we believe it lets us build a really great experience on each of these platforms, while offering a consistent UI for our customers across all their devices. Honestly, we can never out-native Apple because by definition whatever they do is "native", even if it sucks (Liquid Glass on the Mac is … not great UX). If that's your primary consideration, you will always be better with Apple's own Mail app, so it's pointless us trying to build something in that space. (And instead we work to also make Fastmail the best service to use Mail.app with — which we believe it is!)
# Why would you use this instead of the webmail?
If you prefer to keep Fastmail in your browser, great! You can do so. But we hear from many customers that they would rather not have their email mixed in with their tabs. With a separate app you can see it in the dock, Cmd-tab to it, make it your default email app system wide etc. It also lets us integrate with the system, like the Mac menu bar and native context menus.
# Why would you use this instead of an IMAP client?
If you've ever used the Fastmail web interface you probably already know the answer, but for everyone else…
1. It's a lot faster. Compared to Apple's Mail.app for example (which is a good IMAP client!):
- It resyncs way faster when you open the app, and uses a lot less data (JMAP is so much more efficient).
- Moving between messages is quicker. With Mail.app there's often a slight lag between clicking a message and it rendering. In Fastmail, it's usually instant.
2. It's more powerful. We provide the best standards support out there, and are also working to make the standards better. But there's always going to be more that we can do when we control both the server and the client. With the Fastmail UI you can:
- Add private memos to emails
- Mute conversations to ignore replies
- Pin important messages to the top of your inbox
- Schedule messages to send in the future (and not need your laptop to be online then for it to work)
- See related emails when you open your contacts.
- Add events straight into your calendar
- And much more (https://www.fastmail.com/features/).
3. It's got much better search. (Yeah, this is kind-of just "more powerful", but I'm calling it out because search sucks in most email clients0.
# And finally…
This is just a choice. We hope this is something that some of our customers will love, but we're not backing away from our commitment to open standards and encourage everyone to find what works best for them.
I appreciate you taking the time to engage with your customers here. I’ll say this announcement doesn’t thrill me, as a long-time customer. I’ve been paying for Fastmail for at least six years. It may be as many as eight but I can’t find my oldest receipt.
I use Fastmail because of the excellent mail service, customer support, sieve rules to keep my inbox manageable, and because of the little details like WebDAV that I have unexpectedly found useful for things like syncing browser bookmarks. I pay for Fastmail because it has been excellent, not because I’m captive.
This app signals to me that there may be a change coming in our relationship. One in which you may start to neglect
IMAP or make it harder for me to choose my own mail client. It tells me that Fastmail might be pivoting into “growth” and treating me like a “user” rather than a paying customer. It won’t surprise me, and I can’t really say I’d be mad. Most companies get to that point. There’s probably a lot more money to be made from vendor lock-in than happy, $50 per year customers. As for me and mine, I will switch to the next small-to-medium-sized mail provider the second I get a sense that this is the direction.
I'm sorry you feel like this, but it absolutely doesn't mean that. I believe we probably devote more engineering resources to open standards development than any other company, with significant resources given to the mailmaint, calext and jmap working groups at the IETF, not to mention the maintenance of the open-source Cyrus IMAP/JMAP server. I don't know why would do that if we were trying to just keep people captive because it's hard to leave. "Your data belongs to you" is one of our core values: https://www.fastmail.com/company/values/
> There’s probably a lot more money to be made from vendor lock-in than happy, $50 per year customers. As for me and mine, I will switch to the next small-to-medium-sized mail provider the second I get a sense that this is the direction.
Just so you know, the next-best provider is Proton and they're in HEAVY growth mode at the moment. Their UI is strewn with upsell widgets.
I would consider using this app on my desktop instead of Thunderbird primarily due to the improved search.
After giving it a spin for 180 seconds, the main nuisance for me is that I can't elect to "Always show images from this sender". I use that in other desktop clients to ensure the image blocking banner doesn't end up being subconsciously ignored by me, as it will then only show for new senders who I'm not familiar with and need to be more wary of.
Also, like all banners everywhere no matter how well designed, it's ugly. In fact to be honest... this is the main reason I want the option to get rid of it.
I can understand why you don't offer that in the web app if you're storing it server side for each customer's list of saved senders, but for a desktop app where it can be stored locally, I'd value it.
In Settings -> Mail Preferences you can choose to:
* Show images by default for everyone (the images are always proxied via our CDN, so your IP is never leaked to the sender).
* Show images for contacts by default. You can easily add new senders to contacts by clicking their name at the top of the email and selecting "Add to contacts".
A good IMAP client (in combination with my own domains) gives me freedom. I use Fastmail, I like it, and your support is great, but I don't want to tie my usage of your service to your UI. That would tie me down to your service.
So I use Thunderbird and K-9 Mail, and occasionally the Fastmail web UI to manage masked e-mail addresses etc. That is my happy path.
I want to be tied to Fastmail because of your stellar support and good service, not because I am trained to use your UI.
By the way, fastmail.com is now in full advertising mode for this new app. It's hard for potential customers to see that you support IMAP just fine. Please show potential customers that the app is just one option as you say; not a requirement. Your website currently does not communicate that message clearly.
Hi! I have been using Fastmail for the last 2 years and love it!
I don't use the web interface much, instead I use Apple's Mail.app. My only issue is that external email accounts (gmail) take some time to be fetched periodically. When I open the web interface and click on the tag, it instantly pulls the new mail in from the external account, but if I fetch in the Mail.app, it doesn't refresh the external accounts. So, for things that have a very short time period (confirmation codes), I still end up needing to open the web interface. I wonder if this would still be the case with the new desktop app?
I will take some time to set it up over the next days and try it out!
I’ve been a long time Fastmail user and generally love the service.
I’ve got one question not about the new desktop app, but I was wondering if you’d consider adding some kind of automatic email sorting like Gmail? I feel like I’m in a constant battle marking newsletters I didn’t ask for as spam but there’s always new ones. And wish there was a feature that just automatically filtered them all in to a bucket for me.
> Because it lets us build an app that works well across all major platforms with the resources we have available. Building an email/contacts/calendar app is a huge undertaking. Doing it from scratch on each platform is just not feasible for us.
Just to be clear, does this mean the app is mainly reusing the already existing codebase of the web-app? How much additional work went into the desktop-app?
I'm interested, both as a Fastmail customer, and a software developer: what does this let you do that a PWA doesn't? Perhaps not become the default email client? Is there anything else?
The main thing is better integration with the OS. So no browser chrome (even as a PWA, the browser adds buttons or a toolbar over the top of the app), integration with the Mac menu bar, native context menus, the OS semi-transparent background for the frame so it feels like it belongs.
No final decision, but possibly not. Given Apple are dropping support for x86 Macs next year, it's unlikely to be something we could support for the long term.
I think you should also understand that HN is not best place for this kind of news. This is page for people posting very obscure and hacky things. People that try to squeeze miliseconds on everything they do or do things the clever way. Why we should be happy for something that is the antitesis of clever and basically could be called corpo-slop?
> People that try to squeeze miliseconds on everything they do or do things the clever way. Why we should be happy for something that is the antitesis of clever and basically could be called corpo-slop?
If you want a fast small (6 MB vs 318 MB) Fastmail client, use FMail3 (https://fmail3.appmac.fr). More options than this Electron shell around a web page.
Use tabs, windows, Hook and much more. JMAP API handles real quick notifications.
Have a look.
I use fastmail for long time and this move is not good. Instead of investing into TB for example, they do Electron bloatapp... Will for sure never touch that thing
Why should Fastmail invest in Thunderbird, an open-source email client run by a completely unrelated organization? Of course they could, out of good will. But you can't demand that they do.
This is just their webapp wrapped in an off-the-shelf browser engine. Hardly any development resources needed. It could have been quickly put together to tick a checkbox for some big client, the revenue from whom could help them work on features that actually matter more. None of us needs to use it. But somebody must have needed it, so here it is.
> Why should Fastmail invest in Thunderbird, an open-source email client run by a completely unrelated organization?
One very good reason is that Fastmail created the JMAP protocol and while work on getting it into Thunderbird started several years ago, it hasn’t progressed. So JMAP is kinda stuck (obviously Microsoft is not going to put it in Outlook).
It could’ve been a win-win-win for JMAP, Fastmail and Thunderbird to accelerate the implementation and support for JMAP within Thunderbird. This would/could help in JMAP adoption by other mail providers too.
On the same boat as everybody else that this is electron based and not a great experience. I think from a business perspective this is just meant to satisfy those customers that are asking for a standalone app.
If Electron is inevitable, could we make electron slimmer? We don't need backwards compatibility, and we don't need certain features from browsers. Is it even possible to compile without them ?
I know Fastmail isn't the hugest place in the world and the set of skills involved but it feels a bit insulting to roll this out rather than contribute into Thunderbird in a way to get what Fastmail feels is necessary out there.
Thunderbird has had a good number of QoL improvements, and the calendar plugins etc are quite niec. Just if one day search could... uhh... work, that would be nice
they have an amazing team, integration with 1 pass, tons of good things and chose a shortcut like every other major company because it generates revenue, short wins over strategy
I don't hold it against them in the sense that this is the easiest stack to onboard onto, but all the recurring lost effort on native e-mail clients seem very unfortunate.
Fastmail does, of course, probably consider its UI chops etc to be part of their value add. Just seems like if they also want to win over people who like native clients then "here's a bunch of shit that makes native clients also work very well with our offerings" is less of a lift while being more helpful overall. Maybe.
I would rather have more integrations with third parties rather than this.
My main problem is that I have to put a lot of effort to not use gmail for my business because most of third-parties (like CRMs) work only/better with gmail.
Do you mean to access Fastmail as a client for your Gmail-hosted inbox? How about using the fetch feature that moves all emails to your Fastmail inbox, and the 'send as' feature where you can send emails out from your Gmail SMTP via Fastmail. Those two features already exist.
Although when setting this up, Gmail really make you feel like they might pull support at any minute.
I wonder if Fastmail could log you in to Gmail in a way that's consistent with Google's security model, similar to how you can "log in with Google" on many services. I'd much prefer it over the app password thing.
Now that you mention it, I remember that's how Fastmail works today. They use app passwords for non-Google-hosted email inboxes, and 'login with Google' for Google-hosted inboxes.
Replying to mail that arrived through masked email addresses will also reply with the masked email address and not accidentally leak your main address.
Also creating masked mail addresses in the first place.
Going to post the unpopular opinion here, this is also good for them purely for deployments/sales.dont forget the common denominator of "open fastmail app on your windows computer" for the tech literate.
I'm sure there was some deal that didn't get completed because of this.
I was considering Protonmail (have a paid subscription for many years even) but that is e2e encrypted, which means searching emails needs a local index of all emails. I have many many years of emails and several client apps. So that is not an option for me.
Therefore I wonder if this is different (‘better’) for Fastmail. It means Fastmail also can see the contents and that is ok, I just want to move away from US providers.
No one uses desktop apps. Maybe you should spend the engineering effort to make improvements to your phone apps. Like make it so the Android app doesn't load and then re-load every time I open it. Or support for offline mail.
May I ask how old you are? Interesting perspective to me that " no one uses desktop apps". In my bubble people only use the phone to get notified about mails, but do the interaction on a desktop computer using some mail app
If AI is really making developers so much more productive, companies should invest that productivity into offering better technical solutions. This means native applications for each platform.
I’m not a customer of Fastmail, because the laws in Australia are very anti-privacy and Fastmail is at their mercy. But my mail provider has exactly the same problem: a lame web app.
This is not a “technical person” complaint. These so-called apps look and behave worse on macOS.
I saw this post on telegram, and noticed something weird about the webpage preview
It says "native", electron is opposite of thatI guessed it was built with Electron (or at least a WebView) even before seeing the screenshots.
Creating a fully native desktop app takes a huge amount of engineering effort. When you factor in their target platforms (Windows, macOS, and Linux) you’re looking at multiplying that effort several times over. No one in their right mind would build a fully native desktop mail app these days, unless that’s the one thing that sets them apart from the dozens of other web-based mail services out there.
The only real benefit I see in this Electron app is system notifications for new emails, assuming people keep the app running in the background or minimized most of the time. Other than that, the web version will almost always be better and more up to date, since it’s clearly the main product.
I can totally picture people buying MacBook Pros with 128GB of RAM just to run a bunch of Electron apps, hehe.
That's simply not true. "we" are misusing HTML to create applications because the tooling and distribution are so good. ReactNative / NativeScript, and probably more allow you to create apps using native or html implementations of the interface.
It's just that people start with HTML, and then it's just easy so slap Electron around it.
Think of ReactNative / NativeScript like QT/wxWidgets but they are compatible with html too
They just should help K-Mail, Evolution and Thunderbird. And provide a stable API, for “special” features. Minimal input, maximal output for all.
The Electron thing is a waste of resources for a bad application.
I assume that this app is not a mailing app, its an app to control your fastmail service, which includes email, file storage, webhosting, various dns controls, notes, contacts, billing etc. They already contributed JMAP. It would be impossible for them to get all of those features into k-mail - k-mail wouldn't want them.
And packaging the app in electron is relatively easy and a nice convenience for some users.
Once Thunderbird supports JMAP, then we should be there.
For us technical people "native" means something different than it does for regular users. It just means they have an app for their platform and not just a web app.
It's exactly that: just a web app
Most people can not differentiate between a web app in a browser and if an app they start through an icon on their computer is a wrapper around a website. People on HN who care if it’s built with Rust, Swift or an Electron app aren’t really the core audience for most companies.
It's even harder to classify as webapp if the app works offline, as electron apps often do.
Except that HN is exactly Fastmail's audience
That's a disappointment, and in the screenshots, the app actually doesn't look native at all. The new Liquid Glass design, with the round search boxes and transparency, is nowhere to be seen.
Therein lies a detraction to making native apps. Binding yourself to how native apps look now will be a liability. People will judge you as outdated when the operating system moves on to a new groove.
Sure, some work will be needed. But the Liquid Glass look starts with a recompile against the new libraries.
It's not always that simple.
That's true and I tried to acknowledge that by saying it "starts with" a recompile. There's probably a bunch of tasks that will follow.
However, now they came out with a brand-new app that shows the old OS look-and-feel.
It only says "native notifications". Or did they change the webpage?
I pay for Fastmail and I'm using the Fastmail desktop app right now.
It's much faster than Thunderbird so far for me, and more convenient than a browser tab for me, and I'm especially liking the interconnections among mail, contacts, and calendar. The best feature for me is being able to click an email link anywhere on any web page, and have it lead to the Fastmail app.
I do have two questions. The app on my macOS system is using 700MB RAM; is that for Electron? The majority of RAM is showing as GPU rendering; is that for font smoothing?
It is Electron. Sadly this is usual for Electron applications, the company saves developers and you pay with hardware. Software scales well, so investing in development would be much more efficient.
It is not strictly necessary to waste so much resources with Electron. But usually it is, because optimization also requires developer time. Even rather good Electron applications like Signal require much more resources than a native application (Gtk, Qt, Cocoa).
The right choice would be by Fastmail to cooperate directly with Evolution, Thunderbird, K-Mail, Apple Mail and help them were needed.
What makes you think they don't?
As a happy paying user of fastmail, I'm beyond saddened that they are wasting my hard-earned money in this... what, electron bundle?
There is already a fastmail desktop app. It's called thunderbird. And there are many more, for all possible tastes!
Strange that you’d feel entitled to how they spend their money. Imagine if they spent most of the money sipping pina coladas instead - would it make sense for a teetotaller to be upset about that?
You paid them for services rendered. They’ve offered an additional service they didn’t previously for no extra charge. Now you’re upset, even though you’re still getting the same service you were previously at the same price?
People sometimes pay for these things like email and search which they can get for “free” because they want to conduct business with reasonable people who will provide good custodianship of their data and be a reliable partner long term. I don’t want to have to change email provider when my next invoice comes up because they put 6 devs on building an electron app for a year. Hyperbole obviously but their actions are an important indicator of how sane and grounded management is and will continue to be into the future.
Wait, doesn’t everyone have the right to be sad about something? The company didn’t meet their expectations. What is wrong with that?
I don't think that is what they are talking about. Users can be sad. But they cannot claim ownership of a money they "spent". It is not their money anymore.
Yes, it's not communism :D
ahaha please...
As a paying user, I am also beyond saddened that companies work on features I don't use, but I realize I'm not their only customer and different people need different things.
Electron means they're not wasting your heard-earned money. They're hardly spending any of it (on the desktop app, that is).
Electron in almost every case means the user’s hard earned money is being wasted by more power consumption and more use of RAM (which increases disk I/O). Considering that it’s across many users, the hyperbolic statement would be that it’s an environmentally unfriendly option.
Or do what the rest of us have done and configure our usual clients with IMAP access.
I’d rather Fastmail ship their web client in Electron than waste engineering resources on reinventing the wheel for a client that’d get it’s own share of endless complaints from people wanting it to be more like Outlook or Thunderbird or Mutt.
I'm pretty sure the GP was talking about their subscription payments to Fastmail.
But I admit that you got me curious, do you really expect a substantial increase in power consumption due to Fastmail getting a % of their customers to run Electron instead of Thunderbird? I'm really bad at this kind of back-of-the-envelope math but I struggle to imagine that it's substantial.
Like wouldn't one kid in Nebraska playing an AAA game in anger for half an hour, on one computer, once a day, use more energy than all those electron installs combined?
Do you see a regular user researching, downloading and setting up a third party email client or is it more likely they click the download button on Fastmail and log in with their account?
That’s the beauty of open standards, everyone can choose their favorite tool for the job depending on their preferences and skill levels.
No, I see them using the web interface actually, just like they've done so up until now.
I don't think for instance this was keeping a lot of people from switching to Fastmail from let's say Gmail, which also doesn't offer a desktop client.
If Fastmail has an adoption problem it's still from people not wanting to pay for their email, a desktop app is not going to change that.
That's a lot of assumptions unless you know their internal numbers and customer feedback. I've talked to many people building products and often they themselves are surprised what's needed to get certain larger customers, even if they would never use certain features themselves.
I could very easily imagine that if a company wants to switch over their employees from another provider where the users had an app that had email / calendar /contacts all in one app that they would like to have that same setup again on Fastmail. In the end packaging their web app in a wrapper to satisfy that need of certain customers groups doesn't seem like something that should be very controversial.
Not to mention that the Fastmail client likely uses JMAP which is a million times more efficient than IMAP.
JMAP being Fastmails open source json api for email.
As a happy paying user, I am pleased they created this and have wanted a desktop app for awhile now.
> I'm beyond saddened that they are wasting my hard-earned money in this
Lol, What do you mean your hard-earned money ? You already spent your money. It is their money now. Consumer != Investor.
Your equivalent is someone going to their local grocery store and asking them to sell stop selling Avocados because they are allergic.
Spending your money on this brings them in more money which could potentially be used on features you do want.
Not certainly, because that’s not how paying a subscription works. You would have to contact them too discuss directly paying for a specific feature. But potentially!
Are there any desktop apps that support Fastmail's label implementation? Also, a Fastmail web app bundled in Electron would still be MUCH faster than Thunderbird with its bundled Mozilla components.
The should provide an API for that instead of implementing anything with Electron.
I think they do: https://www.rfc-editor.org/rfc/rfc8621.html
However, there is little movement in the desktop email app space anymore, so aside from their web app, I see no other clients supporting this.
Thanks. That’s good!
Evolution added some nifty features lately (Markdown integration). And allows to use Client-Side-Decoration annd classic menus - usability wise awesome. Thunderbird got this year a complete redesign.
The other part are we as users.
> I'm beyond saddened that they are wasting my hard-earned money in this... what, electron bundle?
Vote with your feet. Go to mailprovider with native app (and leave sane people alone)!
I think the actual question was: why would a mail provider develop their own an email client?
If it was about an email client, they wouldn’t mention Electron. Read between the lines.
Why the dislike of electron? It’s not worse than a website resource wise ..
I avoid Electron apps because in every case that I've used one, they have completely in-house UI and window management. Thunderbird is ugly as sin, I'll give you that, but, but at least it mostly let's me manage windows the way I want. Slack, on the other hand, won't even let me have tabs for two different channels. Let alone open the preferences while not navigating away from a chat I'm in the middle of.
Electron is Flash for the Desktop.
https://josephg.com/blog/electron-is-flash-for-the-desktop/
It is always better to use a well-working application with your native UI-Toolkit: The “Electron” from Signal is one of the best applications using Electron. It is fat. Even in this case people resist. Signal isn’t supporting a stable API but: https://github.com/boxdot/gurk-rsTUI :)
Electron is used, when a company wants to save on developer. All users pay with suffering from bad UI and their hardware resources. In this case it is something nobody asked for?
Thunderbird is no different than Electron apps, though. It's built on a browser engine, renders UI written in HTML + CSS (+ XUL partially), consumes ~500MB of RAM on idle, etc.
Is Thunderbird really that different bloat-wise? It also has a full browser engine inside of it.
I use Thunderbird everywhere, but I want to contribute this to the conversation: you don’t have to have your email client open all day long. I open my email client few times a day, and that’s it. I do the same with my chats, but with the chats (especially the work ones) I’m expected to reply within minutes, unfortunately. And, well, that’s another topic.
For email, I mostly don’t care whether it takes too much RAM, if the app is usable. I work with it, then I close it. That’s my workflow, at least. I believe I’m not alone in this. My iPhone is the mini server that gets all the notifications for the emails I need. (By being connected with the default email client.) So, if I want to reply from my laptop, I’ll open my app. Otherwise it’s closed.
I guess you can do that. I have my Thunderbird open 24/7 for days on end. It does seem to occupy 700MB of RAM after a while. Firefox is way worse of course... I keep Signal desktop open too, sits around 160MB.
Any website runs on Electron, Flash was a proprietary platform using proprietary tools governed by Adobe. I don't see how one can equate the two.
> Electron is Flash for the Desktop.
Flash was awesome. It was proprietary, unstable, insecure, but in other regards it was much better than competition at the time.
Electron is open-source, stable and secure (as long as you stay up to date).
You’re making a compliment.
> * Non-native UI toolkit
That’s a drawback, not a plus. You can’t easily style the app with CSS the way you want it (VSCode, Obsidian).
> * Massive waste of resources (CPU, RAM, Battery, Disk). Consumption of 500 MB RAM for idle is the norm.
Nonsense. Obsidian is sitting at 115 MB right now, zero CPU.
> * Slow.
Define slow.
> * Often issues with autonomous, local operation.
???
> * Security -> Browser Engine
The only real drawback so far. Can be mitigated by staying up to date.
> It is always better to use a well-working application with your native UI-toolkit
It is always better to use whatever works best for you and solves your problems. Not OCDing around technology and not playing identity wars with crazy people online.
> Electron is used, when a company wants to save on developer.
Also a big plus. Features are being delivered to all platforms with less money spent. Win-win.
> All users pay with suffering from bad UI and their hardware resources. In this case it is something nobody asked for?
You need to seek therapy if you’re “suffering” from application using the toolkit.
P.S. Thunderbird performs worse than ANY Electron app I’ve ever used, and I’ve been using Electron since its inception.
From the post right below:
> I do have two questions. The app on my macOS system is using 700MB RAM; is that for Electron?
Shall we discuss any of the other claims? Your security solution are constant updates?
Invests in efficiency scales with users. Most things which suck are caused by laziness and cost saving. It would be far more efficient to help either Evolution, K-Mail and Thunderbird with access to special APIs and keep them stable.
> That’s a drawback, not a plus. You can’t easily style the app with CSS the way you want it (VSCode, Obsidian).
VSCode isn't really styled with CSS if you're a user. It's done by some json or yaml. This kind of hack is required: https://marketplace.visualstudio.com/items?itemName=be5invis..., and it's clearly not supported.
You know what does have theming? Win32, GTK and QT. GTK even uses CSS for it.
And unlike electron apps, when you change how a button looks in your GTK theme it affects all GTK apps rather than just the single electron app.
> Nonsense. Obsidian is sitting at 115 MB right now, zero CPU.
I just downloaded obsidian for the first time and launching it spawns 8(!) processes using a total of 827.3 MB of RAM. That's at the launch screen, before it's doing anything.
Of course it's using no CPU when idle. That's basically the bare minimum bar for any application. It's well known that javascript is at least an order of magnitude slower than C. That's where it's wasting CPU, not when it's idle.
> Define slow.
Well to start off with, I can count the seconds obsidian takes to start up. Most native apps I have installed (other than browsers) start faster than I can reasonably react.
Typing has noticeable lag, see: https://github.com/microsoft/vscode/issues/27378
And this is on a workstation computer, I don't want to imagine how terrible the experience is on low-end hardware.
> P.S. Thunderbird performs worse than ANY Electron app I’ve ever used, and I’ve been using Electron since its inception.
Thunderbird isn't a native app either. Just like electron it's using a browser engine to show the UI.
I love Fastmail, but this feels like a waste of time. I'd rather just leave Fastmail open in a browser tab, rather than install Flatpak just to load an Electron app with the web client in it.
> I'd rather just leave Fastmail open in a browser tab
Or if you gotta have a spearate app+:
Safari > File > Add to Dock
+ which I do because it's so much easier to go to my mail instead of wading through browser windows and tabs. I've been using that way for a while now
Indeed what I do as well; gives me apps for Youtube, Netflix, etc. The only downside is that you have to login if you do not use the "app" for a while. Would Electron get around this?
> I'd rather just leave Fastmail open in a browser tab
You'll still be able to do that.
Offline mode can be useful where network connectivity is not great.
Offline mode works in a browser tab too.
yes, but not at app.fastmail.com unfortunately.
Have you tried it lately? The webworker tech they added for the browser is almost definitely why this app exists at all.
my bad, had to enable it in settings...
I've had it for a while actually. Maybe they are rolling it out slowly?
Oh... my bad ! Turns out it was disabled by default... so yes, one less reason to use the standalone app.
Understandably, as technologists we are in uproar at yet another Electron app due to the widely-accepted performance concerns many have with them. But if you don't want to run this, you can always just run it in the browser as before. Nobody is forcing you to install it.
I sometimes think we forget that Electron would have allowed them to ship this to customers super quickly, across all desktop platforms, and get a nice-looking application in to the hands of their customers (who probably have been requesting this for years).
Somehow we used to do that in the middle of 16 bit home computer mess, even when it required writing everything in Assembly.
Don't complain about Google taking over the Web, when everyone keeps packaging Chrome with their applications and calling it a native app.
> “We” (a couple of fanatics)
Internet comments are all kinda insufferable in this way, because most of what you get are complainers while the happy people stay silent. There must be a name for this phenomenon.
I don’t get the negative sentiment here. I know that as someone who uses a third party email client to use Gmail / Fastmail via manually configured IMAP I’m a very tiny minority. Most people probably use the web interface or the Gmail app on their phone.
Nothing wrong with offering an option for people who prefer a desktop app, you don’t have to feel like you are the target audience for everything.
It’s not an “app” in the traditional sense.
Just a webpage with a bundled web bowser (electron).
This is like the worst of everything. A terrible noncustomizable browser and a poor email client glued together.
This has been the standard way to distribute software across platforms for a while now. I'm not sure I understand this kind of objection anymore. What's the alternative?
Fastmail also have a decent API if you're keen to glue together a better client yourself.
Exactly! They support imap so I can use any of the zillion native, much better performing, consistent UI, email clients out there.
What does their webpage wrapped in a fairly poor, memory hungry browser get me over just going to their website in my browser?
> This is like the worst of everything. A terrible noncustomizable browser
Agree.
> and a poor email client glued together.
Totally disagree. FastMail webmail is really good, probably the best webmail/mail client.
Actually, I would use this desktop app if it was compatible with IMAP.
Agreed, Fastmail works so much better than GMail/Google Workspaces, moved my personal domains to Fastmail a while ago, and it's painful to use my work GMail during my day job...
Obsidian is an Electron app, and it's one of the best apps in the world.
Don't hate on the tech stack.
I cannot stand Obsidian because I dislike its UX so much - if it were a native app i’d use it.
There is no connection between whether an app is native or electron based and its UX so not sure why you'd bring this up. There's enough and more native apps with horrible UX and plenty of electron apps with excellent UX.
I agree. As an obsidian user, I use it _despite_ the bad UX, certainly not because of it!
Yes. I'm over the hatred for Electron too. Programmers have few options if they want cross-platform compatibility without Electron. What else are they going to use? QT? Please, give me a break. Some angelic developers like the KeepassXC guys still use QT, but that is a tough road to go down on. For the rest of them, Electron Or Bust I'm afraid.
I would unironically rather have nothing than an Electron app in most cases. They are that bad. And in this case the app doesn't even add anything of value. Literally any email application will let you do the same thing.
> I would unironically rather have nothing than an Electron app in most cases.
So let me understand something: you obviously have a free will to not use something, but you would prefer something TO NOT exist and NOT solve problems for users, because you hate the technology so much?
What is that bad about them?
Waste of disk, RAM, and CPU. Tabs in your browser at least try to share those; but no chance of that with Electron.
There are multiple cross-platform gui toolkits. What's wrong with QT?
> Using C++ for frontend (no, QML does not help)
> Licensing costs
> Atrocious DX
> Still non-native UI
No problem at all.
Using QT is complex for commerical products.
How so? I've used Qt for my commercial note-taking app[1].
[1] https://get-notes.com
Whoa. This looks very interesting. Does it support maths? Are the images stored locally? Can fonts and typography be changed? How does it differ from your open-source version which looks similar?
Thanks!
- Not yet, but adding support for Math blocks is planned.
- Yes, images are stored locally in the ~/user/.config/Awesomeness/attachments folder
- Yes, but only for pre-defined fonts. This is by design - I wanted the app to be opinionatingly simple. But since I got many requests for that, I'm gonna add an option in the settings for that.
- My FOSS version uses a simple plaintext editor (QTextEdit) with some Markdown highlighting. Daino Notes uses a block editor (a la Notion) I wrote from scratch[1] - this allows me to add complex blocks *in the middle of the documents* - so things like Kanban, Images - any custom component that I wish basically - so also math blocks, tables, etc in the future. It's also allows me to do nifty things like cool drag & drop[2] and the editor is even more performant than QTextEdit (especially on large texts).
[1] https://rubymamistvalove.com/block-editor
[2] https://rubymamistvalove.com/blog/drag_and_drop_internal.mp4
https://opensource.stackexchange.com/a/8806
In order to abide by QT's license, you have to follow the appropriate set of rules, depending on how you use it. You can use it LGPL, at which point you need to release the QT source you used and dynamically link it in your program. You can use it GPL but you have to release the source to your app. Finally, you can give QT money, and use it closed source. Okay, that wasn't that complex, but those are the rules if you want to use and distribute QT legally.
https://doc.qt.io/qt-6/licensing.html
> You can use it LGPL, at which point you need to release the QT source you used and dynamically link it in your program.
This is wrong. There's a misconception that you can't statically link your app when using the open-source LGPL version of Qt. From my reading of the LGPL license this doesn't appear to be the case[1]. The LGPL allows you to statically link your app as long as you provide the object files and allow users to relink your app with a different version of Qt.
I've observed many people spreading this misinformation about only being able to dynamically link with the LGPL version of Qt. Please stop this.
[1] https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
Why do they even need an app if they use electron?
Even discord is basically the same thing in the browser
Tauri or similar webview integrations ? Even though it is based on the OS’s native web renderer, so prone to break.
tauri sucks on linux right now because there isn't a good "system webview" available
hoping servo makes it better
I've used similar webview solutions before and they can break even on Windows (example: needing edge webview2 but not available on the user install). I get why people are pissed off by Electron but I also get why it's the de facto standard in its field.
Tauri needs to bite the bullet and bundle Chromium.
Flutter is a pretty good alternative.
Even worse performance on Web and Desktop, very good indeed.
I have many, many issues with Obsidian. It’s not a great Mac citizen. The feature set is wonderful, however.
What would make it a better Mac citizen? (aside from not using Electron)
Obsidian is tricky. I'm not sure you can actually achieve the crazy level of flexibility and custom theming without having some rough edges.
Damn your standards are low
I am already using fmail3 [1] and before that fmail2 which is also a web wrapper but feels more native to mac than Electron apps. And I think it is written in swift. So I don't know why fastmail cannot do something similar after all these years.
[1] https://fmail3.appmac.fr/
Thanks for this tip, looks much better than the electron app from Fastmail.
I find it rather strange that so many email providers have to develop their own "app".
There are so many good clients out there, and I'd rather have 1. The team focus on their core offering, and 2. the existing email client is for the same reason (limited developer time, and matureness) a much better choice for security
> I find it rather strange that so many email providers have to develop their own "app".
It's probably because people want easy access, and have all features supported flawlessly. Mail has come a long way, but there are always specific features not integrated well.
Also, most of those apps are more a thin wrapper around the web-interface, adding some interface-sugar for desktop-integration and serving as a playground for devs to test the web-apps offline-abilities.
> There are so many good clients out there, and I'd rather have 1.
I've yet to see any good client for me. They all are kinda flawed and limited, many suffering from age or not fitting modern demands. Thunderbird seems to be the only trustable Linux-compatible one which is still actively developed, and even this is app is lacking on many corners. Add-ons are supposed to fill and round up the corners, but without anyone developing them, what's the worth in having them?
Fastmail at least seems to work on developing the mail-standards, and having their own client is probably helping them in figuring out how well those improvements are working and where they are lacking.
One reason could be that they need one if there are unique differentiators on the roadmap that cannot be added into regular clients. I dont know if this is the case.
That's even more reason for fast mail to actually invest and coordinate with clients, especially with JMAP integration.
This is from August 2019
https://www.fastmail.com/blog/jmap-new-email-open-standard/
This announcement is a slap in our faces.
This is basically where I'm at. I love Fastmail, but going to the effort of trying to get JMAP standardized and then investing development effort to NOT put it in Thunderbird feels like there's no real intent to make email better for everyone, which is disappointing.
It's very practical when you use a lot of different devices. It's nice to use native built in email apps, but when using multiple different OSes and device types, it can be very annoying to have the different clients play nice with each other.
Kind of like how duckduckgo, a search engine, now has its own "app."
It’s because IMAP sucks really bad and every email service has features beyond what imap supports. Server side filters for example.
But IMAP supports server side filters?
its so they can put ads in it without you being able to block them like you can in Thunderbird.
What adverts have Fastmail put in?
Chief Product Officer of Fastmail here. I see a lot of comments here from people that don't appear to have actually tried using the app, which is a little disappointing; don't knock it 'til you've tried it! Happy to answer any questions, but to answer the main ones that are popping up:
# Why Electron?
Because it lets us build an app that works well across all major platforms with the resources we have available. Building an email/contacts/calendar app is a huge undertaking. Doing it from scratch on each platform is just not feasible for us.
With Electron, we can maintain a single code base across all platforms so we can move faster, and keep feature parity everywhere. More than that though, we believe it lets us build a really great experience on each of these platforms, while offering a consistent UI for our customers across all their devices. Honestly, we can never out-native Apple because by definition whatever they do is "native", even if it sucks (Liquid Glass on the Mac is … not great UX). If that's your primary consideration, you will always be better with Apple's own Mail app, so it's pointless us trying to build something in that space. (And instead we work to also make Fastmail the best service to use Mail.app with — which we believe it is!)
# Why would you use this instead of the webmail?
If you prefer to keep Fastmail in your browser, great! You can do so. But we hear from many customers that they would rather not have their email mixed in with their tabs. With a separate app you can see it in the dock, Cmd-tab to it, make it your default email app system wide etc. It also lets us integrate with the system, like the Mac menu bar and native context menus.
# Why would you use this instead of an IMAP client?
If you've ever used the Fastmail web interface you probably already know the answer, but for everyone else…
1. It's a lot faster. Compared to Apple's Mail.app for example (which is a good IMAP client!):
2. It's more powerful. We provide the best standards support out there, and are also working to make the standards better. But there's always going to be more that we can do when we control both the server and the client. With the Fastmail UI you can: 3. It's got much better search. (Yeah, this is kind-of just "more powerful", but I'm calling it out because search sucks in most email clients0.# And finally…
This is just a choice. We hope this is something that some of our customers will love, but we're not backing away from our commitment to open standards and encourage everyone to find what works best for them.
I'll try to answer any other questions as I can.
I appreciate you taking the time to engage with your customers here. I’ll say this announcement doesn’t thrill me, as a long-time customer. I’ve been paying for Fastmail for at least six years. It may be as many as eight but I can’t find my oldest receipt.
I use Fastmail because of the excellent mail service, customer support, sieve rules to keep my inbox manageable, and because of the little details like WebDAV that I have unexpectedly found useful for things like syncing browser bookmarks. I pay for Fastmail because it has been excellent, not because I’m captive.
This app signals to me that there may be a change coming in our relationship. One in which you may start to neglect IMAP or make it harder for me to choose my own mail client. It tells me that Fastmail might be pivoting into “growth” and treating me like a “user” rather than a paying customer. It won’t surprise me, and I can’t really say I’d be mad. Most companies get to that point. There’s probably a lot more money to be made from vendor lock-in than happy, $50 per year customers. As for me and mine, I will switch to the next small-to-medium-sized mail provider the second I get a sense that this is the direction.
I'm sorry you feel like this, but it absolutely doesn't mean that. I believe we probably devote more engineering resources to open standards development than any other company, with significant resources given to the mailmaint, calext and jmap working groups at the IETF, not to mention the maintenance of the open-source Cyrus IMAP/JMAP server. I don't know why would do that if we were trying to just keep people captive because it's hard to leave. "Your data belongs to you" is one of our core values: https://www.fastmail.com/company/values/
(You can also read more on our open source and standards work at https://www.fastmail.com/company/open-source/)
> There’s probably a lot more money to be made from vendor lock-in than happy, $50 per year customers. As for me and mine, I will switch to the next small-to-medium-sized mail provider the second I get a sense that this is the direction.
Just so you know, the next-best provider is Proton and they're in HEAVY growth mode at the moment. Their UI is strewn with upsell widgets.
In some branch of the Manyverse Kagi is working on mail hosting that will get announced in time to save me.
I would consider using this app on my desktop instead of Thunderbird primarily due to the improved search.
After giving it a spin for 180 seconds, the main nuisance for me is that I can't elect to "Always show images from this sender". I use that in other desktop clients to ensure the image blocking banner doesn't end up being subconsciously ignored by me, as it will then only show for new senders who I'm not familiar with and need to be more wary of.
Also, like all banners everywhere no matter how well designed, it's ugly. In fact to be honest... this is the main reason I want the option to get rid of it.
I can understand why you don't offer that in the web app if you're storing it server side for each customer's list of saved senders, but for a desktop app where it can be stored locally, I'd value it.
In Settings -> Mail Preferences you can choose to: * Show images by default for everyone (the images are always proxied via our CDN, so your IP is never leaked to the sender). * Show images for contacts by default. You can easily add new senders to contacts by clicking their name at the top of the email and selecting "Add to contacts".
Thanks! I checked Settings but for some reason only the Privacy/Security section where I thought this option might be. No wonder I didn't see it.
A good IMAP client (in combination with my own domains) gives me freedom. I use Fastmail, I like it, and your support is great, but I don't want to tie my usage of your service to your UI. That would tie me down to your service.
So I use Thunderbird and K-9 Mail, and occasionally the Fastmail web UI to manage masked e-mail addresses etc. That is my happy path.
I want to be tied to Fastmail because of your stellar support and good service, not because I am trained to use your UI.
By the way, fastmail.com is now in full advertising mode for this new app. It's hard for potential customers to see that you support IMAP just fine. Please show potential customers that the app is just one option as you say; not a requirement. Your website currently does not communicate that message clearly.
I can't login with my YubiKey (FIDO2/WebAuthn) on the desktop app. It works flawlessly in the browser.
Hi! I have been using Fastmail for the last 2 years and love it!
I don't use the web interface much, instead I use Apple's Mail.app. My only issue is that external email accounts (gmail) take some time to be fetched periodically. When I open the web interface and click on the tag, it instantly pulls the new mail in from the external account, but if I fetch in the Mail.app, it doesn't refresh the external accounts. So, for things that have a very short time period (confirmation codes), I still end up needing to open the web interface. I wonder if this would still be the case with the new desktop app?
I will take some time to set it up over the next days and try it out!
The desktop app will automatically pull from Gmail when you refresh the folder/label it fetches into, just like on the web.
I’ve been a long time Fastmail user and generally love the service.
I’ve got one question not about the new desktop app, but I was wondering if you’d consider adding some kind of automatic email sorting like Gmail? I feel like I’m in a constant battle marking newsletters I didn’t ask for as spam but there’s always new ones. And wish there was a feature that just automatically filtered them all in to a bucket for me.
No product plans to announce here at the moment, sorry, but we're aware there are a bunch of people that would like this.
> Because it lets us build an app that works well across all major platforms with the resources we have available. Building an email/contacts/calendar app is a huge undertaking. Doing it from scratch on each platform is just not feasible for us.
Just to be clear, does this mean the app is mainly reusing the already existing codebase of the web-app? How much additional work went into the desktop-app?
> Just to be clear, does this mean the app is mainly reusing the already existing codebase of the web-app?
Yes.
> How much additional work went into the desktop-app?
About 4 months work for 2 developers (but with both of them handling other things that arose during that time too).
I'm interested, both as a Fastmail customer, and a software developer: what does this let you do that a PWA doesn't? Perhaps not become the default email client? Is there anything else?
The main thing is better integration with the OS. So no browser chrome (even as a PWA, the browser adds buttons or a toolbar over the top of the app), integration with the Mac menu bar, native context menus, the OS semi-transparent background for the frame so it feels like it belongs.
> Why Electron?
> Because it lets us
The answer to the Electron question never starts with the customer.
I was just hoping for this a couple hours ago. :)
Any idea how far out the Linux version is?
Next day or two is my best understanding, we're just getting it onto Flathub to handle app updates.
Are there any plans to provide builds for x86 Macs?
No final decision, but possibly not. Given Apple are dropping support for x86 Macs next year, it's unlikely to be something we could support for the long term.
I think you should also understand that HN is not best place for this kind of news. This is page for people posting very obscure and hacky things. People that try to squeeze miliseconds on everything they do or do things the clever way. Why we should be happy for something that is the antitesis of clever and basically could be called corpo-slop?
> People that try to squeeze miliseconds on everything they do or do things the clever way. Why we should be happy for something that is the antitesis of clever and basically could be called corpo-slop?
Unhinged.
It is not available for linux in the download page despite the article saying otherwise.
If you want a fast small (6 MB vs 318 MB) Fastmail client, use FMail3 (https://fmail3.appmac.fr). More options than this Electron shell around a web page. Use tabs, windows, Hook and much more. JMAP API handles real quick notifications. Have a look.
I use fastmail for long time and this move is not good. Instead of investing into TB for example, they do Electron bloatapp... Will for sure never touch that thing
Why should Fastmail invest in Thunderbird, an open-source email client run by a completely unrelated organization? Of course they could, out of good will. But you can't demand that they do.
This is just their webapp wrapped in an off-the-shelf browser engine. Hardly any development resources needed. It could have been quickly put together to tick a checkbox for some big client, the revenue from whom could help them work on features that actually matter more. None of us needs to use it. But somebody must have needed it, so here it is.
> Why should Fastmail invest in Thunderbird, an open-source email client run by a completely unrelated organization?
One very good reason is that Fastmail created the JMAP protocol and while work on getting it into Thunderbird started several years ago, it hasn’t progressed. So JMAP is kinda stuck (obviously Microsoft is not going to put it in Outlook).
It could’ve been a win-win-win for JMAP, Fastmail and Thunderbird to accelerate the implementation and support for JMAP within Thunderbird. This would/could help in JMAP adoption by other mail providers too.
On the same boat as everybody else that this is electron based and not a great experience. I think from a business perspective this is just meant to satisfy those customers that are asking for a standalone app.
Does anyone know if this is Chrome in disguise?
Fastmail.app/Contents/Frameworks/Electron Framework.framework
Yes, Electron 38.2.2 at least which isn't bugged on macOS Tahoe.
If Electron is inevitable, could we make electron slimmer? We don't need backwards compatibility, and we don't need certain features from browsers. Is it even possible to compile without them ?
I am a paid user. I use Thunderbird on my desktop. This is a waste of time and money. Put the money into proper EU based data centres instead.
I know Fastmail isn't the hugest place in the world and the set of skills involved but it feels a bit insulting to roll this out rather than contribute into Thunderbird in a way to get what Fastmail feels is necessary out there.
Thunderbird has had a good number of QoL improvements, and the calendar plugins etc are quite niec. Just if one day search could... uhh... work, that would be nice
Thunderbird needs to adopt JMAP and then Fastmail will work great in it
they have an amazing team, integration with 1 pass, tons of good things and chose a shortcut like every other major company because it generates revenue, short wins over strategy
I don't hold it against them in the sense that this is the easiest stack to onboard onto, but all the recurring lost effort on native e-mail clients seem very unfortunate.
Fastmail does, of course, probably consider its UI chops etc to be part of their value add. Just seems like if they also want to win over people who like native clients then "here's a bunch of shit that makes native clients also work very well with our offerings" is less of a lift while being more helpful overall. Maybe.
The Previous Post https://www.fastmail.com/blog/not-written-with-ai/ is also worth a read :-)
I would rather have more integrations with third parties rather than this.
My main problem is that I have to put a lot of effort to not use gmail for my business because most of third-parties (like CRMs) work only/better with gmail.
Fastmail team, how about a Gmail compatible API ?
Do you mean to access Fastmail as a client for your Gmail-hosted inbox? How about using the fetch feature that moves all emails to your Fastmail inbox, and the 'send as' feature where you can send emails out from your Gmail SMTP via Fastmail. Those two features already exist.
Although when setting this up, Gmail really make you feel like they might pull support at any minute.
I wonder if Fastmail could log you in to Gmail in a way that's consistent with Google's security model, similar to how you can "log in with Google" on many services. I'd much prefer it over the app password thing.
Now that you mention it, I remember that's how Fastmail works today. They use app passwords for non-Google-hosted email inboxes, and 'login with Google' for Google-hosted inboxes.
What would be the benefit of this vs Chrome/Brave app and how does the memory consumption compare?
Just taking a glance and main benefit I'd say is offline support - which they also recently added to their mobile app.
Also being able to make it your default app for email (and hopefully calendar?)
Offline support already works in the Brave app. I've been testing it last couple of weeks.
No: offline has been supported in all modern browsers for a while now.
I was looking for this 2 days ago for a new computer setup.
I haven’t had a chance to download this yet, but hoping that it has native keybindings. (Cmd+N) on mac for composing a new email or something similar.
I know fastmail’s built in keybindings are robust, but I can’t keep track of them all.
Happy Fastmail customer for many many years, I don't want or need a desktop app.
Have a solid, well-performing web app, that's all I care about.
I don't need another desktop app...
The only thing I miss is the official API for the scheduled sending feature.
That's the only thing I would open the webpage app to do.
What does this add over using IMAP with the built-in native client?
Replying to mail that arrived through masked email addresses will also reply with the masked email address and not accidentally leak your main address.
Also creating masked mail addresses in the first place.
On the down side it's an Electron app, on the upside it's JMAP.
I use Mail on macOS, but occasionally the Fastmail web app in a browser. Here are a bunch of things I use the web app for besides configuration stuff:
- Block sender (whole domain)
- Report phishing
- Mark as spam
Because that stuff should be done on the server, not on the client and if you mark stuff as spam in Mail, it's on the client afaik.
I would hope it uses JMAP, not IMAP
Going to post the unpopular opinion here, this is also good for them purely for deployments/sales.dont forget the common denominator of "open fastmail app on your windows computer" for the tech literate.
I'm sure there was some deal that didn't get completed because of this.
Electron apps.. didn't I read something here on HN about them burning battery on OSX?
older versions that have a bug do. they are using Electron 38.2.2 which doesn't have the bugged rendering code.
OT: Does Fastmail offer search through email contents like gmail?
Yes, don't all providers? I search through my email fine.
I was considering Protonmail (have a paid subscription for many years even) but that is e2e encrypted, which means searching emails needs a local index of all emails. I have many many years of emails and several client apps. So that is not an option for me.
Therefore I wonder if this is different (‘better’) for Fastmail. It means Fastmail also can see the contents and that is ok, I just want to move away from US providers.
Fastmail servers are in the US btw
And the company is based in Australia.
They're not at the top of the list for anyone concerned about privacy
Ah yes, emails are not encrypted server-side with Fastmail, but search works.
It does. Why wouldn't it?
Yes
Is this a native client?
Electron App.
No one uses desktop apps. Maybe you should spend the engineering effort to make improvements to your phone apps. Like make it so the Android app doesn't load and then re-load every time I open it. Or support for offline mail.
May I ask how old you are? Interesting perspective to me that " no one uses desktop apps". In my bubble people only use the phone to get notified about mails, but do the interaction on a desktop computer using some mail app
Another Electron app that could have been a PWA, if PWAs were good to work with across all OSes.
If AI is really making developers so much more productive, companies should invest that productivity into offering better technical solutions. This means native applications for each platform.
I’m not a customer of Fastmail, because the laws in Australia are very anti-privacy and Fastmail is at their mercy. But my mail provider has exactly the same problem: a lame web app.
This is not a “technical person” complaint. These so-called apps look and behave worse on macOS.
First i read fairmail, now I am disappointed