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

Tito f.disclosure at
Mon Apr 17 19:55:02 UTC 2017

> Right now, the biggest risk for Thunderbird is to not move fast enough.
> Getting going is not longer sufficient. We need to run now, race.

Ben, unfortunately your are right i.e. there is not much time left and
TB needs to hurry but as Kent spoke about architecture, design patterns
and Philip about the goal of that future client. I really believe that
this is crucial before moving forward with any implementation.

> The next TB is going to be written in JavaScript, that much is for sure.

As much as i would like to agree with that since in this case there such
complicated technologies as XPCOM will not be needed, I would like to
put my 2 cents:

There is a very good reason why binary websocket together with
WebAssembly are being so actively pushed by all major vendors on the
market. I am not saying JavaScript is bad i am just saying that my
target will be to make a future such project much more robust by any big
changes. For example Mozilla decided to drop xul, xpcom etc ... and the
whole projects collapses. I completely agree that JavaScipt must be
present in the such project, but I also believe that some of the core
needs to be written in some other strongly typed languages since i
believe 2 things will happen in the future:

1) WebAssembly with websockets  will take over because of one simple
reason this will kill all of the addons such as Privacy Badger, No
Script JS, Adblock plus etc ... this will result in some devaluation of
the JavaScript. Large vendors are just waiting for the right moment for

2) large game development business will use exactly the 2 technologies
above and not java script (and by the way this is already happening!!!)

3) Unfortunately WebAssembly is difficult to debug as well impossible to
steal the code i.e. proprietary. Companies love that!

Now considering all this above I am not saying JavaScript will disappear
but it will definitely decrease from the networking perspective. I  get
it that we are really productive with JavaScript and that we can save
time on development but also I believe that the above arguments needs to
 be considered before going forward. I would like you to consider Java
here as well because of 6 reasons:

a) We need to try to bring that future client not only to the end users
but also to the to the enterprise. Enterprise today live in Java

b) By bringing it to the enterprise we have good change of getting a
companies financing the project.

c) "Write once, run anywhere" - Platform independent

d) Phones are using Java - future code will run on the phones as well,
not changes what so ever, this will be really the killer feature.

e) No one can drop JDK  i.e. there is OpenJdk , IBM jdk etc. etc.

f) There it is plethora of libraries written on Java.

g) It is the most popular language today according to Tiobe 2017.


(very old dino)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the tb-planning mailing list