FF modularity discussion and Thunderbird backend

R Kent James kent at caspia.com
Wed Oct 12 16:36:24 UTC 2016

There is a very interesting discussion on the firefox-dev list going on
right now about modularity and related technologies, that encompasses
not only FF but also the shared backend that Thunderbird uses. See the
thread at
"Followup: modularity, WebExtensions, and going faster"

Although the thread started from the premise of extending Web Extensions
to be a basic API to be used for browser development, the discussion
extends into the modularity (or lack thereof) in the FF/Gecko codebase,
and ways to fix that. One of my takeaways: Although never stated as
such, I think it is clear that Mozilla now recognizes the perils of
doing large-scale application development with untyped code (IOW JS).
Other large adopters of JS (Microsoft, Facebook, Google) have already
reached this conclusion, and have their own approaches to dealing with
the issue (Typescript, Flow, Google Closure compiler).

>From the Mailnews perspective, I have my own experience in trying to
interpret jcranmer's jsmime library. In spite of an heroic effort by him
to make that well-documented, it is still very challenging to properly
understand the type of API variables. Many of the regressions we have
seen are fundamentally type errors. I hope we can agree that strong
typing through documentation has proven to be an unattainable goal.
We'll have to see where FF ends up with this. David Teller says "Fwiw,
we are currently trying to come up with a strategy to use either Flow,
TypeScript or Google Closure Compiler (which also performs type-checking
on JS) on our codebase." Thunderbird will probably end up following
whatever path Mozilla decides is appropriate for FF.

Yet Thunderbird is fundamentally different than Firefox, in that their
goal is to be the equivalent of an operating system, while we are
clearly an app. We should not follow if they move in directions that
don't allow us to move our backend toward using more web technologies
(such as if they write the FF frontend in Rust as is one proposal). My
long-term dream for Thunderbird is that we can be a universal personal
information and communication platform, that can be used in all of the
standard contexts that people expect (desktop, web, and mobile). The
only hope of achieving that is through using web technologies as the
basis for what we do.

In the last couple of years, our coding energy has been expended on
fixing regressions and long-standing annoyances in our app, while trying
to keep up with the flood of breakages coming from the m-c world. Yes we
need to do all of these things, and we are barely keeping afloat as it
is. But I hope at some point we can start to look beyond that. I'm
considering personally a few directions for next year, and I hope that
some of you can also start considering more fundamental changes that
would move us forward.

Possible personal directions (and you are welcome to join in if interested):

1)    Develop a new message summary database that would be off main
thread and async, written as a JS worker using indexed DB. (Thanks to
jcranmer for the basic concepts of this). As part of that, message MIME
processing needs to be done for all incoming messages, and the results
included in that database.

2)    Leverage the new JsAccount technology to develop a few new main
account types. One promising direction is using gloda or twitter
searches as first-class folders.

3)    Take the Contacts work currently being done by students in New
Zealand, and leverage that into a demo of using our technologies to
develop a universal app. That is, it should be possible to use a
standard contacts codebase to to make a contacts app usable as: 1) the
address book subsystem of Thunderbird, 2) a standalone desktop contacts
app, 3) a mobile contacts app (perhaps using the Progressive Web App
technology that elevates a web app to be a first-class mobile app), and
4) a website. This is partly intended to be a demo of how Thunderbird
could be deployed in a similar manner.

Relating this back to the current FF discussions, I'm hoping that they
will zero in on an appropriate technology for large-scale app
development that we can live with (like TypeScript for example) and that
we can quickly adapt this as our standard, so that as we move forward we
will have viable tools that will not fail us as we scale up.


More information about the tb-planning mailing list