Something I’ve been wondering about.
Roundcube, RainLoop, etc are not too bad, but they’re still essentially using the same 20-year-old model as Squirrelmail: Every time you do anything (open an email, move it to another folder, etc) it opens a brand new IMAP connection, does the thing, then closes the connection. It’s kinda wasteful/slow proxying a stateful protocol over a stateless protocol like that (and yes, I know that
up-imapproxy exists, but the point still stands). Because of this implementation detail, Roundcube (and probably also RainLoop) also periodically poll the server to check for new emails, rather than using something like IMAP IDLE to push them. Polling is inefficient and outdated.
We’ve got better technology these days! We’ve had widespread support for Server-Sent Events since 2010ish and WebSockets since 2011, allowing the browser to keep a persistent connection open to the server, and the server to push stuff down to the client (with SSE) or full bi-directional communication (with WebSockets). With WebSockets in particular, the server could keep one or more IMAP connections open rather than having to open a new connection for every action taken. New emails could appear instantly and it could behave more similarly to a traditional email client. You could even just proxy the raw IMAP commands over WebSockets and have most of the logic client-side if you wanted to.
And yet… I haven’t seen any open-source email clients actually do this. I’ve been tempted to write my own modern webmail client using something better than PHP on the server-side. I think Crossbox actually does use WebSockets, but it’s not open-source so I’m not counting it here.
But why is this the case?
Is this because the current state of webmail systems is “good enough”?
Is this because of the proliferation of “enterprise” remotely-hosted email systems like G Suite, Office 365, etc? Companies that used to self-host their own webmail are now using remotely-hosted solutions, meaning webmail isn’t as popular as it used to be?