Followup: modularity, WebExtensions, and going faster

[Gijs Kruitbosch]

Yes, you can implement webidl things in JS. However, you can't have a 
JS-implemented static WebIDL component: 
https://bugzilla.mozilla.org/show_bug.cgi?id=863952 . This means that 
things that we do with JSMs or js-implemented (singleton) XPCOM 
components right now are usually not easily portable to WebIDL.

~ Gijs

On 12/10/2016 17:36, David Teller wrote:
> 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
>>
>>