Followup: modularity, WebExtensions, and going faster

[Richard Newman]

>
> Would Firefox then be a very basic "core" browser, implemented in
> HTML/CSS/JS, with extensions for adding features on top of this
> ("awesomebar", bookmarks, devtools, etc?)  If so then the "core"
> browser needs to implement WebExt APIs for each feature to use,
> possibly with a "mozilla-only" permission if it's something we
> wouldn't want third-party extensions to be able to do?
>

My big fear about this is that the choices we would make with those APIs
essentially define the pillars of the application for years to come.

Good luck building anything novel on top of chrome.bookmarks, which
hard-codes the existence of "Bookmarks Bar" and "Other Bookmarks", is
strictly hierarchical, can't be transactionally changed alongside a
different data source, etc.

(Heck, good luck building the awesomebar on top of Chrome's bookmark and
history APIs.)

And think we have trouble moving fast now? Try hard-coding and publishing
an interface that you can't evolve without breaking all UIs built on top!

IMO it's a mistake to treat all interfaces as equal and public, which seems
to be the point of the WE side of this discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161010/7ecad4ab/attachment.html>