Followup: modularity, WebExtensions, and going faster

[Gijs Kruitbosch]

On 12/10/2016 16:44, Dan Mosedale wrote:
> 2016-10-12 8:26 GMT-07:00 Gijs Kruitbosch <gijskruitbosch at gmail.com 
> <mailto:gijskruitbosch at gmail.com>>:
>
>>     If you look, again, at session restore you will have to go
>>     through all of them and it is far from being obvious and will
>>     feel very hard to approach to anyone except mozilla employees who
>>     have to learn all these things. Web extension abstracts all that.
>>     The difference between a content script and a background page is
>>     very small.
>>
>>      1. 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?
>>
>>     Session restore?
>>     http://blog.techno-barje.fr/post/2016/03/14/session-restore-web-extension/
>>     <http://blog.techno-barje.fr/post/2016/03/14/session-restore-web-extension/>
>>     The big advantage to this particular feature is that it doesn't
>>     involve much UI, which is where WebExtension is the most limited.
>     ... but then, is avoiding the UI problem really going to be
>     helpful in the future? How do we transition the experience from a
>     hypothetical successful session restore add-on to other frontend
>     features if we haven't solved that problem? And, most negatively,
>     how do we avoid that becoming boundary type number N + 1 (after
>     XPCOM, JSM, XBL, message managers, system add-ons, ...) that we
>     then don't get rid of and have to teach every contributor
>     (employee or volunteer)?
>
>
> ​The thing that doesn't seem to have yet been called out in this 
> discussion is the difference between technologies that are local-only, 
> versus ones that have broad documentation and support on the web at 
> large (WebExtensions is arguably such a one).
>
> It seems like some of the real wins going forward involve 
> opportunistically aligning ourselves with existing larger stable 
> development technologies/communities (presumably mostly from the 
> web).  (E.g. incrementally migrate from JSMs to CommonJS). Part of the 
> trick here is to, over the longer term,
> slowly let go of old proprietary technologies that are only known 
> here, in favor of technologies known to large swaths of the 
> web-development community, and broadly supported in common tooling.
>
> An example of this is that most (many? all?) of the various Firefox 
> sub-projects that use React have used mocha/chai/sinon for unit 
> testing. Execution is at least an order of magnitude faster than any 
> of the test frameworks commonly used in-tree, it's well-supported, 
> constantly updated, has lots of interesting build tooling integrations 
> in most IDEs and even in eslint, runs headless, etc.
Aligning ourselves with the web is a good goal, IMO, but seems 
problematic with WebExtensions. WebExtensions, its async-ness, and its 
lacking support for actual UI creation, and interfacing with related UI 
on a single main thread with multiple async components, is (to the best 
of my knowledge) not a solved problem**. Then there's all the stuff 
about exposed vs. internally used API surfaces. Using React for the 
internal implementation of the frontend components would be 
better-understood (even if I'm personally not a massive React fan...).

The problem then would be how to integrate it piecemeal into the main 
Firefox UI and replace UI components, how to prioritize that work (which 
will wholesale break lots of add-ons) and of course whether having the 
entire thing in react (with flux or redux or whatever the latest thing 
is called) is the right choice (from the outside, it seems like the 
reactjs world uses a different toolset every 6 months, so picking 
something and sticking with it may not be the easiest thing) and how to 
make sure perf is acceptable (where a lot of our perf measurements right 
now rely on the infra we have, and so we'd have to rewrite them into 
something that works both before + after the conversion in order to 
compare things, etc.). Those are all solvable problems, but there would 
need to be a commitment that people want to invest in this, and broader 
agreement on tools and direction.

As for testing, it's not clear to me that those frameworks would be 
usable for privileged toplevel browser window stuff, which is the 
primary way we use mochitests these days***. Happy to be proven wrong. 
Note that mochitests were also originally adapted from web things - the 
mocha/chai/sinon of yesteryear, if you will - the important part being 
"adapted". We can do the same thing here, but the idiosyncracies are 
going to be "a little weird" today, worse in 2-5 years, and we'll like 
throw "well-supported" and perhaps some of the tooling integrations out 
of the window. In other words, not sure if that problem won't be 
reoccurring in due time irrespective of what unittest framework we 
decide on today.

~ Gijs

** I know someone upthread mentioned transactionality. I don't buy that 
that solves the problem I flagged up. Happy to discuss that more, but 
not sure pigeonholing the discussion into that direction is helpful, so 
not going to do that here.
*** mochitest-plain used to be mostly used by platform, but AIUI these 
days they use web platform tests, so I don't think we're actually 
creating many new mochitest-plain tests.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161012/94747aba/attachment.html>