Followup: modularity, WebExtensions, and going faster
Brendan Barnwell
brenbarn at brenbarn.net
Fri Oct 7 02:14:17 UTC 2016
On 2016-10-06 16:41, Robert Helmer wrote:
> 1) WebExtensions currently don't (and Chrome likely never will) allow
> modification of the UI beyond a few very limited things like adding
> toolbar buttons, maybe things like menu entries in the not-too-distant future.
This is critical, and for me it touches on one of the most fundamental
issues: the functionality of the product is more important than the ease
of development, and WAY more important than the speed of the release
cycle. The starting point needs to be functionality, and then dev
process and speed need to accommodate to that. (Another comment on this
thread re the necessity of consistent ordering between things like the
URL and the selected tab points in a similar direction.)
As far as functionality, I am apprehensive. To my mind, the move to
WebExtensions has already cost Firefox a massive amount of credibility
because it is essentially breaking all existing extensions. If
"doubling down" on this means more blocking off the ability to provide
useful functionality (and breaking existing functionality) in order to
make it easier to provide a severely limited range of functionality, I
don't see that as a benefit. It's like running a sandwich shop and
deciding you're going to make sandwiches faster by just giving everyone
two slices of bread instead of a sandwich.
As far as speed, I'm also apprehensive, because I think the drive to
"go faster" is fundamentally misguided. I would rather have a browser
that releases one coherent, well-designed version a year than a browser
that releases a gazillion tiny upgrades, some of which may break the
workflow I've developed with my existing extensions.
So, basically, I just think the starting point needs to be "what do we
want the browser (and extensions) to be able to do". If everything that
needs to be done can be done with WebExtensions, great. If not, it's
better to back off on WebExtensions than to deliver a crippled product.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
More information about the firefox-dev
mailing list