Followup: modularity, WebExtensions, and going faster

Wed Oct 12 15:16:55 UTC 2016

>>  2. Surely we're not the first large application that's had to grapple
>>     with this kind of design decision. Are there any success or failure
>>     stories from outside of Mozilla that we can draw inspiration or
>>     lessons from?
>
>Good question. I don't know of any.

The BlackBerry 10 browser architected itself primarily as modules and
extensions in webtech in 2011-2012 (released January 2013). By increasing
the friction necessary to get at privileged APIs (because we didn't
autogenerate them particularly well, especially for complex types) we
ensured that most operations were completed through extending the support
of web standards and renderer performance.

That being said, it was developed rapidly by a small team to support one
platform and about six screen sizes, so I'm not sure how much of my
experience with it might be of use.

Feel free to pick my brains on the subject at your leisure, but to begin,
here's a couple lessons learned:

1) HTML+CSS in 2011 was a poor widget language. Encapsulating components
wasn't possible (Hello Custom Elements and Shadow DOM), but restyling
existing ones was spectacularly fruitful (webkit's stylability of form
components far exceeds gecko's to this day). Specifically, the DOM is a
general-purpose layout mechanism so a lot of performance shortcuts that can
be made in widget languages cannot be assumed by the renderer leading to
terrible slowdowns. If Firefox goes this route, it might benefit from
focusing on using CSS to hint at usage (overflow: hidden can be an explicit
intent. What I wouldn't have given to have will-change in 2011)

2) APIs are important. Components are important. JS wasn't particularly
happy with either. Component loading was a pain at startup. Strings are
heavier than you think. i18n has a deep cost. Simply scanning the JS off of
disk eats millis out of every user which adds up to hours at userbase scale.

3) A central architecture and design vision was paramount to accomplishing
what we did. Before the inter-component framework was put in place, work
circled as if in a sink drain. Before the lines had been drawn (albeit in
pencil) the frontend had no shape, only colour.

:chutten

On Wed, Oct 12, 2016 at 10:53 AM, David Teller <dteller at mozilla.com> 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;
> - given the granularity, frozen interfaces was a momentum killer but
> unfrozen interfaces was an extensions killer;
> - also, the resulting types (and error messages) are very
> un-JavaScript-ish.
>
>
> >  2. Surely we're not the first large application that's had to grapple
> >     with this kind of design decision. Are there any success or failure
> >     stories from outside of Mozilla that we can draw inspiration or
> >     lessons from?
>
> Good question. I don't know of any.
>
> >  3. Is there a browser component that we can experiment with, and
> >     attempt re-implementing with the WebExtension API to see how it
> >     feels? Or, to take rnewman's angle here, is there an opportunity
> >     here to draw some new boundary lines and define a new (but small)
> >     WebExtension Thing that combines capabilities from several of our
> >     current modules for great good?
>
> Have you looked at ochameau's experiment with WebExtension?
>
> See
> http://techno-barje.fr/post/2016/03/16/shipping-firefox-features-as-addon/
> and followups.
>
> Cheers,
>  David
>
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161012/c384c6a5/attachment.html>