Followup: modularity, WebExtensions, and going faster

[Richard Newman]

>
> Simple bugs cannot be fixed easily because of gazillions of unexpected
> dependencies. … Having clearer boundaries inside our own code is critical,
> too.
>

To address just this little part (again): lots of interactions and close
behavioral coupling between two modules is — in the absence of lazy design,
which I don't think is our problem — an indicator that after years of
evolution those module boundaries are drawn in the wrong place.

(That's totally normal, but I think our codebase's emphasis on modularity
has if anything made the problem worse, not better.)

I think Sync and Places (and Satchel, and pwmgr, and…) are a great example
of this: with the benefit of hindsight, having Sync and Places be totally
separate modules — indeed, Sync started off as a separate add-on: very Go
Faster! — with Sync trying to track very low-level Places changes via
observer notifications, is/was entirely the wrong thing to do. Syncing is a
cross-cutting concern.

We flipped this around on iOS, with storage exposing very narrow APIs to
the front-end and taking on the burden of tracking changes for Sync.
Tightly coupled, deliberately very constrained… but small, correct, and
simple. The module boundaries are drawn between front-end and storage, not
between bookmarks and Sync tracking.

I betcha there are other cross-cutting concerns, too, and I'm curious which
other ones people see. Perhaps with the advent of rAC and fancy form fill
we wish we didn't have a division between form fill and password
management? Maybe we wish the favicon service were more general to support
page summaries and tiles?

So yes, clearer boundaries — but they should probably not be the boundaries
we have now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161010/9ef1fffb/attachment.html>