4 ms·

Interesting. I switched a little over a year ago too. I like not being the product but find the web client painful. Specifically: 1. No Send and Archive 2.

Interesting. I switched a little over a year ago too. I like not being the product but find the web client painful. Specifically: 1. No Send and Archive 2. Sending is slooow. E.g. compose email, hit Send, wait several seconds, go back to Inbox. Gmail is instantaneous. 3. Hitting Reply is SLOOOOW to bring up the Reply pane. Fastmail does a POST that takes from 500ms to 5000ms (usually on the lower end but even that is noticeable. On the rare occasion it's longer it's incredibly frustrating). 4. Replying to a message in a thread requires the mouse. In Gmail, the keyboard shortcuts will act on the highlighted message in-thread. In Fastmail the keyboard shortcuts only act on the most recent message in the thread. 5. When viewing an email that is a response to another email, Gmail collapses the initial email and lets you expand it with an ellipsis. Fastmail does no such thing, which means you need to scroll (and scroll and scroll...) when looking up through long threads 6. Search is just OK vs. Gmail, but that's not a huge surprise. In general Fastmail hasn't impressed me with the pace of development on the web app at all - the issues I had with it a year ago are still exactly the same issue I have today. I don't know how anybody who works on it and dogfoods it can't notice the speed issues every time they send an email. But it's still nice to not be the product.

llimllib 9y ago
A few years on, muting a thread is the #1 feature I miss from gmail
morganvachon 9y ago
Interesting, I've only ever run into these kinds of speed issues on the iOS client. I've found the web client (and usually the mobile client) loads a large inbox (hundreds to thousands of messages) much, much faster than Gmail; in fact, that was one of the first things in testing that told me I'd like using it. I will say that Gmail handles threading better, as you said. Fastmail goes for a more traditional native-client-like approach; it didn't take long for me to switch back to that paradigm, but someone who has only ever known Gmail would definitely see it as a pain point.
- kareemm 9y ago
  The FM web client loads messages faster, but is slower to use in my experience. I’d rather pay a one-time loading cost up front for an app experience that feels native-ish and snappy like Gmail vs having the app feel laggy when I do mainline use cases like send email or compose a reply. Re threading I’ve had email for 25 years now and def. feel Gmail’s approach is superior, if only because you don’t have to scroll so freaking much!
