Followup: modularity, WebExtensions, and going faster

[Gijs Kruitbosch]

On 12/10/2016 13:29, David Teller wrote:
> On 12/10/16 13:33, David Bruant wrote:
>> Microsoft faced the challenge of writing large JavaScript applications.
>> They ended up inventing TypeScript for this very purpose. Facebook
>> followed a couple of years later with Flow. Both have differences, but
>> in practice the differences are barely noticeable as far as I'm concerned.
>> Note that the Firefox devtools team is already using Flow
>> https://github.com/devtools-html/debugger.html
>>
>> Because of JavaScript limitations and "culture", the type system of
>> either with never be as expressive as the Rust type system can be.
>> However, I've never heard of it as an strong argument to move away from
>> TypeScript or Flow.
> 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.
>
> Of course, the tools only makes sense if we have clean, well-designed
> APIs, so the discussion on WebExtensions (or alternatives) is still on.
>
> So far, from this discussion, I have parsed the following proposals:
> - [customized] WebExtensions (which intends to answer the question "how
> do we present the APIs?");
> - Rust (which intends to answer the questions "how do we implement the
> APIs"/"how do we encourage APIs to be well-typed");
> - don't change anything (which, in my books, doesn't answer any question);
Being able to do type checking is orthogonal to using WebExtensions for 
browser features.

If you could convince people that it's worth annotating all the existing 
JS in browser/ and toolkit/ with these types, you could do that today. 
Heck, you could probably use IDL and WebIDL data to infer some of the 
types automatically already. Either way, none of that requires the much 
larger effort of switching to either Rust or WebExtensions.

I'll note that you're assuming that we all agree type checking is going 
to add significant value, and in particular that that value outweighs 
the costs of switching technologies to Rust or WebExtensions, or the 
cost of annotating all our existing code. However, you have provided no 
evidence for that view.

Finally I'll note that the existing WebExtensions APIs are very very 
very far from enough to write a browser with. Benjamin already 
acknowledged this. We would need to write new ("proprietary" in the 
not-specced/in-general-web-use sense) APIs. The implementations of 
WebExtensions APIs are not currently type-annotated (that I've been able 
to see when reviewing them, anyway), and so AFAICT "switching to 
WebExtensions" would just be shifting the annotation problem to the 
layer that implements such new APIs.

All of this is of course on top of the fact that significant sets of our 
"APIs" (using the term very loosely) are implemented in XBL and XUL, and 
none of TypeScript/Flow/... know how to deal with that.


In summary, I'm sympathetic in principle to wanting to do more static 
checking on our codebase, but I think "rewrite all the things in other 
technology X" is the wrong starting point for achieving that goal. There 
might be other reasons why (progressively) rewriting stuff is desirable, 
but I don't think requiring that rewrite for the static checking is an 
expedient way of getting the static checking, nor does wanting static 
checking per se justify a rewrite.

~ Gijs