Proposal to start a new implementation of Thunderbird based on web technologies

Ben Bucksch ben.bucksch at
Tue Apr 4 20:05:23 UTC 2017

Joshua Cranmer 🐧 wrote on 04.04.2017 02:58:
> On 4/3/2017 5:00 PM, Ben Bucksch wrote:
>> Joshua Cranmer 🐧 wrote on 03.04.2017 18:08:
>>> We've talked about rewriting Thunderbird for, oh, a decade or more 
>>> now. We've had agreement on the direction these rewrites should take 
>>> for at least 3 or 4 years (rkent was really one of the last 
>>> hold-outs for using JS). But we've not really made any measurable 
>>> progress on rewriting Thunderbird.
>> And you know why? Because nobody started. If we had started "a decade 
>> or more" ago, we would be done since 5 years, would not be fighting 
>> Gecko regressions today, and would be adding the features that the 
>> users today are screaming for.
> It is a lie to say that no one started.

There are many email clients written in JavaScript, and many of them 
work wonderfully. So, it's definitely technically feasible. However, 
they are not a replacement for Thunderbird, because they are based on 
custom servers, and they do not even try to have the features that 
Thunderbird has. That's not because it's impossible - they have other 
difficult features, like PGP or telephone integration -, but because it 
was not their goal. They just had a different user group in mind.

I meant a full email client, to replace Thunderbird. The Thunderbird 
project has never seriously tried that.

I specifically excluded attempts to gradually rewrite, by replacing 
certain components of the old Thunderbird. That was my whole point. We 
have tried that, indeed, and it hasn't gotten us anywhere. If it had 
worked, we would be finished by now, with a renewed Thunderbird. After 
"a decade", we're very far from done. We simply don't have another 5 years.

> There have been at least two projects with the clear intention of 
> rewriting major portions of Thunderbird that produced concrete results 
> yet have failed to come to fruition (Ensemble and JSMime)

I know your work around JSMime, and I appreciate and respect your work.

> what concerns me: that you're going to hit a roadbump, and everything 
> is going to go wrong, and there is going to be no Plan B.

There is a plan B. I am not proposing to stop Thunderbird based on 
Gecko. It will continue until the replacement is ready. Everybody has 
the option to switch at the moment they feel the replacement is better 
for them than the old Thunderbird. That will be a different moment for 
different people.

At the end, we will make a specific effort to migrate the features that 
the remaining users need.

Also, Thunderbird-on-Gecko can backport the new developments. I also 
described that. That's another risk mitigation.
That means there *are* 2 plans. There is a Plan B.

If you gradually rewrite, *then* you don't have a plan B. The 
integration of new components into old codebase is hard. If the rewrite 
fails, or does not finish in time (same thing), you are dead.

> force [the replacement] down everyone's throats

I don't think that's a fair argument. You also force your rewritten 
components "down the throat of everyone" (to use your own language), 
even in the old client. What, if I don't like the replacement part or 
how it works? Same thing.

> for example, that you have problems with unacceptable performance on 
> message display, and that this resists all attempts to bring it to the 
> performance level of existing Thunderbird code for years.

Please don't pretend that Thunderbird is perfect. Here, my Thunderbird 
keeps freezing for 3-5 seconds every 15-30 seconds. I have one of the 
fastest desktop machiens you can buy. It's like that since years, but 
it's getting worse. Do you any idea how disruptive this is? I've filed 
bugs about this, posted all information and symptoms I have there, 
without any action. This makes me want to trash Thunderbird. And that's 
saying something, because I've put a lot of my time into it.

> What do you do?

Fix it. There are enough email clients built in JS to prove that it's 

> This is the sort of risk that concerns me deeply, and the best way to 
> mitigate is to minimize the criticality of delivering any one 
> individual feature.

You're welcome to backport individual features of the new implementation 
to the old Thunderbird.

> Proposing a complete rewrite and not seeking gradual uplifiting is 
> exactly the opposite of that strategy.

No, it's not. It's just 2 efforts running in parallel: Creating the new 
app, with a clean code design, and backporting the new components to old 
Thunderbird. And that can be done in separate teams. You do effectively 
still do a gradual rewrite of the old Thunderbird.

You just a) share the load and b) don't compromise the new design with 
old APIs and c) if the integration with old Thunderbird does not work 
out, you still have a working result: the new version.

I am so insistent, because I'm convinced that the gradual rewrite will 
not finish in time. It will be late by years, if it ever finishes at 
all. If project history is any indication, I think it will outright 
fail. So, what I propose is in fact risk mitigation.

(The other reason is that the Thunderbird code design is 20 years old 
and just not fit for today, and a gradual rewrite would keep the overall 

All our attempts of something new have always failed, because we held on 
too much on old code and old thinking. The task itself is doable. It's 
just extremely hard within the constraints of the old thing.

> 3. I am not proposing to maintain the current APIs.

How did that work out for JsMime? See what I mean?


More information about the tb-planning mailing list