bgrohman 9y ago
Hmm, that’s odd. In my experience, FastMail’s web app is much faster than Gmail. I also tend to like that the FastMail web app is simple in comparison to Gmail - fewer things to slow it down or break, and few things for me to ignore :)
chrismorgan 9y ago
> 2. Sending is slooow. E.g. compose email, hit Send, wait several seconds, go back to Inbox. Gmail is instantaneous. Gmail is optimistic about it, while we’re actually sending the message before confirming to you that it’s been sent. (There are sound technical/historical reasons why it’s done the way it is; it’s not trivial to change.) Once the JMAP spec stabilises (hopefully by the next IETF meeting in March), our web UI will switch to using JMAP, and then I think that sending messages will be done in the background. Not certain, I’m not the one that’s been doing the JMAPification of the FastMail web UI. > 3. Hitting Reply is SLOOOOW to bring up the Reply pane. Fastmail does a POST that takes from 500ms to 5000ms (usually on the lower end but even that is noticeable. On the rare occasion it's longer it's incredibly frustrating). This is definitely fixed with JMAP. In a JMAP world the client takes care of creating drafts, parsing MIME messages, defanging potentially malicious HTML, &c. rather than the server as our current implementation does. > 4. […] In Fastmail the keyboard shortcuts only act on the most recent message in the thread. Not true: use n/p to focus the appropriate message (same as in Gmail), then r et al. will apply to that particular message. > 5. When viewing an email that is a response to another email, Gmail collapses the initial email and lets you expand it with an ellipsis. Fastmail does no such thing, which means you need to scroll (and scroll and scroll...) when looking up through long threads FastMail does collapse the messages that have been read. You can expand individual messages by clicking on them or pressing e (provided you’re using n/p to switch between them), or Shift+e to expand all (Alt+Shift+e collapses all). In consequence of these things, I’m not sure what the issue you’re pointing out is; if you can provide more info we can look into improving it. You may find it helpful to look at https://www.fastmail.com/help/receive/kbshortcuts.html https://www.fastmail.com/help/receive/kbshortcuts.html. --- For web UI work, we’ve been focusing on Topicbox and JMAP this year rather than FastMail; Topicbox has been a simpler staging ground for various improvements that we intend to bring to FastMail (mostly internal tooling stuff—I’ll be writing a bit about it later in our Advent series), and JMAP will enable various long-desired features (e.g. snooze, delayed/undo send). Next year will see more effort put into the FastMail web UI; my favourite item that we have planned (and I called dibs on implementing most of it!) is service workers for offline support and substantially improved performance (building on top of JMAP’s improvements).
- abrowne 9y ago
chrismorgan 9y ago
I whipped up a quick implementation of Send & Archive for fun which you can hook up with something like Greasemonkey: O.require(['mail', 'compose'], function () { const composeController = FastMail.mail.screens.compose; const mailActions = FastMail.mail.actions; const mailToolbar = FastMail.views.mailToolbar; mailToolbar.registerView('sendArchive', new O.ButtonView({ type: 's-send', icon: 'icon-paper-plane', _isSending: O.bind(composeController, 'instance.isSending'), _mayMove: O.bind(mailActions, 'mayMove'), isDisabled: function () { return this.get('_isSending') || !this.get('_mayMove'); }.property('_isSending', '_mayMove'), label: O.loc('Send & Archive'), target: { doIt: function () { composeController.fire('send'); mailActions.archive(); } }, method: 'doIt', shortcut: 'cmd-shift-enter', // (Fairly arbitrarily chosen.) })); const config = O.clone(mailToolbar._configs.compose); config.left.splice(config.left.indexOf('send'), 0, 'sendArchive', '-'); mailToolbar.registerConfig('compose', config); }); It’s not elegant, but it works. It’ll probably break when the web UI switches to JMAP some time next year.

llimllib 9y ago

A few years on, muting a thread is the #1 feature I miss from gmail

morganvachon 9y ago

Interesting, I've only ever run into these kinds of speed issues on the iOS client. I've found the web client (and usually the mobile client) loads a large inbox (hundreds to thousands of messages) much, much faster than Gmail; in fact, that was one of the first things in testing that told me I'd like using it. I will say that Gmail handles threading better, as you said. Fastmail goes for a more traditional native-client-like approach; it didn't take long for me to switch back to that paradigm, but someone who has only ever known Gmail would definitely see it as a pain point.

kareemm 9y ago
The FM web client loads messages faster, but is slower to use in my experience. I’d rather pay a one-time loading cost up front for an app experience that feels native-ish and snappy like Gmail vs having the app feel laggy when I do mainline use cases like send email or compose a reply. Re threading I’ve had email for 25 years now and def. feel Gmail’s approach is superior, if only because you don’t have to scroll so freaking much!

bgrohman 9y ago

Hmm, that’s odd. In my experience, FastMail’s web app is much faster than Gmail. I also tend to like that the FastMail web app is simple in comparison to Gmail - fewer things to slow it down or break, and few things for me to ignore :)

chrismorgan 9y ago

> 2. Sending is slooow. E.g. compose email, hit Send, wait several seconds, go back to Inbox. Gmail is instantaneous. Gmail is optimistic about it, while we’re actually sending the message before confirming to you that it’s been sent. (There are sound technical/historical reasons why it’s done the way it is; it’s not trivial to change.) Once the JMAP spec stabilises (hopefully by the next IETF meeting in March), our web UI will switch to using JMAP, and then I think that sending messages will be done in the background. Not certain, I’m not the one that’s been doing the JMAPification of the FastMail web UI. > 3. Hitting Reply is SLOOOOW to bring up the Reply pane. Fastmail does a POST that takes from 500ms to 5000ms (usually on the lower end but even that is noticeable. On the rare occasion it's longer it's incredibly frustrating). This is definitely fixed with JMAP. In a JMAP world the client takes care of creating drafts, parsing MIME messages, defanging potentially malicious HTML, &c. rather than the server as our current implementation does. > 4. […] In Fastmail the keyboard shortcuts only act on the most recent message in the thread. Not true: use n/p to focus the appropriate message (same as in Gmail), then r et al. will apply to that particular message. > 5. When viewing an email that is a response to another email, Gmail collapses the initial email and lets you expand it with an ellipsis. Fastmail does no such thing, which means you need to scroll (and scroll and scroll...) when looking up through long threads FastMail does collapse the messages that have been read. You can expand individual messages by clicking on them or pressing e (provided you’re using n/p to switch between them), or Shift+e to expand all (Alt+Shift+e collapses all). In consequence of these things, I’m not sure what the issue you’re pointing out is; if you can provide more info we can look into improving it. You may find it helpful to look at https://www.fastmail.com/help/receive/kbshortcuts.html https://www.fastmail.com/help/receive/kbshortcuts.html. --- For web UI work, we’ve been focusing on Topicbox and JMAP this year rather than FastMail; Topicbox has been a simpler staging ground for various improvements that we intend to bring to FastMail (mostly internal tooling stuff—I’ll be writing a bit about it later in our Advent series), and JMAP will enable various long-desired features (e.g. snooze, delayed/undo send). Next year will see more effort put into the FastMail web UI; my favourite item that we have planned (and I called dibs on implementing most of it!) is service workers for offline support and substantially improved performance (building on top of JMAP’s improvements).

abrowne 9y ago

chrismorgan 9y ago

I whipped up a quick implementation of Send & Archive for fun which you can hook up with something like Greasemonkey: O.require(['mail', 'compose'], function () { const composeController = FastMail.mail.screens.compose; const mailActions = FastMail.mail.actions; const mailToolbar = FastMail.views.mailToolbar; mailToolbar.registerView('sendArchive', new O.ButtonView({ type: 's-send', icon: 'icon-paper-plane', _isSending: O.bind(composeController, 'instance.isSending'), _mayMove: O.bind(mailActions, 'mayMove'), isDisabled: function () { return this.get('_isSending') || !this.get('_mayMove'); }.property('_isSending', '_mayMove'), label: O.loc('Send & Archive'), target: { doIt: function () { composeController.fire('send'); mailActions.archive(); } }, method: 'doIt', shortcut: 'cmd-shift-enter', // (Fairly arbitrarily chosen.) })); const config = O.clone(mailToolbar._configs.compose); config.left.splice(config.left.indexOf('send'), 0, 'sendArchive', '-'); mailToolbar.registerConfig('compose', config); }); It’s not elegant, but it works. It’ll probably break when the web UI switches to JMAP some time next year.