
Proposal to start a new implementation of Thunderbird based on web technologies - rxlim
https://mail.mozilla.org/pipermail/tb-planning/2017-March/005298.html
======
cakeface
Does anyone actually have any problems with Thunderbird? I feel like it is
"done" software. It works, perfectly, for all my needs. It's fast. It has
great UI. It lets me read and write email.

~~~
CJefferson
The search is unusable -- wedding finds 'weds'. There is no way to do exact
searching. I reported this 5 years ago, lots of other people have complained
about the stemming, there has been no fix.

There is no support for outlook/exchange. Not saying it's trivial, but it's
useful in the modern era.

IMAP folder support is very flakey, I reported some bugs but nothing got
fixed.

~~~
losteric
It sounds like search needs a patch bounty, but it would be ridiculous to
rewrite Thunderbird because search is naively implemented.

I've never had problems with IMAP, nor do I use Exchange, so I can't speak to
those...

~~~
mdaniel
And thankfully, there's a Lucene-in-C (which I haven't personally had a need
to use, but Lucene as a project is __awesome __), so the patch might not even
be terribly large unless their current search implementation is splattered all
over the app

[https://lucy.apache.org](https://lucy.apache.org)

------
sidlls
"JavaScript is the best choice."

(Citation Needed).

This proposal identifies serious legitimate concerns with Thunderbird
development going forward, but the proposed solution looks more like a hammer
seeking a nail than a thoughtful approach to addressing the concerns.

~~~
phkahler
Yeah, I cringed at the JS thing. Why not do it in Rust and start with some of
the Servo code as a base? That would give the developers an intermediate
application to work with that doesn't require the full capability of a web
browser.

~~~
lloeki
The whole tirade read like a thinly veiled "building an Electron-based MUA is
just easier by now", which is a thing I've been contemplating toying with
because, to paraphrase another well-known MUA, all those desktop email
clients† flat out suck and the best ones are barely above the tolerable
threshold.

> Why not do it in Rust and start with some of the Servo code as a base?

Thought about it, but I think Servo might just not be _that_ ready yet given
the expected timeframe. Could be of a great synergy and a nice real-life
testbed for Servo though.

† I've extensively used a lot on various OSes, from Claws to Gmail (web) to
mutt to Mail.app to Eudora to Fastmail (web) to Outlook to AirMail. For _none_
of them could I ever say "nailed it" and while some do have their pluses
they're all broken one way or another which brings the whole package down.

~~~
juliangoldsmith
You say that desktop email clients all suck. Is there a web-based client that,
in your opinion, doesn't?

------
nkkollaw
They've already neglected Thunderbird for years, and now they want to start
from scratch? Doesn't sound like a good idea. Sounds more like another project
they will shut down after a while.

I used to use both Thunderbird and Firefox a few years ago as my main mail
client and browser. Since then, Mozilla started spreading between too many
projects, chasing the failed phone thing, and both Firefox and even worse
Thunderbird are nowhere near where their competitors are.

I now use Google Chrome and Google Inbox (via Electron app Wavebox, formerly
WMail), and they actually look from this century. I downloaded Thunderbird a
few months ago out of nostalgia, and everything looks the same as 5 years ago.
Pretty sad.

~~~
orthecreedence
I think Thunderbird is fine how it is. I think a lot of the projects Mozilla
takes on are stupid (Rust being a giant exception, I love Rust).

You know what I want? NWJS/Electron but using Firefox/Spidermonkey. I want to
package desktop apps with Firefox. They almost had this with xulrunner but
killed it for some reason. And I want them to build crosswalk
([https://crosswalk-project.org/](https://crosswalk-project.org/)) for mobile,
but with Firefox. The only real reason is that I don't trust Google or
anything they touch, and I've never actually been able to build Chromium/NWJS
from source (such a complicated build), which worries me.

Call me paranoid, but the monoculture around Chromium creeps me out and I'd
really like a viable alternative from Mozilla. Seems like they jumped ship
from the packaged HTML5 desktop/mobile app paradigm _right_ when it started
getting popular.

~~~
jcranmer
There actually was a fork of node.js that used SpiderMonkey.

IMHO, one of Mozilla's greatest failures was its decision to more or less give
up on embedding (for both SpiderMonkey and Gecko). They effectively killed off
embedding in the process of moving to the train model back in 2011, 2012, but
back then, the expectation was that they would have their 2 years of "let's
kill our broken architecture." Instead, it sort of ended up dragging on how
long it would take them to stabilize some APIs for embedding, and they
certainly never bothered to try to maintain any documentation (I briefly
attempted to maintain some client application that used SpiderMonkey in 2011,
and it was a headache trying to find any sort of documentation on how to fix
each incremental bustage, since everything that was found on MDN was woefully
out of date).

First, there was to be some sort of IPC-based embedding mechanism in Gecko.
Then that idea was nixed in favor of just XULRunner. Then Mozilla decided it
didn't want to maintain XULRunner anymore. For a period of time, they had a
XULRunner-like setup called something like webapprt (which was basically a
Firefox sans normal Firefox UI), but that too was killed off within a few
years.

------
bengotow
Hmm, I thought Mozilla had pulled financial support from Thunderbird? This
would be an exciting new chapter for the product, but the article doesn't
address whether it makes financial sense for Mozilla to invest this much in
Thunderbird's future.

For most of the last three years I've worked on Nylas Mail
([https://github.com/Nylas/Nylas-mail](https://github.com/Nylas/Nylas-mail)),
and it hit 2.0 yesterday with Mac/Win/Linux support. It's entirely open source
(GPL), written in JavaScript, syncs mail locally, etc. It essentially -is-
what the author of the post is looking to build, except it doesn't look like
Thunderbird. Nylas put at least $2M+ worth of engineering time into it, and I
imagine ThunderbirdJS would take at least a similar commitment of time and
effort. Heck, maybe they could just skin Nylas Mail and call it Thunderbird
;-)

~~~
wink
Is the "open source" label still comically misleading? [0]

I tried it out, didn't read the fine print, filed an issue, never looked at it
again.

Because "It keeps user data local and private." is kind of one of the main
benefits.

[0]: [https://github.com/nylas/nylas-
mail/issues/860](https://github.com/nylas/nylas-mail/issues/860)

~~~
bengotow
Ahh thanks I need to update that!

Originally Nylas Mail was OSS, but tied to the Nylas Cloud APIs (which did the
actual mail processing.)

The cloud strategy was too expensive, and in version 2.0 the entire mail-sync
system was moved into the client and open sourced.
([https://github.com/nylas/nylas-
mail/tree/master/packages/cli...](https://github.com/nylas/nylas-
mail/tree/master/packages/client-sync)). It's now much more like Thunderbird.
There's a bit of cloud processing for snoozing / send later, etc., but it no
longer syncs all your email through the cloud.

~~~
Ao7bei3s
Is there a way to configure it so it makes _zero_ requests to your servers?

If not (yet), would it at least be technically feasible, and would supporting
this be an option for you?

~~~
grinich
Definitely feasible but it's not our product focus right now. Most of the
features that help differentiate Nylas Mail require some cloud component.
(snoozing, send later, reminders, open tracking, etc.)

We totally encourage folks to fork the project and take it in whatever
direction they want. If you want to chat with other devs in the community, you
should join our Slack room: [http://slack-invite.nylas.com/](http://slack-
invite.nylas.com/)

(I work at Nylas)

~~~
problems
> (snoozing, send later, reminders, open tracking, etc.)

None of that has any appeal to me, I'd much rather a mail system which doesn't
require using someone else's server.

Maybe this isn't a priority for other people, but just putting it out there.
This is what's making me not use Nylas today.

~~~
atonse
He's already given you a good alternative – fork and collaborate with other
devs on a version that doesn't touch their server.

Seems sufficient.

~~~
hutzlibu
I would consider forking a last option, instead of "a good alternative".

A good alternative in my opinion would be just to make some parts optional.
Does not sound too hard, to implement (if the codebase is well done)

------
pjmlp
If it becomes yet another Electron package it is time to look elsewhere.

~~~
geodel
Perhaps the idea to implement it as web technology is to leverage NPM so that
millions of plugins can be made available to an email client.

~~~
rhizome
Now you have 100,000 problems.

------
mixedCase
I wonder, if they want to use JS, why not QtQuick? I'm a heavy Thunderbird
user but I would move to pretty much anything else if it were to switch to
Electron.

~~~
irq-1
I think the reason QtQuick hasn't taken over this space, is that you still
need to deal with C++ and cross-compiling. If QT had an option that made it
clear you could develop and distribute in JavaScript only, that would be a
hit.

~~~
rhodysurf
You can write QML apps in like every popular language, there are well
supported bindings everywhere.

I dont get the C++ hate though. C++11 and up is a totally new language and
much more productive than its reputation gives it.

------
zokier
It would be neat if TB would be rebased on top of Servo (and Rust) as a
flagship application for using Servo as an GUI foundation, the same way as TB
previously was for Gecko/XUL.

Sadly I doubt TB has the resources to make that happen, but still, it would be
neat...

~~~
estebank
I wonder if basing a desktop application on top of Servo would be any more
painful than on any of the existing self contained HTML/JS delivery mechanism.
It probably would be annoying until Servo reaches parity not to be able to use
the web technologies to their fullest extent, but at least you have one
(admittedly moving) target.

~~~
JoshTriplett
People have done this, not just for desktop applications but also for Android
apps, using Servo to display a web UI on mobile.

And there's some work in progress to put a WebView-compatible API on top of
Servo, making it trivial to substitute it in an arbitrary application.

------
zzz2002
Before we start thinking about working on Thunderbird or its replacement there
is a fundamental question that needs answering. Is there a future for email?
Email is/was a function of the personal computer era. But as PC sales decline
and smart phone sales grow do people still use email to the same extent? Is
its place in field of personal communications being replaced by SMS, etc. In
the business arena I am seeing some companies where internal email is not
allowed. The reasoning is that email has become a way of procrastinating (send
and forget). On the customer facing side of things email is being replaced by
web based customer service apps that use AI (or similar) to answer the
customers query ASAP, and if that is not possible get the info and pass on to
a human if and only if needed (people cost money). So back to the question is
email and by extension Thunderbird obsolescent. Would effort in redeveloping
TB be futile as it would wind up give us wonderful app just as email
disappears.

------
xupybd
"JavaScript, if used diligently and with good design, is a very efficient
language. Both in execution time, but more importantly for developers.
Personally, I wrote apps in many languages, including C++, Java and
JavaScript. Of those, JavaScript is by far the most productive - I am
personally 4-10 times as productive as with C++."

Not trying to start a this language is better flame war, but is this true? I
still find JS to be a strange and incomplete feeling language, but I've not
really done much outside of front end work with it. Is it really that
productive?

Also I've disliked every interaction with NPM. You end up with a huge chain of
decencies for even simple applications. Is this something that's workable with
production software?

~~~
beagle3
I suspect it is true that among Java, C++ and JavaScript, disciplined well
designed JavaScript is easier for developers, and reasonably efficient in
execution (given e.g. v8). Especially compared to C++, the memory safety and
speed of the compile->run->debug cycle tend to give JavaScript an edge for
more programmers (x4 to x10 is of course subjective).

But that doesn't mean JavaScript is a good language. e.g., you have to be
extremely careful to not get bitten by the floating point-only math. It was
the source of catastrophic bugs for many Twitter clients (in the sense that
they stopped working) -- I would hate to find such a bug ate my local mail
store.

Not sure what I'd recommend, though - JavaScript is technically bad, but
socially excellent for such a project. Python is not fast enough for it (PyPy
not withstanding), D/Rust/Nim/Ocaml/Scala are not mainstream enough.

------
Ono-Sendai
Sounds like a terrible idea, please no. I for one probably will stop using
thunderbird if it gets rewritten in JS.

~~~
tmzt
What is it written in now? If I remember correctly it's mostly JS with a few
native extensions in the chrome.

~~~
jcranmer
The backend is mostly in pure C++ (~500KLOC or so). The frontend is in JS
(~200KLOC or so).

------
zmix
I'd rather see projects like Cyberfox, Thunderbird, Palemoon and Evolus Pencil
(which, sadly, has been rewritten by now) taking up xulrunner, fork it and
continue developing it.

I have yet to find a better system for rapid application development. XUL is
wonderful, extentable, everybody know CSS and Javascript these days, XML is
very well suited for such tasks. It's one of the best technologies for power-
users I ever came around!

All that was ever needed would habe been a Mozilla, that creates an XUL IDE,
rather than taking up on a lot of stupid projects (Persona Light Themes, Hello
Chat, FirefoxOS, removing XPFE (how coding with XUL is actually called) and
whatever (the only real good thing to mention would be Ubiquity, but they
killed that off as well), oh, and let's not start talking about Firefoxy mugs,
t-shirts, community barbecues, community videos... But hey, that's what
happened.

Now, if some people would just fork xulrunner and mirrror the
addons.mozilla.org stuff...

As for Thunderbird, I am also pretty satisfied as it is. It may be nice, if
one could set certain To: email-addresses per folder (mailing-list folders
would greatly benefit from that, along with subscribe/unsubscribe configured
per such folder), alternate views onto mails and have, maybe, a modernized
foldering-system.

~~~
flukus
> I have yet to find a better system for rapid application development. XUL is
> wonderful, extentable, everybody know CSS and Javascript these days, XML is
> very well suited for such tasks. It's one of the best technologies for
> power-users I ever came around!

It also looks awful and ignores desktop themeing. Or is that just firefox?

------
norea-armozel
I'm just gonna say I oppose this proposal because I'm really tired of seeing
developers shy away from utilizing or learning C/C++ only to admit much later
in a project's life cycle that those languages and their associated libraries
are the best for the job. I'm all ears on utilizing JS for front end to even a
desktop application but if the entire thing gets written to be ran on Servo or
whatever browser engine they choose then I oppose it categorically. JS might
be fine for some things but as a general programming language on a substandard
runtime is just asking for trouble. Learn to write in C/C++ for native
applications or go home.

~~~
Kinnard
Why do you oppose things being run on something like Servo categorically?

~~~
norea-armozel
Because there's existing libraries which solve many of the same problems which
they inevitably run into and then re-implement them in JS. The "not invented
here" mentality has to stop. Unless there's a significant reason to not
utilize a library then it shouldn't be avoided. There's no good reason to
replicate that functionality.

~~~
Silhouette
_The "not invented here" mentality has to stop._

This is true, but the track record of bugs and poor security inherent in using
relatively low-level languages like C and C++ for everyday Internet-connected
applications also has to stop.

~~~
norea-armozel
That doesn't really help you when the platform you run on be it a browser or a
virtual machine is written in C/C++ which by implication can be exposed to the
same security flaws if/when they utilize unsafe design patterns or idioms. So,
all you've done is pass the buck onto Servo/Gecko/Safari. The reality is that
you can't make an argument that's ironclad in favor of forcing JS to become
the new C. Let JS do it's wonders for the web and let C/C++ and other
languages that have great native application tools do their wonders for the
desktop?

~~~
Silhouette
I didn't say anything about using JS as the alternative. I happen to think
it's a rather poor language and that using it for anything other than running
front-end code on a web site until we have better alternatives is usually a
mistake. But there are a lot more languages out there than C, C++ and JS, and
I don't think any of those is a particularly good choice for this sort of
task.

~~~
norea-armozel
Oh no doubt there's better languages in terms of general purpose programming.
I'm biased towards OCaml myself since it has nice syntax but there's plenty of
options to choose from. I'm just pointing to C/C++ languages since they're the
most mature and widely available in terms of documentation, IDEs, etc.

------
thesmallestcat
Note that this is from the end of March, and the thread continues at
[https://mail.mozilla.org/pipermail/tb-
planning/2017-April/th...](https://mail.mozilla.org/pipermail/tb-
planning/2017-April/thread.html)

------
MaxLeiter
> We need 2 persons for the framework, 3 for backend modules, 4 for frontend
> UI, and 1 for theming.

Doesn't 4 people dedicated to front-end UI seem excessive/unnecessary? At
least, at the beginning? I would dedicate almost all work to the framework and
backend modules; UI with web technologies is far from complicated compared to
everything else the client would require.

------
petepete
The mockups look very promising. I was never a TB user because it never looked
the part in Gnome, but it's something I've kept an eye on and recommended to
other people.

[https://dribbble.com/shots/2917534-Thunderbird-
Redesign](https://dribbble.com/shots/2917534-Thunderbird-Redesign)

------
gravypod
I skimmed through this and saw no management of PGP, encryption, key storage,
or key exhange. Is that not going to be one of the main focuses of this? I
wish that PGP/encrypted mail would be a main feature post Snowden.

~~~
fattire
The one thing i'd like to see is some kind of integration of the Signal
protocol-- preferably in a way that supports federation as (1) having
OpenWhisper Systems as a single point of failure for all email is not a good
idea and (2) having to tie one's email to a phone number is sheer insanity.
It's bad enough with messaging.

------
warpech
Why not rewrite it in Graphene, which is the Servo's foundation for
browser.html?

[https://github.com/browserhtml/browserhtml](https://github.com/browserhtml/browserhtml)

------
detaro
title should be the one of the submitted e-mail: "Proposal to start a new
implementation of Thunderbird based on web technologies", especially since "is
in the works" doesn't seem to be the case yet. (Lots of discussion, continuing
into April, but unless I missed it no actual decision made and work begun
yet.)

The thread is worth a read, interesting arguments regarding
rewrite/refactor/approaches to transition.

~~~
rxlim
According to Cambridge Dictionary "in the works" has the following meaning:

    
    
      in the process of being planned or done
    

Thunderbird replacement is currently being planned, so I think it's correct.

~~~
tumblen
I think it's that "in the works" seems to imply an agreement/commitment, but
this appears to be a proposal.

~~~
rxlim
This is a post[0] from one of the project leaders:

 _However, I think we all agree we want the Thunderbird replacement to be a
desktop client (plus other platforms like mobile), and based on web
technologies, most importantly written in JavaScript._

But the title has now been changed and that is fine with me.

[0][https://mail.mozilla.org/pipermail/tb-
planning/2017-April/00...](https://mail.mozilla.org/pipermail/tb-
planning/2017-April/005394.html)

------
pmontra
The only point I could argue with is the choice of JavaScript, all the others
seem inevitable. As a Thunderbird user I'm happy to know that I might be using
it for another 20 years.

Even JavaScript is not that bad. I not familiar with Electron: do those apps
run from a directory with the source code or are a binary file? Running from
source code would make it easy to hack with the code, which is good.

~~~
bengotow
Yep! Electron essentially just launches a web app from a directory on disk in
an included copy of Chromium, with NodeJS's JavaScript bindings as well as the
usual ones. The web app has an index.html, CSS, all the standard stuff. It's
usually packaged into a .asar file so things can be loaded faster, but it's
great for hackability.

------
jancsika
> We must pay attention to also keep technical qualities that many of our
> users rely on. An obvious one is that the new implementation must be able to
> quickly scroll through a list of up to 100000 messages.

Does any cross-platform GUI toolkit have a widget that can handle this with
sane defaults?

~~~
trishume
Qt, as long as you back the view with a model with O(1) lookup, can handle up
to INT_MAX rows perfectly fast. I expect other cross-platform GUI toolkits
work similarly. Most native table/list views work on an assumption of uniform
row height and thus handle huge lists with no trouble.

The problem browser based apps run into is rendering the entire list into the
DOM and thus the browser has to lay out the whole thing in order to compute
scroll bars and scroll positions.

You can work around this using requestAnimationFrame, large empty padding
divs, and inspecting the scroll position to create DOM elements for only
things that you compute are visible. At my last job I implemented a web based
table that could do 60fps scrolling on 100,000 items that were all dynamically
updating using js_of_ocaml and
[https://github.com/janestreet/incr_dom](https://github.com/janestreet/incr_dom).

~~~
acemarke
There's also toolkits like React-Virtualized:
[https://github.com/bvaughn/react-
virtualized](https://github.com/bvaughn/react-virtualized) .

------
nguillaumin
That is awesome! I actually toyed with the same idea a couple of months ago
and started a prototype, but in the end it was too much work for a single
developer (having to implement IMAP/POP backends, etc. in addition to the UI).

Using web technologies for desktop apps is not ideal, but at the same time
it's probably the easiest way these days to build cross-platform apps because
of the lack of a good cross-platform UI toolkit.

A big benefit I see is that it will make it very hackable as a lot of
developers are familiar with web technologies. That should be a good way to
get a lot of contributors to implement features and innovate (See for example
the community / contributions around Visual Studio Code).

------
petecox
Mozilla already has a mail client written in Javascript and HTML 5 - the one
shipping in Firefox OS.

And it worked decently.

Start by tidying it up for Android and then port it to desktop. One code base
- for mobile, tablet _and_ desktop.

------
ausjke
I am a bit extreme here as I think Mozilla shall reduce efforts on firefox and
make thunderbird a great product instead, one reason is that chrome is too
powerful to beat already, and thunderbird could become the universal email
client for all, not much contender there yet.

after using slack for a while i feel we can use one slack-channel for each
email contact, a bit like google wave probably, and thunderbird can merge
email+slack experience into one.

~~~
edko
If Mozilla manages to build a product based on Servo that kicks Electron's ass
(safer, faster, cheaper to distribute, etc.), then I am not sure that Chrome
cannot be beat (or be seriously challenged).

This Electron competitor would become very popular, and it could become the
"entry drug" into Rust development (you would be able to do everything in
HTML/CSS/JS but you would also have the option to code some parts in Rust, for
more power), which would also grow the number of Servo contributors. With a
large enough community, Servo-based Firefox could fight for a place at being
the best browser (safest, fastest, full-featured).

------
johnny7
Whatever you do, make it render emails in a sane way. I still prefer mutt
text-only rendering of emails (content) than any email rendering software, but
if you're going to render and digest html, actually do it. The total time
involved in and barbarity with which web atrocities have been committed to
make emails render correctly in Outlook or even Gmail cannot be understated.

------
Kenji
I wish I could freeze the program Thunderbird in time to keep it precisely how
it is right now for the next couple of decades. I literally want not change. I
know, I know. It's a pipe dream, the surrounding environment changes, breaking
the program as the OS and libraries evolve. But this constant resolving of
perfectly solved problems annoys me.

~~~
fao_

      git clone <thunderbird-url>
      <build from source and sudo make install>
    

^ there you go. A stable thunderbird branch that will work mostly forever.
Every time an API changes just shove it in another iteration of a virtual
machine :P

~~~
Kenji
Thank you, I know all of that. I like native though. So, both VM and HTML5+JS
are things I try to avoid for convenience messaging tools I use many times
every day.

------
Sytten
I like the idea of using web technologies for desktop application. The only
major problem right now is that each application uses at least 1.5-2g of RAM
each since it basically launches a full web browser under it (and chromium
loves ram). We will need enormous amount of RAM soon if all applications
starts to go that way...

~~~
ungzd
Thunderbird has browser engine to display html emails anyway. And probably
most of Thunderbird's code is already in javascript, but using XUL instead of
HTML DOM.

------
billpg
So it'll be a self-hosted webmail service with a custom web server that runs
locally?

~~~
Silhouette
That doesn't seem to be what they're aiming for here. The goal is supposed to
be a new UI that looks and functions very similar to today's.

That's too bad, in a way. One thing I'd really like that Thunderbird doesn't
offer today is to separate the mail receive/store/send functionality from the
reading/writing UI, so I could run the former on my own server and access it
from any device on my network.

Obviously there are some relevant standards here and you could set something
like this up with enough technical knowledge using other tools that already
exist. However, that reduces the potential market by a few orders of magnitude
to those who are sufficiently expert with those tools, and then probably by a
few orders more for those who have the time to actually do it.

~~~
flukus
> That's too bad, in a way. One thing I'd really like that Thunderbird doesn't
> offer today is to separate the mail receive/store/send functionality from
> the reading/writing UI, so I could run the former on my own server and
> access it from any device on my network.

Uh, that's exactly what an email server does. Thunderbird is just the client
used to access it from any device.

~~~
Silhouette
Assuming by "email server" you mean an SMTP server, that's not quite what I'm
talking about. What I'm looking for is more akin to a mail store, an IMAP
server, and functionality for sending and receiving via actual SMTP server(s).
That's a separate set of responsibilities to reading or composing messages,
which would just need something like an IMAP-compatible client. And all of
those are separate responsibilities to a full SMTP server with all the
administrative overheads that comes with.

You could do the back office part of what I'm talking about with tools like
Dovecot and fetchmail today, running on a Linux server with a standard Maildir
backing store, and then you could run Thunderbird purely for its IMAP client
capabilities as a front-end, but setting it all up and maintaining it is a
horrendous hassle and it's far too technically demanding for most users
anyway.

However, separating the receive/store/send responsibilities from the
read/write responsibilities would mean you could have a single store on any
server with relatively straightforward set-up to actually send and receive
mail, which you could then access from any device on your network (or over a
VPN or the Internet if it's running on a remotely accessible box), _without_
the risks and overheads of both running your own SMTP server and trying to get
mail from it actually accepted anywhere else these days.

Now that everyone's got PCs, laptops, tablets, phones, and who knows what
else, I think this is probably the single most limiting problem with
traditional offline email clients compared to all the hosted webmail services,
but it shouldn't be necessary to incur all the downsides of those hosted
webmail services just to access your mail from different devices.

~~~
flukus
IMAP is that single store. Setting up a server just for that would be just as
impossible for most users as settings up a mail server would be.

~~~
Silhouette
An IMAP server alone typically doesn't include the equivalents of fetchmail
and the like. It just provides a protocol for remotely accessing the mail
store.

However, I don't see why you think it would be impossible for most users to
set up what I'm describing. If they can install Thunderbird and configure it
to retrieve mail from their ISP or GMail or whatever, they could install a
two-part system and configure the store part to do the same using exactly the
same information.

In particular, just installing both parts on a single PC would work fine and
provide equivalent functionality to current standalone mail clients like
Thunderbird. You just have the flexibility to connect other devices to the
same store and safely access your mail from those as well, or to install the
store part on some other place on the network like an office server or maybe a
NAS at home if you want to.

~~~
flukus
> However, I don't see why you think it would be impossible for most users to
> set up what I'm describing. If they can install Thunderbird and configure it
> to retrieve mail from their ISP or GMail or whatever, they could install a
> two-part system and configure the store part to do the same using exactly
> the same information.

Then to connect from their mobile they have to open ports on their home
networks, get a static IP, know what their IP is to enter it on their phone,
worry about a whole host of new security issues.

At that point you may as well run a full mail server.

~~~
Silhouette
Many ISPs offer a static IP. This is applicable for small businesses as well,
and they almost certainly have one. Anyone with VPN on their router to access
anything remotely has a way in.

There are difficulties in running a full mail server far beyond this. For
example, many ISPs won't let you run one on anything below a high-level
business plan without just blocking port 25 and friends at a firewall. Even if
you can, many other mail servers will flag anything you send as likely junk
mail if you're not running a well-known mail server yourself. For incoming
mail, you need something that's going to be up 24/7/365 if you're going to
give it as the MX for your domain, and you need to be constantly monitoring
for security issues in real time, because if you're even a few hours late with
the patch then you're probably running an open relay already and you just made
every blacklist on the Internet.

Basically, if you're not big enough to have your own full time IT department,
there are huge practical advantages to sending and receiving your mail via a
dedicated SMTP server run by someone who does. These are completely unrelated
to the usefulness of having a centralised mail store that can be used from
anywhere on your network, or beyond if you provide a way in for remote access.

------
bugmen0t
The backstory here is that Thunderbird devs would like to be faster but have a
_hard_ time working against the Gecko changes that breaks their build.

Sure Thunderbird kind-of works, as in it's "done", but people find Security
bugs in the Firefox base and it's not sure how they apply to Thunderbird to
Thunderbird has to take the update and then they have to deal with the
breakage and the incompatibility. You can't just stop and be on Firefox 45
forever. That's just asking for trouble.

------
mazerackham
If it's scoped for 3 years, does that mean it'll take 9? =P

------
dammitcoetzee
I really like my hosted email because it's not on my computer. I love offline
software, but it all sucks for security. Dropbox, Evernote, Outlook, etc. They
all just dump my data in a folder anyone with physical access to my very
stealable laptop can get at. Email is especially terrifying because there's
just so much personal info in there. I have evernote and dropbox sitting in a
bitlocker, so that's okay-ish, but the email thing is just too much.

~~~
hutzlibu
You have heard of this awesome new thing called "Complete System encription"?

------
buovjaga
A couple of days ago I reached out to users to give a morale booster to the
devs as they try to figure this rewrite business out:
[https://www.reddit.com/r/linux/comments/65upot/show_some_lov...](https://www.reddit.com/r/linux/comments/65upot/show_some_love_for_thunderbird_by_testing_bugs/)

------
orionblastar
I like the gpg integration using enigmail in Thunderbird. So I can send
encrypted messages to my friends and people I write code with.

~~~
libertytrek
You'll be happy to learn that the P=P folks are most likely going to be
handling full end to end encryption integration for Thunderbird, for the
current version, and the new one (if it happens):

[https://pep-project.org/](https://pep-project.org/)

------
silky
> JavaScript

Nylas all over again... Why complicate and bloat things as if it's the obvious
sensible choice?

The time to finally learn how to configure mutt is that much close...

------
newsat13
The sieve plugin is still broken :-( What's the alternative when using
Thunderbird?

------
b4xt3em4n
After many years waiting, maybe we will have a compose new email on a tab.

~~~
libertytrek
God no, unless there is a way to disable it. I hate tabs in Thunderbird.

------
Gonzih
Please no. Im very happy with current state of Thunderbird.

------
deckiedan
Interesting that mithril.js gets a mention. I really like it.

~~~
acemarke
Was that mentioned in one of the replies? I don't see any specific libraries
mentioned in the linked message, or the other replies I searched through.

 _edit_ : Scratch that, it was in this reply:
[https://mail.mozilla.org/pipermail/tb-
planning/2017-March/00...](https://mail.mozilla.org/pipermail/tb-
planning/2017-March/005328.html) . "I'd suggest using TypeScript, Mithril.js,
Tachyons, and Node.js for the base technologies -- probably with Mocha/Chai
for testing. Later we can make a more stand-alone desktop version with
Electron or such. We could use socket.io to push notifications for changes in
real or virtual folders and then use Mithril.js (a vdom library) to quickly
rerender changed data the client UI requests (or is pushed)."

Worth noting that reply looks more like a wishlist of stuff than a meaningful
viable proposal.

~~~
brlewis
FWIW that reply appears to be someone who's serious about this proposal:
[https://github.com/pdfernhout/Twirlip2](https://github.com/pdfernhout/Twirlip2)

------
5ilv3r
Mozilla just doesn't get the message.... We don't want your features, fixes,
refreshes, rebranding, or re-imagining. We want a browser that is fast,
stable, secure, minimal, and that DOES NOT FIGHT US. Let me load my old SSL
certs (a warning is fine). Let me keep my preferences (why does
[https://](https://) disappear from my address bar every update, and my search
bar keep switching back to case sensitive).

Stop making your problems worse and get your $#!% together! I'm a sysadmin,
dangit, I need this tool to work!

~~~
Certhas
So Thunderbird is moving away from legacy technology that was built to make
Mozilla/Firefox more than just a browser. They are doing this to be free to
improve Firefox to make it more stable, fast, secure and minimal.

This leads to a completely independent Mozilla project, Thunderbird, that
relied on this technology to get the axe.

That project thus is discussing taking the difficult technical step to start
from scratch while keeping the user experience the same its been for 10 years.

This, in turn, leads to you criticising Mozilla for not focusing on making
their browser fast, stable and secure. Because you are hitting some
configuration/update/UI bugs that seem entirely unrelated to the core browsing
experience. Thunderbird, BTW, has 25 million users. So even if you don't need
it, some people do.

~~~
5ilv3r
The resource allocation decisions mozilla has been making is driving me away
from their products. Throwing resources at recreating thunderbird with a new
framework is a poor use of their time.

~~~
Certhas
You are still not paying attention. Mozilla has decided to _not_ throw
resources at Thunderbird anymore. The outcome of that is that the _community_
is debating to move away from the to be deprecated XUL platform.

