Followup: modularity, WebExtensions, and going faster

[David Teller]

I have summarized in a previous post [1, 2] my thoughts about our
current XPCOM/XPIDL + jsm boundaries and what I expect from any
replacement boundaries. I believe that this addresses the key parts of
your response.

And yes, definitely, WebIDL APIs are more JS-friendly than XPIDL. I'm
pretty sure that they can be implemented in JS, fwiw. There is just the
problem that they are centralized, but for a clear and well-defined API,
maybe that's not a problem at all.

[1] https://mail.mozilla.org/pipermail/firefox-dev/2016-October/004684.html
[2] https://mail.mozilla.org/pipermail/firefox-dev/2016-October/004685.html

Cheers,
 David

On 12/10/16 17:13, Gijs Kruitbosch wrote:
>> 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
> 
>