I perceive that you haven’t ever tried programming against IMAP or making a MUA, or not seriously at least.
IMAP is a mess if you try to do much beyond the basic “retrieve list of folders, retrieve messages, now just leave it alone”; and most IMAP client libraries are worse than IMAP need be. There are many extensions for many features, poorly supported in various clients and servers, and various things that are slow, difficult, or impossible to do in IMAP that JMAP can express elegantly. http://jmap.io/#why-is-jmap-better-than-imap lists a few reasons. Bugs in clients or servers that cause data loss over IMAP are not unheard of.
IMAP is also only one part of the app: one of the hardest parts is MIME, and figuring out what to show for an email and how to craft an email; there are fewer libraries to do this than there are IMAP clients—and almost none that are any good. (You’ll find some that do the plain parsing of most of the message, but how do I decide what to do with multipart/alternative, multipart/mixed, text/plain, Content-Disposition, Content-Encoding, &c. is answered by no library that I know of.) JMAP doesn’t solve all these problems, but it handles most of them by handing you a sanely parsed message (putting the burden of sanity on the server, and the spec provides good guidance and there’s a JMAP test suite being made to ensure the sanity of the server): things like exposing To, Cc, &c. as lists of addresses; and fields like preview, htmlBody, textBody and attachedFiles to save you the trouble of deriving the crazy convoluted rules of multipart messages. You can send messages without having to implement SMTP and grok MIME, too.
For authors of existing MUAs, JMAP doesn’t have much to offer by this stuff from the last paragraph—they’ve already done the hard slog. But for authors of new MUAs and other programs that might want to do email at all—sending or receiving—JMAP really is “all that”.
Some of the experiments that I’m looking forward to seeing won’t look like existing MUAs at all. They’ll be other things altogether that just happen be able to send or receive emails directly, now, because it’s finally easy enough to.
IMAP is not particularly well suited to being used as a purely-online client with no local storage or persistent cache. You can do it, and many clients have over the years, but you will sacrifice a lot, like the ability to search multiple folders efficiently. We couldn’t make something like the FastMail web UI speaking IMAP; it just wouldn’t work in too many places. JMAP, on the other hand, is designed to work in such a situation, and suffers from few of those sorts of shortcomings. Sure, you’ll probably want to introduce offline support and may want to reimplement search on the client somewhere down the track, but it’s not necessary-work-that-must-be-done-before-the-client-is-generally-useful like it is in IMAP.
JMAP allows you to get started quickly and efficiently. Because it speaks HTTP and JSON and is deliberately designed as a synchronisation protocol, and because it lacks the cruft of decades of fragmented extension that IMAP has¹, JMAP is really easy to work with. Even things like synchronisation and notifications come at very low cost even without a library, especially if you are running in a web browser.
Don’t forget that JMAP replaces IMAP and SMTP for the MUA. And having only one thing to configure and get right, with a standard configuration procedure (SRV and .well-known, so that you can just provide an email address and it’ll figure out the rest) instead of two with no consistently applied configuration procedure is a surprisingly big deal for users.
The talk that I plan will be predominantly live coding, starting from scratch—no frameworks at all—and building a basic but functional MUA in half an hour. You really can’t do that in IMAP/SMTP, but you can in JMAP², and it genuinely gets better beyond there.
I have no interest in making a realistic MUA with IMAP/SMTP, because I know that I would spend weeks on the groundwork, to produce a result that is strictly inferior to what I am confident I can produce in an hour with only a general understanding of the JMAP spec, and access to the JMAP core and mail spec docs.
Oh yeah, I just remembered another absolutely massive thing about JMAP, though the dust has not yet fully settled—calendars and contacts. Because this IMAP/SMTP MUA estimate of mine just went up by a couple of months to handle them for some ESPs, whereas with JMAP that groundwork will take maybe another whole hour.
Seriously, JMAP is a big deal.
---
¹ For now, and it has a more thoughtful design to future extension so that it will avoid some of the troubles of aging.
² I’m delicately ignoring the matter of authentication here, which is omitted from the JMAP spec, and assuming something really basic.
"I perceive that you haven’t ever tried programming against IMAP or making a MUA, or not seriously at least."
Unfortunately for you, your perception is wrong. Writing an IMAP client library is my go-to project when I'm learning a new network stack / language. I am very familiar with the way it works and it's various problems, and have been paid to write software that uses it.
I am not as familiar with JMAP, but I did look into it a year or so ago. I recall at the time that it didn't seem to solve that many problems, and introduced problems that I never previously had when working with IMAP. I triggered a discussion on the IETF mailing list regarding one of these problems (https://mailarchive.ietf.org/arch/msg/jmap/7dSQsqRBJ_YlZ7wF8...). Somebody said at the time that they would look into modifying the protocol to address that problem, but to me (and I could be wrong) it looks like this hasn't happened.
My basic perspective on JMAP is: It doesn't fix enough problems to justify the massive increase in pain it would cause developers of mail clients by having to support both IMAP and JMAP at the same time. I'm totally on-board with replacing IMAP with something better. But it needs to be a lot better, or we should just stick with IMAP. To me, JMAP just looks like it will cause more problems than it solves.
(Yes: I have personally implemented IMAP, and SMTP, and in fact even Seieve, all from scratch. No: I did not find writing a fully compliant parser difficult, and I have no sympathy for people who seem incapable of writing one.)
> You can do it, and many clients have over the years, but you will sacrifice a lot, like the ability to search multiple folders efficiently.
By "folders", I will assume you mean "mailboxes" (as that is how most, if not all, existing clients and servers choose to represent "folders"). This was addressed in RFC 7377. I realize that you will argue "but what servers actually implemented that?", but the answer is "probably more than have decided to implement JMAP".
That said, JMAP has chosen to unify labels and folders into a term "mailboxes". The same solution applies to IMAP: I think a more correct usage of IMAP is to unify labels and folders into what IMAP calls "flags" (as opposed to what IMAP calls "mailboxes") at which point I think you will find that 90% of the struggles people have with IMAP disappear.
I realize that no IMAP server does this, but that is for historical reasons related to how mail was stored on disk and I think totally ignores what makes IMAP as a protocol interesting. I honestly feel like a lot of people just never took the time to understand either IMAP (or Mark Crispin) (or how to quickly write a parser :/) and then spent decades complaining about the annoying and limited ways people mapped semantics.
That all said, I would at least begrudgingly agree that for some simple use cases, JMAP is likely convenient for certain classes of mail consuming systems. But come on... to try to claim that IMAP is somehow not designed for online usage or is somehow broken for that usage is such a totally disingenuous claim that I will go so far as to say that it outright slanders the memory of Mark Crispin, who seriously seemed to believe people writing offline email clients with persistent caches that required synchronization were embarking on a "fools errand", and (for better or for worse) effectively assumed servers would always be better than local hardware.
Last time I was working on a MUA (which was admittedly a long time ago), within about 3 days I ended up submitting a patch upstream for Ruby's Net::IMAP. It's a fiddly protocol, and there's a lot of ways to get things wrong.
I, too, am quite excited about JMAP, although I have my doubts about ever trying to write an MUA ever again.
IMAP is a mess if you try to do much beyond the basic “retrieve list of folders, retrieve messages, now just leave it alone”; and most IMAP client libraries are worse than IMAP need be. There are many extensions for many features, poorly supported in various clients and servers, and various things that are slow, difficult, or impossible to do in IMAP that JMAP can express elegantly. http://jmap.io/#why-is-jmap-better-than-imap lists a few reasons. Bugs in clients or servers that cause data loss over IMAP are not unheard of.
IMAP is also only one part of the app: one of the hardest parts is MIME, and figuring out what to show for an email and how to craft an email; there are fewer libraries to do this than there are IMAP clients—and almost none that are any good. (You’ll find some that do the plain parsing of most of the message, but how do I decide what to do with multipart/alternative, multipart/mixed, text/plain, Content-Disposition, Content-Encoding, &c. is answered by no library that I know of.) JMAP doesn’t solve all these problems, but it handles most of them by handing you a sanely parsed message (putting the burden of sanity on the server, and the spec provides good guidance and there’s a JMAP test suite being made to ensure the sanity of the server): things like exposing To, Cc, &c. as lists of addresses; and fields like preview, htmlBody, textBody and attachedFiles to save you the trouble of deriving the crazy convoluted rules of multipart messages. You can send messages without having to implement SMTP and grok MIME, too.
For authors of existing MUAs, JMAP doesn’t have much to offer by this stuff from the last paragraph—they’ve already done the hard slog. But for authors of new MUAs and other programs that might want to do email at all—sending or receiving—JMAP really is “all that”.
Some of the experiments that I’m looking forward to seeing won’t look like existing MUAs at all. They’ll be other things altogether that just happen be able to send or receive emails directly, now, because it’s finally easy enough to.
IMAP is not particularly well suited to being used as a purely-online client with no local storage or persistent cache. You can do it, and many clients have over the years, but you will sacrifice a lot, like the ability to search multiple folders efficiently. We couldn’t make something like the FastMail web UI speaking IMAP; it just wouldn’t work in too many places. JMAP, on the other hand, is designed to work in such a situation, and suffers from few of those sorts of shortcomings. Sure, you’ll probably want to introduce offline support and may want to reimplement search on the client somewhere down the track, but it’s not necessary-work-that-must-be-done-before-the-client-is-generally-useful like it is in IMAP.
JMAP allows you to get started quickly and efficiently. Because it speaks HTTP and JSON and is deliberately designed as a synchronisation protocol, and because it lacks the cruft of decades of fragmented extension that IMAP has¹, JMAP is really easy to work with. Even things like synchronisation and notifications come at very low cost even without a library, especially if you are running in a web browser.
Don’t forget that JMAP replaces IMAP and SMTP for the MUA. And having only one thing to configure and get right, with a standard configuration procedure (SRV and .well-known, so that you can just provide an email address and it’ll figure out the rest) instead of two with no consistently applied configuration procedure is a surprisingly big deal for users.
The talk that I plan will be predominantly live coding, starting from scratch—no frameworks at all—and building a basic but functional MUA in half an hour. You really can’t do that in IMAP/SMTP, but you can in JMAP², and it genuinely gets better beyond there.
I have no interest in making a realistic MUA with IMAP/SMTP, because I know that I would spend weeks on the groundwork, to produce a result that is strictly inferior to what I am confident I can produce in an hour with only a general understanding of the JMAP spec, and access to the JMAP core and mail spec docs.
Oh yeah, I just remembered another absolutely massive thing about JMAP, though the dust has not yet fully settled—calendars and contacts. Because this IMAP/SMTP MUA estimate of mine just went up by a couple of months to handle them for some ESPs, whereas with JMAP that groundwork will take maybe another whole hour.
Seriously, JMAP is a big deal.
---
¹ For now, and it has a more thoughtful design to future extension so that it will avoid some of the troubles of aging.
² I’m delicately ignoring the matter of authentication here, which is omitted from the JMAP spec, and assuming something really basic.