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

Paul D. Fernhout pdfernhout at
Tue Apr 4 04:02:21 UTC 2017

Hi Joshua,

Your point on risk management makes a lot of sense. That's why I
suggested a possibility of having a new Thunderbird that could run
alongside the existing one and share the same files while offering a
different UI. That is the simplest risk-management strategy I can think
of for one developer with web technology experience to take.

To address this risk in another way (one requiring coordinating multiple
developers with current Thunderbird codebase knowledge), consider an
option I mentioned but mostly discounted as as not fun. We could modify
Thunderbird-as-it-is to work as a backend to serve content to a web
browser. Essentially, we add a simple embedded web server to Thunderbird
written in C/C++ which supports an API (maybe all JSON, maybe even
JMAP?) to fetch and store email-related content, where the existing
backend still handles retrieving messages from servers and writing local
files. The existing full Thunderbird UI would continue to work in
parallel with this web server and be maintained in parallel. The goal
then would be to get the entire Firefox-based UI replaced first. After
we have a workable UI, then we could throw away the embedded Firefox UI
while still keeping the backend. After that, then we could talk about
redoing the Thunderbird backend if desired (maybe in Node.js, Java,
Python, Rust, C/C++ again, or whatever). And all along, there would just
be one system.

Anyway, this other approach would be a lot more work and coordination,
and would require making riskier changes to the existing Thunderbird
codebase (including because the existing UI code might not play nice
with some other UI given shared state, so that might take extra work to
resolve). As an individual, I would never consider doing such a thing
myself. But it is possibly the most incremental thing we could do as a

Also, maybe someone more conversant than I with the range of existing
Firefox/Mozilla technologies might be able to point to embedded server
code we could leverage? Maybe related to past work for FirefoxOS?

Obviously, at some point the effort involved in making such changes
incrementally might exceed the from effort needed to rewrite from
scratch. So, its a tradeoff about risk mitigation at potentially a big
extra labor cost. I don't know enough about the Thunderbird codebase to
decide about that tradeoff -- other than that from what little I've seen
and learned the existing Thunderbird-specific codebase seems hard to
understand and maintain (even the backend) because of the entanglement
with Firefox code and a complex Firefox-related build process. But,
perhaps that impression is incorrect? Or even if it is correct, given
Thunderbird-as-is will likely be maintained for another year or two,
maybe the extra work of adding in a server part won't be too much?

--Paul Fernhout (
"The biggest challenge of the 21st century is the irony of technologies
of abundance in the hands of those still thinking in terms of scarcity."

On 2017-04-03 8:58 PM, Joshua Cranmer 🐧 wrote:
> The problem is that you're suggesting... well, basically inaction (on a
> feature level) while you go off and work on a separate project,
> hopefully to force it down everyone's throats when it's done. And
> arguing that it will be so wonderful and timely that there's not going
> to be any problems forcing people to switch (I am aware that this is
> probably a gross caricature of what you're proposing). *That* is 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.
> The biggest risk is that one snag derails the entire project. Suppose,
> 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. (This is not
> unrealistic: this is exactly what happened to ical.js). What do you do?
> 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. Proposing a complete rewrite and not seeking gradual uplifiting
> is exactly the opposite of that strategy.

More information about the tb-planning mailing list