<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 07/10/2016 à 23:48, Gregory Szorc a
écrit :<br>
</div>
<blockquote
cite="mid:CAJTgH0mLMND95Z1xmhAxJaeR_31ruw1WAiVx7ustwzBvbDv5eQ@mail.gmail.com"
type="cite">
<div dir="ltr">3) If we're talking about a significant change of
architecture to the Firefox frontend and the high costs
associated with that change, I'll throw out an alternative idea:
(re)write the frontend in a typed language like Rust. I argue
that a typed language - and Rust especially - would deliver
"well-defined, documented, and enforced module boundaries or
interfaces" better than JavaScript ever will.<br>
</div>
</blockquote>
Le 08/10/2016 à 00:12, Robert Helmer a écrit :<br>
<blockquote type="cite">+1. I think we should probably stick with
HTML/JS/CSS for basic UI<br>
stuff like layout, setting up button events, DOM manipulation etc,
but<br>
a lot of the code we have in JSMs right now would be much safer to<br>
implement in Rust, and most likely faster.</blockquote>
Microsoft faced the challenge of writing large JavaScript
applications. They ended up inventing TypeScript for this very
purpose. Facebook followed a couple of years later with Flow. Both
have differences, but in practice the differences are barely
noticeable as far as I'm concerned.<br>
Note that the Firefox devtools team is already using Flow
<a class="moz-txt-link-freetext" href="https://github.com/devtools-html/debugger.html">https://github.com/devtools-html/debugger.html</a><br>
<br>
Because of JavaScript limitations and "culture", the type system of
either with never be as expressive as the Rust type system can be.
However, I've never heard of it as an strong argument to move away
from TypeScript or Flow.<br>
<br>
Given the advances of JS perf engines the last few years, and things
like asm.js and coming primitives low-level like shared memory
(which Firefox is the only one to ship under flag at the time?),
there are enough options on the table so that language-level
performance should not be an argument to switch language.<br>
<br>
<br>
<blockquote
cite="mid:CAJTgH0mLMND95Z1xmhAxJaeR_31ruw1WAiVx7ustwzBvbDv5eQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>4) I have significant concerns about the concept of
system add-ons. Currently, the composition of Firefox (in
terms of code) is essentially deterministic from the
commit in mozilla-central it was built from. We know
exactly what Firefox code is running (OK, /should/ be
running) on users' machines. System add-ons fundamentally
change that from ~1 combination of software components to
N, where N could be absurdly large (10^3 or larger). It is
hard enough to track down intermittent failures in test
automation with a well-defined software configuration.
System add-ons introduce whole new classes of bugs related
to how different versions of add-ons interact with each
other.</div>
</div>
</div>
</div>
</blockquote>
I lack the proper experience to answer this point with appropriate
authority, but I'll try to say something relevant anyway.<br>
I think the idea is that the point of system addons is to find parts
of the system that do not interact with one another but only with
the Web Extensions API. In that context, the combinations should not
matter, only the WE boundary and how the addons interact with it.<br>
Whether this idea is wishful thinking or plausible is the heart of
the debate.<br>
<br>
Another question is whether the Web Extensions API is the proper
boundary. It's misdesigned in many ways (some I would consider
major) and allows too many interactions between addons by default.
Maybe a tighter API would be a better start to reduce the potential
of bad interactions.<br>
<br>
David<br>
</body>
</html>