<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 12/10/16 17:44, Dan Mosedale wrote:<br>
<blockquote type="cite"
cite="mid:CABQdK3aPuNs3DzXf4vtaViMgTOV5pVx4cPqUat6HTFev=XSTTQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">2016-10-12 8:26 GMT-07:00 Gijs
Kruitbosch <span dir="ltr"><<a
href="mailto:gijskruitbosch@gmail.com" target="_blank"
moz-do-not-send="true">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
href="http://blog.techno-barje.fr/post/2016/03/14/session-restore-web-extension/"
target="_blank" moz-do-not-send="true">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>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
I think we need to have a bigger conversation about React.<br>
<p>IMHO, React makes a lot of statements that are very related to
the statements that XUL made 15 years ago.</p>
<p>The core statement might be "HTML can't fly". Back then,
mozilla's answer was XML. Facebook's answer today is javascript.</p>
<p>The impact on HTML of both is the same though, it constrains HTML
from winning.</p>
<p>Axel<br>
</p>
</body>
</html>