Thunderbird development

Paul Fernhout pdfernhout at
Wed Nov 29 15:38:55 UTC 2017

On 28.11.2017 04:25, Eyal Rozenberg wrote:
> On 11/28/17 5:15 AM, Paul Fernhout wrote:
>> Thunderbird needs to be rewritten essentially from scratch, with a 
>> core ideally in a more type-safe language than C/C++ while leveraging 
>> existing libraries and tools (such as using Firefox Quantum as a 
>> client via web protocols and not via embedding).
> Umm, C and C++ are completely different languages,

True, but both are typically used in codebases of that sort; for 
"SpiderMonkey is Mozilla's JavaScript engine written in C and C++."

Here is a good recent debate by many developers on the pros and cons of 
both C and C++:
"Why ESR Hates C++, Respects Java, and Thinks Go (But Not Rust) Will 
Replace C "

> and it's weird that
> you discuss them together as being non-type-safe. AFAICR C++ is quite
> type-safe unless you specifically circumvent type checks.

Since either C or C++ support writing outside the bounds of arrays, 
freeing memory twice, and casting between structures of different sizes, 
there are whole host of security bugs likely in C and C++ applications 
that just don't usually happen in, say, Java, JavaScript,Lisp, or 
Smalltalk. I called that "type safety" but perhaps "memory safety" would 
have been a better choice. Further, manual memory management is 
typically a source of about one third of C and C++ bugs -- and manual 
memory management also takes up lots of developer time that otherwise 
could be focused on other areas. It's true that tools can help find 
those unsafe memory situations or can even provide conservative garbage 
collection, but in practice those tools and libraries are often not used 
for whatever reasons and also have their own weaknesses.

> I'm not commenting to start an argument on language merit, though,

As with the Slashdot discussion linked above, both C and C++ have their 
defenders. For latency-critical or long-running applications there is 
certainly a case to be made for manual memory management and 
pre-allocation of all data. For time critical applications, a case can 
be made for writing close to the metal. If you have to do those things, 
C makes sense -- and at some point for a complex application you can 
argue C++ provides some good abstractions or useful libraries worth the 
extra complexity of the C++ language over C.

But none of those cases apply for Thunderbird as a desktop application 
-- or, perhaps in the future, a communications server for messages 
between people generally tolerating high latency compared to real-time 
embedded systems.

Those cases (performance, latency) might apply in some areas of a web 
browser. But in 2017, the whole idea of embedding a complex web browser 
written in a low-level language directly in your application in such a 
way that you need to compile and maintain the web browser code yourself 
is just ... (looking for a polite word) ... ill-advised. And even 
Mozilla is trying to get away from C and C++ with Rust.

One alternative is to have an application be a local web server that 
talks to a web browser. Such a server can be wrapped in Electron or 
something similar if you really want to bundle a web browser with your 
application. That different relationship to the web browser is the 
architectural shift which makes most of the existing Thunderbird 
codebase obsolete (whatever it is written in). And that shift 
essentially the reason I am writing this email in Roundcube via a web 
browser on a cheap Chromebook on my couch and not Thunderbird on a big 
desktop in my office.

> but rather to ask - is this your opinion or has there been a decision 
> to
> move away from C++ as a core language for a future TB?

Just my personal opinion.

But you can find others saying the same. Here is a comment from 2007(!), 
for example from Benjamin Smedberg:
"I have a fairly high tolerance for coding pain, and I have found the 
mailnews codebase very difficult to navigate and hack effectively. There 
are multiple causes for this, that I am going to list in no particular 
order. ... 1) Poor Model-View-Controller separation.  ... 2) Pervasive 
C++ ..."

And agreement by Jean-Marc Desperrier: "I think the problem mostly is a 
huge amount of very bad C++, very verbose and inefficient. I always felt 
reading the mailnews codebase that at the start of the project it 
received all the worse coders so  that they would not disturb the 
browser code. [After providing an example of such poorly written code] I 
could submit a patch for the above, but what would be the point when 
what is really needed is a full rewrite ? And in that rewrite, we could 
as well think about reducing the amount of C++ code in favor of js, but 
the basic problem is not C++, it's bad code, and it could just as well 
be bad js code than bad C++ code."

Ok, that was ten years ago, but has that much changed? Maybe it has as 
regards just Thunderbird?

And even if it has, then consider this next point on the consequences of 
having an embedded web browser written in C and C++.

Here is one big reason why it is so hard to engage developers with the 
existing C and C++ codebase for Thunderbird:
"The source code requires 3.6GB of free space or more and additionally 
5GB or more for default build.  ... Building can take a significant 
amount of time, depending on your system, OS, and chosen build options. 
Linux builds on a fast box may take under 15 minutes, but Windows builds 
on a slow box may take several hours. ... [After making changes] Then 
just re-run the mach command above. This will only recompile files that 
changed, but it's still a long haul."

And nowadays I feel waiting ten seconds or more to test changes to a 
large TypeScript application is painful...

Having to deal with this accidental complexity and testing delays from a 
legacy of embedding low-level complex code of a web browser in 
Thunderbird is all a distraction from Thunderbird developers working on 
better ways to help people communicate. It's all massive technical debt. 
That's the big challenge of Thunderbird going forward -- how to deal 
with that technical debt for each part (whether by minor maintenance, 
progressive refactoring, and/or rewriting) -- especially considering the 
need to now *unembed* a legacy Firefox web browser component from the 
Thunderbird codebase. And the use of a low-level-oriented language like 
C or C++ with poor guarantees for memory safety where it is no longer 
needed (if it ever was) in Thunderbird is another part of that technical 
debt in my opinion.

--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."

More information about the tb-planning mailing list