Empathy List Archives

RK

R Kent James

Wed, Feb 7, 2018 9:49 PM

In discussions of vision on tb-planning, there were plenty of voices
calling for continuing to focus Thunderbird on desktop, expending no
resources on mobile or web directions. You probably know I disagree with
that perspective (and I think that an upcoming log post from Ryan about
his FOSDEM experience will reinforce that the larger audience is really
interested in mobile and web email), but let's think through what a
desktop focus would really mean technically.

As many of you know, I have for many months been working toward
retirement from Thunderbird, so I'm not really going to be in a position
to push my beliefs forward in the future. So take some of these thoughts
as words of fatherly advice from someone with many years of experience
with Thunderbird.

Thunderbird technically developed the general philosophy of implementing
new features in JS during an era when it seemed like Firefox had a
similar approach. But since then, Firefox has completely pivoted toward
betting on Rust as the key to a more robust, performant future. Now we
see quite a different approach, with Mozilla platform removing features
from Javascript and XPCOM that are not strictly needed by
security-limited web applications, but are important to a more universal
use of Javascript. See for example the recent push to restrict the
functionality and extendability of nsIURI. It is becoming increasingly
difficult to replace C++ implementations with JS.

Meanwhile, let's review our experience with JS replacements. Calendar's
replacement of libical was never fully completed due to performance
issues. JsMime suffered severe performance limitations initially, which
we solved through shortcutting a few procedures. (That method deals with
some pretty simple manipulations of things like address fields and
headers. I doubt we could replace the C++ mimelib for full-text
manipulation with a JS version easily due to performance issues) My
experience with JsAccount has succeeded so far, but the JS-based
ExQuilla is also quite slow compared to IMAP.

