<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/10/2016 16:44, Dan Mosedale
wrote:<br>
</div>
<blockquote
cite="mid:CABQdK3aPuNs3DzXf4vtaViMgTOV5pVx4cPqUat6HTFev=XSTTQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">2016-10-12 8:26 GMT-07:00 Gijs
Kruitbosch <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>></span>:<span></span>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div dir="ltr">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. <br>
<span>
<ol>
<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?<span
class="m_-5573870297602042182m_-4095819469811120818gmail-HOEnZb"><font
color="#888888"><br>
</font></span></li>
</ol>
</span></div>
<div>Session restore?<br>
<a moz-do-not-send="true"
href="http://blog.techno-barje.fr/post/2016/03/14/session-restore-web-extension/"
target="_blank">http://blog.techno-barje.fr/po<wbr>st/2016/03/14/session-restore-<wbr>web-extension/</a><br>
</div>
<div>The big advantage to this particular
feature is that it doesn't involve much UI,
which is where WebExtension is the most
limited.<br>
</div>
</div>
</div>
</div>
</blockquote>
... 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)?<span
class="m_-5573870297602042182HOEnZb"></span></div>
</blockquote>
<div><br>
<div style="font-size:small" class="gmail_default">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).<br>
<br>
</div>
<div style="font-size:small;display:inline"
class="gmail_default">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,<br>
</div>
<div style="font-size:small;display:inline"
class="gmail_default">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.<br>
<br>
</div>
<div style="font-size:small;display:inline"
class="gmail_default">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. <br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
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...).<br>
<br>
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.<br>
<br>
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.<br>
<br>
~ Gijs<br>
<br>
** 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.<br>
*** 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.
</body>
</html>