I've been doing some research myself for an offline-first project I've been thinking about, so it's great to see more people going in this direction!
A project I recently discovered in this realm is `wa-sqlite`. Yet another sqlite browser web assembly project, but it has VFS adapter examples that introduced me to the OPFS which, at least on a surface level, seems to be faster but more complicated than using indexeddb, and is a whole other avenue the article didn't explore. I'm guessing because it's still new/experimental and they're trying to build their thing yesterday
I am very confused as to what this is trying to claim... it says it is "IMAP-based, not API-based", and yet it is clearly running its own sync solution, including to web browsers.
Marco is essentially a direct competitor to Superhuman.
However, Superhuman and almost all other products in this space integrate with providers solely via API (like the Gmail API). This means almost all "modern" email products only support Gmail, and perhaps Microsoft if you're lucky.
We've opted to integrate at the IMAP level to allow maximum interop.
There must be some functionality trade-offs that come in to the picture here. What do you see as the key downsides of using the IMAP approach rather than integrating with email providers via their APIs?
Good question.
There are no pure "functionality" trade-offs. IMAP _is_ the defacto email protocol and supports everything that email "does".
There are, however, _massive_ implementation trade-offs. The reason almost all email products use APIs instead of IMAP is: IMAP is really hard. Orchestrating and abstracting over IMAP for cross-platform usage is insanely hard.
IMAP is antiquated and fundamentally broken. It has race hazards built in, poor querying performance, etc.
JMAP is supposed to be the successor to IMAP, but it's been around for over a decade and the world still runs on IMAP.
We want to build a multi-account, cross-platform, offline-first email app that _just works_. The project was born out of personal frustration. We're not trying to do anything revolutionary. We're building the email app that should have already existed.
That makes sense.
Do you have a way to limit how much space you use on the user’s device? I hate the Mac/iOS Mail apps which I’m using now because they download gigabytes and gigabytes of emails from forever ago and slurp up all my disk space. Especially with an offline first app, that would be a concern for me.
Another great question, and something we've been pondering deeply in recent weeks.
Our current iteration of Marco stores full and complete _metadata_, but not message bodies or attachments.
This means we can do rudimentary full-text search, filtering, sorting, etc over your entire corpus of email content.
Full-text search in particular is incredibly compelling. Imagine having ~2ms search results for every email account you own. That is the current Marco performance.
In addition to that, Marco optimistically preloads messages bodies. This means that in practice, when opening an email you should see content load instantly. Any email you open will be cached offline in a LIFO stack.
Despite all of this, we're hyper aware of not overreaching in terms of disk space. For example, my personal email address is ~10GB according to the Gmail storage dashboard, but compresses to ~140MB of metadata, indices, and cached message bodies within Marco.
We will very likely expose storage settings/limits in the longer term future.
Cool! I’m on the waitlist, look forward to testing it out!
I've been doing some research myself for an offline-first project I've been thinking about, so it's great to see more people going in this direction!
A project I recently discovered in this realm is `wa-sqlite`. Yet another sqlite browser web assembly project, but it has VFS adapter examples that introduced me to the OPFS which, at least on a surface level, seems to be faster but more complicated than using indexeddb, and is a whole other avenue the article didn't explore. I'm guessing because it's still new/experimental and they're trying to build their thing yesterday
I am very confused as to what this is trying to claim... it says it is "IMAP-based, not API-based", and yet it is clearly running its own sync solution, including to web browsers.
Marco is essentially a direct competitor to Superhuman.
However, Superhuman and almost all other products in this space integrate with providers solely via API (like the Gmail API). This means almost all "modern" email products only support Gmail, and perhaps Microsoft if you're lucky.
We've opted to integrate at the IMAP level to allow maximum interop.
There must be some functionality trade-offs that come in to the picture here. What do you see as the key downsides of using the IMAP approach rather than integrating with email providers via their APIs?
Good question.
There are no pure "functionality" trade-offs. IMAP _is_ the defacto email protocol and supports everything that email "does".
There are, however, _massive_ implementation trade-offs. The reason almost all email products use APIs instead of IMAP is: IMAP is really hard. Orchestrating and abstracting over IMAP for cross-platform usage is insanely hard.
IMAP is antiquated and fundamentally broken. It has race hazards built in, poor querying performance, etc.
JMAP is supposed to be the successor to IMAP, but it's been around for over a decade and the world still runs on IMAP.
We want to build a multi-account, cross-platform, offline-first email app that _just works_. The project was born out of personal frustration. We're not trying to do anything revolutionary. We're building the email app that should have already existed.
That makes sense.
Do you have a way to limit how much space you use on the user’s device? I hate the Mac/iOS Mail apps which I’m using now because they download gigabytes and gigabytes of emails from forever ago and slurp up all my disk space. Especially with an offline first app, that would be a concern for me.
Another great question, and something we've been pondering deeply in recent weeks.
Our current iteration of Marco stores full and complete _metadata_, but not message bodies or attachments.
This means we can do rudimentary full-text search, filtering, sorting, etc over your entire corpus of email content.
Full-text search in particular is incredibly compelling. Imagine having ~2ms search results for every email account you own. That is the current Marco performance.
In addition to that, Marco optimistically preloads messages bodies. This means that in practice, when opening an email you should see content load instantly. Any email you open will be cached offline in a LIFO stack.
Despite all of this, we're hyper aware of not overreaching in terms of disk space. For example, my personal email address is ~10GB according to the Gmail storage dashboard, but compresses to ~140MB of metadata, indices, and cached message bodies within Marco.
We will very likely expose storage settings/limits in the longer term future.
Cool! I’m on the waitlist, look forward to testing it out!