Sorry-- launch day craziness :) More docs to follow soon!
They're merely implementing their own means to access email in convenient and modern way. Say, IMAP has no labels or contacts (and many other things) - there are proprietary extensions, MS Exchange being the most famous one, but they're... proprietary. And given that proprietary implementations differ, it makes sense to create an unifying wrapper.
And JS apps and web services are just an approach that's trendy today. Personally, I don't like it either, but can't blame for going with the flow. Especially since it's a business (and going against the flow has costs, both in development and adoption), not a private project where one can do things in a way that just feels right, ignoring anything else.
I believe it would absolutely make sense to bundle the "sync engine" within the mail client, though, to make it standalone. But I understand it's done this way just because there was only the engine (as a service, not a library) at the beginning.
I'm not entirely sure what's "happened with email in 10 years"? Search-defined virtual folders?
Mark Crispin was actually pretty-damned prescient when it came to IMAP: he believed that client operations should be offloaded to a server that would have much more disk space and CPU than the client, which is exactly the model everyone reaches for today, and thereby designed a thin client protocol that had asynchronous updates baked into its core. A few years ago, he passed away: here is what I wrote at the time about his mission for IMAP and history on the project.
Really, the only thing in IMAP to actively dislike is how the thin client view requires the server to have a "dense" (here I mean the mathematics term, not from the technical spec) numbering of messages the client is modeling in its view (this is the reason opening a large mailbox via Zimbra takes forever, and why many IMAP servers have dumb global locks), but I have come up with some techniques that should allow me to handle that with minimal overhead. Otherwise, with some of the modern extensions in place (QRESYNC, for example), IMAP is pretty damned awesome.
Everything you ever wanted to know about Exchange  (but were afraid to ask). I personally use SOGo  as a Exchange ActiveSync provider but I know OpenChange is a project to implement the entire Exchange stack. So I would not consider it proprietary.
Sounds like it's time for a new protocol, then. Is anything in the works?
> "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
Though I think I get why this email client and Android's Outlook  will hoover your emails to some other server - the server may have more processing power than your device. And/or use an RDBMS to index the emails which is better suited for a server than a smartphone. And that's fine - but the email client should be able to do this on it's own without the need for a server (and explicitly show a warning/message allowing you to opt-in to using the third party service). It will be slower indexing emails on your phone but that is the price you will pay.
And to be fair - I've tried almost every email client I can get my hands on: Evolution, Foxmail, Pegasus, Thunderbird, Outlook, ElementaryOS. To date no one has gotten calendar, contacts, and email better integrated than Outlook. Trust me I REALLY REALLY REALLY don't want to use Outlook - but I've yet to use an open source alternative where in 5 clicks or less I am syncing all those items previously mentioned. Thunderbird comes in second place - but I have to install 2 different extensions for contact and calendar syncing. The contact syncing has been hit/miss and the calendar syncing was stable for the most part. I should note that I don't use Exchange but I use iredadmin with SOGo.
I think SyncML was supposed to solve the whole syncing problem - but never really took off.
But why is that a problem? It's open source, someone should just package everything up into one nice downloadable desktop application.
Front-end is gorgeous. Using it to try out some ideas re: email encryption.
You are already doing this unless you run your own mailserver, or if any of your inbound/outbound emails aren't GPG encrypted (or encrypted during connections with other mail servers using TLS).
Something has to receive email for you when your computer is not running, unless you simply rely on a local mailserver, updating your MX and A records whenever your IP changes, and let other mail servers queue your email until your local desktop is back online to accept them.
"JMAP is a transport-agnostic, stateless JSON-based API for synchronising a mail client with a mail server. It is intended as a replacement for IMAP. The specification is based on the API currently used by FastMail’s web app. It aims to be compatible with the IMAP data model, so that it can be easily implemented on a server that currently supports IMAP, but also allows for reduced data usage and more efficient synchronisation, bundling of requests for latency mitigation and is generally much easier to work with than IMAP."
Seems like they've addressed at least one of your concerns, and it might actually turn out to be very simple to set up locally, so here's the privacy trade-off for not using it in your case: privacy > value || privacy > work_of_local_install
But I can see plenty of reasons the design was chosen. If you are bringing in lots of mail accounts, having it running as a daemon isn't necessarily a bad way to go. A sync program doesn't need to be associated with a tty, is better off run in the background in its own process, is arguably more extensible in design terms, doesn't necessarily take up any more memory than a regular executable, allows for multiple UIs (e.g. terminal program, Gtk+ GUI, WxWindows GUI), seperates processing from the UI, lots and lots of reasons.
Maybe the developers can step in here with a response?
You can make a UI to turn off the service or use the command prompt, if that's the concern.
If you can give me a valid technical reason running the sync part of the program as a daemon is bad, I'm definitely all ears though.