<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 12/10/2016 17:36, R Kent James wrote:<br>
<blockquote
cite="mid:93e3c284-a706-1cf6-20cc-bdeff8ff1f2a@caspia.com"
type="cite">
<pre wrap="">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
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/pipermail/firefox-dev/2016-October/004639.html">https://mail.mozilla.org/pipermail/firefox-dev/2016-October/004639.html</a>
"Followup: modularity, WebExtensions, and going faster"
</pre>
</blockquote>
<br>
I have been following the discussion in firefox-dev with great
interest. It's quite informative to this non-Mozilian (only
Mozilla-using) person.<br>
<br>
<blockquote
cite="mid:93e3c284-a706-1cf6-20cc-bdeff8ff1f2a@caspia.com"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:93e3c284-a706-1cf6-20cc-bdeff8ff1f2a@caspia.com"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:93e3c284-a706-1cf6-20cc-bdeff8ff1f2a@caspia.com"
type="cite">
<pre wrap="">4) a website. This is partly intended to be a demo of how Thunderbird
could be deployed in a similar manner.</pre>
</blockquote>
<br>
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).<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:93e3c284-a706-1cf6-20cc-bdeff8ff1f2a@caspia.com"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
(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.<br>
(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.<br>
(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
<a class="moz-txt-link-abbreviated" href="mailto:non-@mozilla.com">non-@mozilla.com</a> 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.<br>
(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).<br>
(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 <i>sell</i> 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).<br>
<br>
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.<br>
<br>
<pre class="moz-signature" cols="72">--
Mark Rousell
</pre>
</body>
</html>