Followup: modularity, WebExtensions, and going faster

[Richard Newman]

>
> What isn't clear to me is where exactly do we draw the line for API
> support? It's cool to say that awesomebar, bookmarks, session store, etc
> are loosely coupled and independently hackable - this sounds great from an
> ivory tower. But the cobweb of inter-dependencies between all these
> components exists for a reason: it was/is necessary to implement features.
>

To echo this: in the past couple of years my opinion is starting to settle
that Firefox's vertical component architecture is obsolete in many
respects. We very rarely (in my experience, at least) can limit our work to
"behind the curtain", wherever that curtain happens to be.

Speaking very superficially, most of the interesting problems occur between
components, much of the rest involves poking at components as if they were
bad POJOs, and much of what we can do (and *think* to do) is limited by the
artificial boundaries put in place.

If we split apart Firefox along its existing lines, we will get more of
what we've got, perhaps faster.

Choosing some different lines will give different results. For example,
right now we wouldn't really think to, e.g., up-weight awesomebar results
for which we have a saved password, because those two data sources are
about as siloed as you can get, and it would be a huge pain in the ass to
integrate the two from calling code. At an even greater extreme,
implementing decent atomic sync of all browser data sources in the current
model is essentially an impossibility, because there's no part of the
browser that even pretends to consider them holistically.

My very opinionated position, then, is that putting effort into making
Firefox's existing modularity structures "*even more so"* is not just a
waste of time, but actively counterproductive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161006/4df74691/attachment.html>