<div dir="ltr"><div>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.<br><br></div>Here's what I'm reading:<br><ol><li>It might be worth considering re-implementing some browser components using WebExtensions. This would likely involve adding new, probably privileged APIs.<br></li><li>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).</li></ol><p>Here are my thoughts. Hopefully I'm not repeating other people here!<br></p><ol><li>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?<br></li><li>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?</li><li>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?<br></li></ol><p>-Mike<br></p></div><div class="gmail_extra"><br><div class="gmail_quote">On 12 October 2016 at 10:04, David Bruant <span dir="ltr"><<a href="mailto:bruant.d@gmail.com" target="_blank">bruant.d@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Le 12/10/2016 à 14:41, Gijs Kruitbosch a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 12/10/2016 13:29, David Teller wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 12/10/16 13:33, David Bruant wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Microsoft faced the challenge of writing large JavaScript applications.<br>
They ended up inventing TypeScript for this very purpose. Facebook<br>
followed a couple of years later with Flow. Both have differences, but<br>
in practice the differences are barely noticeable as far as I'm concerned.<br>
Note that the Firefox devtools team is already using Flow<br>
<a href="https://github.com/devtools-html/debugger.html" rel="noreferrer" target="_blank">https://github.com/devtools-ht<wbr>ml/debugger.html</a><br>
<br>
Because of JavaScript limitations and "culture", the type system of<br>
either with never be as expressive as the Rust type system can be.<br>
However, I've never heard of it as an strong argument to move away from<br>
TypeScript or Flow.<br>
</blockquote>
Fwiw, we are currently trying to come up with a strategy to use either<br>
Flow, TypeScript or Google Closure Compiler (which also performs<br>
type-checking on JS) on our codebase.<br>
<br>
Of course, the tools only makes sense if we have clean, well-designed<br>
APIs, so the discussion on WebExtensions (or alternatives) is still on.<br>
<br>
So far, from this discussion, I have parsed the following proposals:<br>
- [customized] WebExtensions (which intends to answer the question "how<br>
do we present the APIs?");<br>
- Rust (which intends to answer the questions "how do we implement the<br>
APIs"/"how do we encourage APIs to be well-typed");<br>
- don't change anything (which, in my books, doesn't answer any question);<br>
</blockquote>
Being able to do type checking is orthogonal to using WebExtensions for browser features.<br>
<br>
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.<br>
</blockquote></div></div>
Annotating all the existing JS is not a requirement to use TypeScript or flow (IIRC Google Closure Compiler is a different story).<br>
Interesting blog post from 2013 of someone switching a 100kLOC lib:<br>
<a href="http://news.turbulenz.com/post/47457658846/mostly-painlessly-migrating-a-3d-game-engine-to" rel="noreferrer" target="_blank">http://news.turbulenz.com/post<wbr>/47457658846/mostly-painlessly<wbr>-migrating-a-3d-game-engine-to</a><br>
"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].<br>
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."<br>
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.<br>
<br>
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.<br>
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.<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
David</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/firefox-dev</a><br>
</div></div></blockquote></div><br></div>