Followup: modularity, WebExtensions, and going faster

[Mike Conley]

I'm trying to synthesize what I've read in this thread. I'm focusing more
on the modularity subject, and less on things like tools for ensuring
type-correctness or anything like that.

Here's what I'm reading:

   1. It might be worth considering re-implementing some browser components
   using WebExtensions. This would likely involve adding new, probably
   privileged APIs.
   2. The current set of modules, as they're defined, may not be optimal
   these days. rnewman brought up a few examples of where our current module
   definitions / boundaries hurt us, confuse things, and / or slow us down
   (Satchel and Password Manager was one such example).

Here are my thoughts. Hopefully I'm not repeating other people here!

   1. XPCOM / XPIDL, for better or worse, offered a boundary and interface
   system. I think those interfaces were originally intended to be pretty
   stable. Down the line, I seem to recall us deciding that having frozen
   interfaces there was slowing us down, and so now those interfaces are
   changed at will. I understand that we were more constrained because more
   applications were relying on the underlying interfaces, but this all starts
   to feel kinda familiar. Are we at risk of creating a new set of interfaces
   and silos that get holes poked through them over time because they slow us
   down instead of speeding us up? Are we repeating ourselves? If so, what did
   we learn last time that will make this time better?
   2. Surely we're not the first large application that's had to grapple
   with this kind of design decision. Are there any success or failure stories
   from outside of Mozilla that we can draw inspiration or lessons from?
   3. Is there a browser component that we can experiment with, and attempt
   re-implementing with the WebExtension API to see how it feels? Or, to take
   rnewman's angle here, is there an opportunity here to draw some new
   boundary lines and define a new (but small) WebExtension Thing that
   combines capabilities from several of our current modules for great good?

-Mike

On 12 October 2016 at 10:04, David Bruant <bruant.d at gmail.com> wrote:

> Le 12/10/2016 à 14:41, Gijs Kruitbosch a écrit :
>
>> 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.
>>
> Annotating all the existing JS is not a requirement to use TypeScript or
> flow (IIRC Google Closure Compiler is a different story).
> Interesting blog post from 2013 of someone switching a 100kLOC lib:
> http://news.turbulenz.com/post/47457658846/mostly-painlessly
> -migrating-a-3d-game-engine-to
> "The first step I took was to simply rename each of our .js files to .ts
> and create a trivial build step to convert the each of these new .ts files
> to JavaScript [with the typescript compiler].
> The advantage of this apparently trivial step was that regular development
> could continue while we gradually expanded the type definitions in the same
> files.  This approach is only really viable because TypeScript extends
> rather than replaces JavaScript, and it’s actually very important."
> Now, TypeScript has a --allowJs option which makes that you don't even
> need to rename the files anymore. I'm sure it's the same for flow.
>
> Anyway, given TypeScript does type inference, "switching" to TypeScript is
> merely using the compiler to report error and do nothing else (--noEmit
> option) without having to annotate anything.
> As a side note, it still surprises me that most JS projects (front-end or
> Node) don't use the Typescript (or flow) compiler. It just takes running it
> on normal JS code to have errors reported for free with no consequence;
> errors that are not reported by any other tool.
>
> Now, to fully benefit from the static type checking, annotations are of
> course the way to go, but they can be added gradually over time. From
> experience, it's not a bad exercice and can be seen more as a welcome form
> of documentation. "Documentation" that is run against the code and that the
> compiler invites you to fix when the code changes.
>
> David
>
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161012/10826cc9/attachment.html>