THIS PAGE IS PROPOSED FOR DELETION	2019-11-15
	This page contains personal plans that are no longer relevant, and could be confusing for people looking into Thunderbird plans. Should have been on a user page to start with.

Why we do this

Thunderbird is now over 20 old. The beginnings go back to 1995, with the Mail component in Netscape 2.0. Then came Netscape Communicator 4.5, by another team. 1999-2000, it was turned into Mozilla Seamonkey, then into Thunderbird. The change to Mozilla with XUL and XPCOM was big, but still kept a lot of the backend code. On top of all that are a few decades of hacks.

It's time for a refreshment, using a clean architecture and using a clear separation between model and view, and a thin view, to allow for easy changes to the view or even completely separate views, e.g. for mobile. Architecturally, change observers will help a lot to keep the components decoupled.

What's really making this change required, though, is that the Mozilla platform moves away from XUL and XPCOM towards HTML and Servo. Both XUL and XPCOM are base technologies that Thunderbird is written in or that define core parts of it. The Thunderbird project already uses a good part of its development effort just keeping up with Mozilla changes, and this effort is going to increase significantly in the near future (Nov 2017) when XUL extensions are dis commissioned. Mozilla made this drastic move not to deliberately kill a community, but to allow them to make large changes to the platform. These very changes are going to affect Thunderbird massively, being the largest XUL and XPCOM application ever written, even bigger than Firefox itself.

This means that large parts of the codebase have to be rewritten anyway, in the mid-term to near future. Of course, the changes in Gecko are gradual, but eventually, the technology will go away, so the overall work is there nonetheless.

Given that XPCOM is the very technology that creates the API between the modules, is hard to replace step by step. I think we would spent as much time integrating the new modules with the old code as we would take writing the module in the first place, which means the overall effort increases at least 2-fold, by trying to do it step by step. Other negative effects add another 2-fold factor, so that it eventually takes 4 times as long to operate "on the open heart" than using the "minimal viable product" approach. Worse, the new component would have to adhere to old and unfortunate design patterns that emerged between components.

The TB:NG project proposes to use this opportunity to also create clear component separation and clean API that make it easy to learn the codebase and easy to make changes to it. A good extension API surface and more stable extensions would be a side effect of a good internal API.