Followup: modularity, WebExtensions, and going faster

[Axel Hecht]

On 12/10/16 17: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.
>
I think we need to have a bigger conversation about React.

IMHO, React makes a lot of statements that are very related to the 
statements that XUL made 15 years ago.

The core statement might be "HTML can't fly". Back then, mozilla's 
answer was XML. Facebook's answer today is javascript.

The impact on HTML of both is the same though, it constrains HTML from 
winning.

Axel

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