Followup: modularity, WebExtensions, and going faster

[David Bruant]

Le 07/10/2016 à 23:48, Gregory Szorc a écrit :
> 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.
Le 08/10/2016 à 00:12, Robert Helmer a écrit :
> +1. I think we should probably stick with HTML/JS/CSS for basic UI
> stuff like layout, setting up button events, DOM manipulation etc, but
> a lot of the code we have in JSMs right now would be much safer to
> implement in Rust, and most likely faster.
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.
Note that the Firefox devtools team is already using Flow 
https://github.com/devtools-html/debugger.html

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.

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.


> 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.
I lack the proper experience to answer this point with appropriate 
authority, but I'll try to say something relevant anyway.
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.
Whether this idea is wishful thinking or plausible is the heart of the 
debate.

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.

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