Followup: modularity, WebExtensions, and going faster

[Gijs Kruitbosch]

On 12/10/2016 15:53, David Teller wrote:
>
> On 12/10/16 16:45, Mike Conley wrote:
>> I'm trying to synthesize what I've read in this thread. I'm focusing
>> more on the modularity subject, and less on things like tools for
>> ensuring type-correctness or anything like that.
>>
>> Here's what I'm reading:
>>
>>   1. It might be worth considering re-implementing some browser
>>      components using WebExtensions. This would likely involve adding
>>      new, probably privileged APIs.
>>   2. The current set of modules, as they're defined, may not be optimal
>>      these days. rnewman brought up a few examples of where our current
>>      module definitions / boundaries hurt us, confuse things, and / or
>>      slow us down (Satchel and Password Manager was one such example).
> There is also a discussion on whether we should base our "new" modules
> on WebExtensions on something else.
>
> So far, I have seen some suggestions of using Rust as a "something
> else", but I believe that this is something of an implementation detail
> at that stage.
>
>> Here are my thoughts. Hopefully I'm not repeating other people here!
>>
>>   1. XPCOM / XPIDL, for better or worse, offered a boundary and interface
>>      system. I think those interfaces were originally intended to be
>>      pretty stable. Down the line, I seem to recall us deciding that
>>      having frozen interfaces there was slowing us down, and so now those
>>      interfaces are changed at will. I understand that we were more
>>      constrained because more applications were relying on the underlying
>>      interfaces, but this all starts to feel kinda familiar. Are we at
>>      risk of creating a new set of interfaces and silos that get holes
>>      poked through them over time because they slow us down instead of
>>      speeding us up? Are we repeating ourselves? If so, what did we learn
>>      last time that will make this time better?
> Good question. In my experience, the main issues with XPCOM/XPIDL are as
> follows:
>
> - in practice, we exposed everything as public, something we want to avoid;
Right, but this is independent of the technology you use. If we expose 
the Rust/WebExt stuff to external people (so e.g. add-ons can implement 
a replacement location bar) then we're still going to have that problem.

> - given the granularity, frozen interfaces was a momentum killer but
> unfrozen interfaces was an extensions killer;
Yuuup. Hard decisions are hard.

To me, it felt like webextensions (and before that, the SDK) were an 
attempt to have a secondary API layer that you used for add-ons, and 
your own inter-modular-code could be as unfrozen as you liked. This by 
definition means that you can't/shouldn't use said secondary API layer 
for your own stuff because then you're back to square 1 where our own 
code and add-ons share the same API layer and now everybody is sad.

> - also, the resulting types (and error messages) are very un-JavaScript-ish.
Our JS bindings for XPCOM could be (have been) better. WebIDL is already 
better in that respect, but isn't really geared to JS-based 
*implementations* (rather than consumption) of static/singleton things, 
which is part of why it's (IMO) underused today in frontend-land.

~ Gijs