Followup: modularity, WebExtensions, and going faster

[Dan Mosedale]

2016-10-12 8:26 GMT-07:00 Gijs Kruitbosch <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/
> 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.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161012/b1ea16eb/attachment.html>