FF modularity discussion and Thunderbird backend

Mark Rousell mark.rousell at signal100.com
Thu Oct 13 19:04:03 UTC 2016


On 12/10/2016 17:36, R Kent James wrote:
> 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
> https://mail.mozilla.org/pipermail/firefox-dev/2016-October/004639.html
> "Followup: modularity, WebExtensions, and going faster"

I have been following the discussion in firefox-dev with great interest.
It's quite informative to this non-Mozilian (only Mozilla-using) person.

> 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.

I feel a little presumptuous commenting on Thunderbird/FF internals (not
least because I'm not a competent JS programmer) but it seems to me that
there is no need to wait for FF to lead the way on this. Surely there's
no reason not to use, say, Typescript starting now.

> 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.

That's very interesting and also effectively what I'd love to see,
although I believe that I differ from you on how I think it is most
likely to be achieved. For example, would it be more resource-efficient
to develop or fork something like K-9 instead of porting Thunderbird to
mobile? And I am sure that we differ in the role of chargeable services
and/or software.

> 4) a website. This is partly intended to be a demo of how Thunderbird
> could be deployed in a similar manner.

I've been involved in a project (unrelated to Thunderbird) that is
intended to work in this manner, i.e. be able to work on
desktops/laptops and as a web application, complete with extensions that
don't care if they are running locally on the desktop or in a browser.
>From what I understand of Thunderbird, it's surely a long, long way from
being able to do that. Many of the same problems that are facing Firefox
face Thunderbird in this context, such as (a) Thunderbird's UI is not
encoded in HTML and (b) and moving to HTML (as well as all the other
changes needed at the same time) will break extensions. And backward
extension compatibility really, really matters for Thunderbird (and
Firefox in my opinion).

Also a possible fifth direction: Improved HTML composer. I feel somewhat
guilty mentioning this since I can't really contribute (I'm more
familiar with C# and not JS or C++) but TB is crying out for it I think.

> 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.

But... my impression is that whatever technology they go for will result
in a very different Firefox to the one that exists today. Will it be a
suitable technology basis for a PIM/mail client? Perhaps a brand new one
but for Thunderbird? I hate to sound like a dreadful stick in the mud
but extension compatibility seems to me to be crucial for Thunderbird's
ongoing survival but extension compatibility is not high on the list of
importance for anyone at with a @mozilla.com address.


I've been dithering about posting the following anywhere public but here
and now seems reasonable. It is less about TB planning and more about
observations following on from the discussion in firefox-dev (although
the ramifications of the observations do affect TB). Apologies if it's
off-topic here. Also bear in mind that it is written from the point of
view of a member of the public, a Mozilla-user, someone looking from the
outside in.

(1) The thread is not just about modularity or WebExtensions but about
going faster (i.e. faster development), the implicit assumption being
that faster = better and is necessary. As a user (and developer of
software in other contexts) I can only say: Good grief, slow down.
Whilst a glacial development pace is of course to be avoided, there is
such a thing as too fast. I'm hardly the only person to think that
Firefox's development cycle is way too manic now. The unwritten
assumption seems to be that they are in some kind of race with Chrome
but, no, it seems to me that they are only in a race with themselves
from what I can see.
(2) The thread has shown me that there seems to be a lack of strategic
architectural vision in Mozilla. This greatly surprises me. I get the
impression that the issues being discussed, whilst clearly not new to
anyone, have not been discussed in such detail before. Apparently no one
has set a strategic vision and development path, allowing everyone else
to actually get on and implement it. How odd when the issues at hand are
so fundamental. My perception as an outsider is that that is
representative of a failure of leadership.
(3) Public group discussion about strategic direction is admirable,
open, and healthy. I applaud it. BUT... if you have such discussions in
public, take on board end user input and be prepared to absorb it and
change direction to implement it. Only one or two non- at mozilla.com
contributors have taken part in the thread and, apart from the ones
clearly known to the @mozilla.com contributors, I seem to recall that
their input has been pretty much ignored.
(4) The idea of writing the entire browser in WebExtensions.
Notwithstanding the work I understand has been done on an experimental
WebExtension-based browser by Alexandre Poirot, get over it! This is a
symptom of a common problem in software development: An obsessive focus
on the latest fad, even when that fad is entirely unsuitable or
irrelevant for the job at hand (or needs massive and non-standard
development in its own right to get it even close to being suitable).
(5) And extensions in general. Oh, another user whining on about
extensions. Yup, here goes. Now, I realise that the discussion is not
about extensions per se and is instead about fundamental development
directions and choices of underlying technology but this nevertheless
has an impact on extensions and what they can and cannot do. It is clear
that @mozilla.com contributors see extensions as a secondary level of
infrastructure. I can appreciate that from their particular
perspectives. But from a marketplace perspective, it's suicidally
inward-looking. There is a reason that businesses like Microsoft and IBM
place a massive amount of importance in backwards compatibility. Whilst
one might argue that Mozilla is different because it doesn't /sell/
software, I don't think the differences are all that great. Mozilla's
stated mission and existence depend on more people, not fewer, using
their software, and yet extensions are, or were, Firefox's key USP in
the marketplace. The focus on WebExtensions as an extension mechanism
(notwithstanding the outsider, Giorgio Maone's, native.js proposal) is
severely damaging to Firefox's USP and thus, eventually, to Thunderbird
(taking the other likely architectural changes being discussed into
account). The very fact that the future of what WebExtensions might or
might not be able to do is not yet decided and set out as a firm
strategic plan with migration guidelines set out over a stated timeframe
is a symptom of the lack of strategic leadership I noted in point 2.
It's worse because it's not just an internal lack of vision; it was and
is a lack of public/user communication and a demonstration of a
fundamental lack of understanding of the concerns of the Firefox-using
market (in other words, a company that intends to be open and inclusive
seems, from the outside looking in, to have lost sight of what very many
of its users want and are clearly saying they want).

Perhaps I should have posted the above observations/comments in
firefox-dev. However, the observations don't add anything to the
direction that the discussions are taking and I'd be seen as (a)
criticising the discussion itself, which is not my intention at all, or
(b) making criticisms which are outside of the the scope of the
discussion, which would be true.

-- 
Mark Rousell
 
 
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20161013/3ca72b82/attachment.html>


More information about the tb-planning mailing list