Future Planning: Thunderbird as a Web App

Kent James kent at caspia.com
Fri Sep 18 17:39:48 UTC 2015

On 9/17/2015 3:20 PM, Sean M. Pappalardo wrote:
> Hello.
> The direction you outline makes sense to me and opens up some 
> interesting possibilities. I just have a few questions.
> As a "web app," will Thunderbird still look and feel like a desktop 
> one on desktop OSs? Will there need to be a hidden Web server process 
> in the background? How much of a speed penalty will there be with JS 
> vs C++ code?
> Will it be easier (even trivial, dare I say) to build Thunderbird as a 
> native iOS and Android app once it's a Web app?
> Would it be possible to run Thunderbird as a cloud app too? I.e. the 
> back-end on a Web server and front end usable by any modern browser? 
> (Much like SOGo's Web interface: 
> http://www.sogo.nu/tour/screenshots.html)

Performance: is a major concern as others who have gone down this path 
have encountered, and we see with JsMime and ical.js  I think it will be 
important that we not simple assume that the performance issues will be 
solved by faster js, but we need to identify performance-sensitive areas 
and a mitigation strategy. That might include using asm.js more 
deliberately, or even proposing needed WebIDL components that are needed 
to be developed and exposed to the web that solve critical performance 

native iOS or Android: No this is not a goal or easier. If it were, we 
would follow the path of Fennec, but that is not the plan here.

Thunderbird as a cloud app: This would not be a short-term goal. But we 
might need to be open to this as a possibility when we design basic 
protocols. For example, we will need to consider the path that transmits 
information about messages to the front-end code. At the very least we 
will be moving to make this async. At the same time, we might consider 
if that same interface could be adapted to a cloud-based back end in the 
future. You might, for example, use a cloud-friendly protocol like JMAP 
to interface to your local message storage, so that a future cloud-based 
app could be converted easily.

> If this is the direction things go, how will that affect my desire to 
> add full LDAP editing? Should I wait until the application core is 
> changed over first? Or will rewriting the Address Book module be part 
> of the code conversion?

LDAP is a great example of how thinking might change. I think we have 
discussed for years that LDAP code needs to convert to a standard, 
non-binary library in the long run. I think that we should resist the 
urge to try to adapt our existing C++-based library to support editing. 
But if you are interested in LDAP, we would really, really appreciate 
someone who would research available, license-compatible LDAP js 
libraries, and adapt our code to use that. Editing should be added in 
the context of that new library.

As for user interface, if you do a new UI you should consider using HTML 
instead of XUL. This is already done in a few places in Thunderbird 
code. See for example accountProvisioner.xhtml The js support for that 
brings in many existing XPCOM-based Thunderbird js scripts, so you can 
see that it is actually not as difficult as you might imagine to use 
HTML instead of XUL.


More information about the tb-planning mailing list