Looking outside Thunderbird, the active fork of Nylas (called Mailspring
https://github.com/Foundry376/Mailspring) had to replace their JS IMAP
backend with a C++ version: "Mailspring replaces the JavaScript mailsync
code in Nylas Mail with a new C++ sync engine based on Mailcore2. It
uses roughly half the RAM and CPU of Nylas Mail and idles with almost
zero "CPU Wakes", which translates to great battery life."

In summary, we have a lot of reasons to wonder if JS is going to ever be
able to offer the performance that we need.

I've continued though to promote JS because I think that it has the best
hope of achieving what I think is a long-term requirement of
Thunderbird, namely to offer a true multi-platform email product with a
consistent UI and workflow over the platforms in use today (Linux,
Windows, OSX, Android, iOS, web). I believe that the likely performance
issues are less important than the multi-platform capabilities.

But that all changes if you abandon mobile and web - particularly if you
view Thunderbird for the foreseeable future as a recompile of Firefox
binaries, as it has always been. Now instead of offering a
multi-platform product, you need to provide a desktop product with some
outstanding characteristics. Certainly performance should be one of
them. And if you are going to stay aligned with Firefox binaries, then
you need to follow their primary technical initiatives. That means Rust
and the WebExtensions API.

So I am asking the question - if the technical future of Thunderbird is
a recompile of Firefox, then we should really rethink our very old
commitment to JS, XUL extensions, and XPCOM as the core technologies,
and consider moving into Rust and WebExtensions like Firefox.

This has some serious implications in the hiring round that we are
undergoing right now.

:rkent

In discussions of vision on tb-planning, there were plenty of voices calling for continuing to focus Thunderbird on desktop, expending no resources on mobile or web directions. You probably know I disagree with that perspective (and I think that an upcoming log post from Ryan about his FOSDEM experience will reinforce that the larger audience is really interested in mobile and web email), but let's think through what a desktop focus would really mean technically. As many of you know, I have for many months been working toward retirement from Thunderbird, so I'm not really going to be in a position to push my beliefs forward in the future. So take some of these thoughts as words of fatherly advice from someone with many years of experience with Thunderbird. Thunderbird technically developed the general philosophy of implementing new features in JS during an era when it seemed like Firefox had a similar approach. But since then, Firefox has completely pivoted toward betting on Rust as the key to a more robust, performant future. Now we see quite a different approach, with Mozilla platform removing features from Javascript and XPCOM that are not strictly needed by security-limited web applications, but are important to a more universal use of Javascript. See for example the recent push to restrict the functionality and extendability of nsIURI. It is becoming increasingly difficult to replace C++ implementations with JS. Meanwhile, let's review our experience with JS replacements. Calendar's replacement of libical was never fully completed due to performance issues. JsMime suffered severe performance limitations initially, which we solved through shortcutting a few procedures. (That method deals with some pretty simple manipulations of things like address fields and headers. I doubt we could replace the C++ mimelib for full-text manipulation with a JS version easily due to performance issues) My experience with JsAccount has succeeded so far, but the JS-based ExQuilla is also quite slow compared to IMAP. Looking outside Thunderbird, the active fork of Nylas (called Mailspring <https://github.com/Foundry376/Mailspring>) had to replace their JS IMAP backend with a C++ version: "Mailspring replaces the JavaScript mailsync code in Nylas Mail with a new C++ sync engine based on Mailcore2. It uses roughly half the RAM and CPU of Nylas Mail and idles with almost zero "CPU Wakes", which translates to great battery life." In summary, we have a lot of reasons to wonder if JS is going to ever be able to offer the performance that we need. I've continued though to promote JS because I think that it has the best hope of achieving what I think is a long-term requirement of Thunderbird, namely to offer a true multi-platform email product with a consistent UI and workflow over the platforms in use today (Linux, Windows, OSX, Android, iOS, web). I believe that the likely performance issues are less important than the multi-platform capabilities. But that all changes if you abandon mobile and web - particularly if you view Thunderbird for the foreseeable future as a recompile of Firefox binaries, as it has always been. Now instead of offering a multi-platform product, you need to provide a desktop product with some outstanding characteristics. Certainly performance should be one of them. And if you are going to stay aligned with Firefox binaries, then you need to follow their primary technical initiatives. That means Rust and the WebExtensions API. So I am asking the question - if the technical future of Thunderbird is a recompile of Firefox, then we should really rethink our very old commitment to JS, XUL extensions, and XPCOM as the core technologies, and consider moving into Rust and WebExtensions like Firefox. This has some serious implications in the hiring round that we are undergoing right now. :rkent

JC

Joshua Cranmer 🐧

Thu, Feb 8, 2018 1:35 AM

On 2/7/2018 4:49 PM, R Kent James wrote:

In summary, we have a lot of reasons to wonder if JS is going to ever
be able to offer the performance that we need.

I've continued though to promote JS because I think that it has the
best hope of achieving what I think is a long-term requirement of
Thunderbird, namely to offer a true multi-platform email product with
a consistent UI and workflow over the platforms in use today (Linux,
Windows, OSX, Android, iOS, web). I believe that the likely
performance issues are less important than the multi-platform
capabilities.

But that all changes if you abandon mobile and web - particularly if
you view Thunderbird for the foreseeable future as a recompile of
Firefox binaries, as it has always been. Now instead of offering a
multi-platform product, you need to provide a desktop product with
some outstanding characteristics. Certainly performance should be one
of them. And if you are going to stay aligned with Firefox binaries,
then you need to follow their primary technical initiatives. That
means Rust and the WebExtensions API.

So I am asking the question - if the technical future of Thunderbird
is a recompile of Firefox, then we should really rethink our very old
commitment to JS, XUL extensions, and XPCOM as the core technologies,
and consider moving into Rust and WebExtensions like Firefox.

As I said in my recent message, we should probably consider what we
actually have the manpower to do in reasonable timeframes. With the
deprecation of XUL, we are more or less forced to rewrite most of our
frontend code, although substantial portions possibly could be salvaged.
The code of nsMsgDBView is pretty much the only
substantially-front-end-driven C++ code, and since that code is
performance-sensitive, it's likely to play a major role in any frontend
rewrite anyways. Demanding that we move everything to JS requires us to
rewrite the entire backend to make progress forwards, and I think
experience has generally shown that this is simply not tractable, not
with our manpower resources.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

On 2/7/2018 4:49 PM, R Kent James wrote: > In summary, we have a lot of reasons to wonder if JS is going to ever > be able to offer the performance that we need. > > I've continued though to promote JS because I think that it has the > best hope of achieving what I think is a long-term requirement of > Thunderbird, namely to offer a true multi-platform email product with > a consistent UI and workflow over the platforms in use today (Linux, > Windows, OSX, Android, iOS, web). I believe that the likely > performance issues are less important than the multi-platform > capabilities. > > But that all changes if you abandon mobile and web - particularly if > you view Thunderbird for the foreseeable future as a recompile of > Firefox binaries, as it has always been. Now instead of offering a > multi-platform product, you need to provide a desktop product with > some outstanding characteristics. Certainly performance should be one > of them. And if you are going to stay aligned with Firefox binaries, > then you need to follow their primary technical initiatives. That > means Rust and the WebExtensions API. > > So I am asking the question - if the technical future of Thunderbird > is a recompile of Firefox, then we should really rethink our very old > commitment to JS, XUL extensions, and XPCOM as the core technologies, > and consider moving into Rust and WebExtensions like Firefox. > As I said in my recent message, we should probably consider what we actually have the manpower to do in reasonable timeframes. With the deprecation of XUL, we are more or less forced to rewrite most of our frontend code, although substantial portions possibly could be salvaged. The code of nsMsgDBView is pretty much the only substantially-front-end-driven C++ code, and since that code is performance-sensitive, it's likely to play a major role in any frontend rewrite anyways. Demanding that we move everything to JS requires us to rewrite the entire backend to make progress forwards, and I think experience has generally shown that this is simply not tractable, not with our manpower resources. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist

MH

Matt Harris

Thu, Feb 8, 2018 2:22 AM

On 08-Feb-18 8:19 AM, R Kent James wrote:

I do not think anyone is going to pretend that JS can do the performance
jobs that are currently undertaken by C++. They might be able to be
done in Rust as it is a compiled language, but I must leave it to
someone that actually knows Rust to comment on that.

So I think we are left with Rust but I do not want to see Thunderbird
going down the web extensions API for add-ons. They are currently far
to limiting. Just as the HTML user interface appearing in Firefox looks
amateurish. Thunderbird is a desktop application and should look as
much like a native application as can be managed.

Matt

On 08-Feb-18 8:19 AM, R Kent James wrote: I do not think anyone is going to pretend that JS can do the performance jobs that are currently undertaken by C++. They might be able to be done in Rust as it is a compiled language, but I must leave it to someone that actually knows Rust to comment on that. So I think we are left with Rust but I do not want to see Thunderbird going down the web extensions API for add-ons. They are currently far to limiting. Just as the HTML user interface appearing in Firefox looks amateurish. Thunderbird is a desktop application and should look as much like a native application as can be managed. Matt

maildev@lists.thunderbird.net

Technical directions for Thunderbird Part I: Questioning JS Focus