Email is simple the way a plane is simple. As long as you don't see all the moving parts, and get to go along for the ride, it just seems like a magical flying tube!
I spent about 18 months on an email client project (was already 3 years in when I joined the team). I can tell you email is insane... so much more broken than you would expect (on all sides).
There is a reason many clients do "gmail" instead of "email". "Email" is a nasty barely functional ball of duct tape greased with WD-40 in the places it needs to go fast -- the fact that it works at all is breathtaking and only explained by the fact that it is one of the "killer features" of the internet.
The number of broken clients and servers is shocking and breathtaking. So you have to accept and expect bad data from everywhere. From the server directly, violating the imap spec, and in the body of the message violating all sanity. Yet, your users will see any failure as "this email client sucks" because the OTHER older email clients have already seen this idiocy and custom coded around it. Email clients end up being giant laundry lists of "if <stupid server> (act way 1)", "if created with <stupid client> (render 'right' way 2)"...
The reason new email clients are relatively slow to be created, and even fewer take off, is they are forced to deal with an insane clusterfuck of standards and corner cases to get to that 80% good enough mark -- or simply build out to one service at a time (we support gmail, hotmail and yahoo... etc).
There are 20+ RFCs you need to deal with the cover the spectrum of "basic" email with calendaring across a number of servers. That is just the "good" standard parts. On top of that you have the hundreds of server oddities that you need to handle else your email client will fail to get email off broken server X. Add to that the hundreds of rendering special cases you need to be aware of (ohh, this game from old outlook, so X means Y).
After you do all that, you have to deal with spam (both how servers tell you about it, how you show it, how you maintain it, etc) and an entire new set of oddities (very similar but simpler) for sending mail.
FastMail has an idea floating around that appears less terrible: http://jmap.io/ -- but I am blissfully out of that industry and simply don't care anymore.
EDIT: For the record, I agree with the article, email will be around for a long time, it is the "point of record" -- many of the "email killers" require your email address to sign up... so...
Looks interesting. IMAP is a pain! We spent months trying to get really simple stuff working for a mail client we're building (http://www.sortd.com). Actually, to be accurate it runs inside Gmail because it's more of a way to manage email rather than a standalone client, but we still need to connect to the mailbox itself via IMAP. Started using context.io, which was useful, but they went kind of wayward from their original vision.
What about performance though? Things like search are almost just not viable with IMAP - WAY too slow - we find ourselves having to hack the Gmail DOM to do things we should be able to do directly via the mailbox.
Seems to me that IMAP needs to be updated or replaced. What do you think of the new Gmail API?
Wow, how long have you guys existed? I am shocked I didn't know about this product. That is IMHO, EXACTLY the product that has needed to be built for awhile. Get all those eccentricities into one library that provides a clean interface.
We announced this a couple of months ago, though the company has been around for a while. We're also just quieter than most startups. Less blogging and talk, more code. :)
I spent about 18 months on an email client project (was already 3 years in when I joined the team). I can tell you email is insane... so much more broken than you would expect (on all sides).
There is a reason many clients do "gmail" instead of "email". "Email" is a nasty barely functional ball of duct tape greased with WD-40 in the places it needs to go fast -- the fact that it works at all is breathtaking and only explained by the fact that it is one of the "killer features" of the internet.
The number of broken clients and servers is shocking and breathtaking. So you have to accept and expect bad data from everywhere. From the server directly, violating the imap spec, and in the body of the message violating all sanity. Yet, your users will see any failure as "this email client sucks" because the OTHER older email clients have already seen this idiocy and custom coded around it. Email clients end up being giant laundry lists of "if <stupid server> (act way 1)", "if created with <stupid client> (render 'right' way 2)"...
The reason new email clients are relatively slow to be created, and even fewer take off, is they are forced to deal with an insane clusterfuck of standards and corner cases to get to that 80% good enough mark -- or simply build out to one service at a time (we support gmail, hotmail and yahoo... etc).
There are 20+ RFCs you need to deal with the cover the spectrum of "basic" email with calendaring across a number of servers. That is just the "good" standard parts. On top of that you have the hundreds of server oddities that you need to handle else your email client will fail to get email off broken server X. Add to that the hundreds of rendering special cases you need to be aware of (ohh, this game from old outlook, so X means Y).
After you do all that, you have to deal with spam (both how servers tell you about it, how you show it, how you maintain it, etc) and an entire new set of oddities (very similar but simpler) for sending mail.
FastMail has an idea floating around that appears less terrible: http://jmap.io/ -- but I am blissfully out of that industry and simply don't care anymore.
EDIT: For the record, I agree with the article, email will be around for a long time, it is the "point of record" -- many of the "email killers" require your email address to sign up... so...