[erinaceousjones]

JMAP does solve the same problems, and then some -- looking at the specs, it's more of a 1:1 mapping between IMAP+SMTP. I'd say that if you're looking at implementing _all the functionality of a modern email client_ you might want to look at that. If your use-case is just wanting to fetch emails from a bunch of inbox folders in real-time, potentially with some querying/filtering, I'd say JMAP is a bit overwhelming. Sure, it has some clients/libraries available, but only a few.

imapapi, in my opinion, being a RESTful API, appears to have a much simpler surface, seems easier to play with using curl, and if you're developing a bunch of RESTful services that use Swagger, it fits better with your stuff. So, less dev-time to use :-)

[josephg]

JMAP is definitely more complicated, but that complexity enables some very useful features. You can search, you can fetch emails by thread. You can get text snippets of emails for preview. JMAP can also automatically convert any email into directly renderable HTML (or plain text).

I’m convinced if nothing else the jmap json format is what everyone should be using for passing around email objects since it’s so well designed and feature rich. Almost all hand rolled email json formats throw away data you really want when rendering or processing email messages.

IMAP api does look lovely though.

[rmccue]

I tried using the JMAP bridge to develop a modern client as you mention, but there were huge problems with it. It appears to be abandoned, and Fastmail’s demo install of it is entirely broken too.

I ended up using the underlying lib that this project uses (also by andris9) and have had basically no problems whatsoever, it was a night and day difference.

[inputmice]

> If your use-case is just wanting to fetch emails from a bunch of inbox folders in real-time, potentially with some querying/filtering,

Nobody says you need to implement all of JMAP (from a client perspective). Just implement Email/query Email/get