Followup: modularity, WebExtensions, and going faster

[Andrew McKay]

The focus right now is tooling and development for add-on developers.
Another example is that we are soon going to be taking the schema from
Firefox and running it through tools like web-ext and AMO so
developers can have the same offline linting and validating tools that
Firefox does. But WebExtensions are currently focused on add-on
developers. What works there may not work for other developers, unless
you take the approach that all developers are add-on developers.

I count myself a relatively numpty in Firefox development, so I am
curious... we've tried all this before right? There are already
multiple layers of modules, schemas and all other kinds of things
throughout Firefox I believe. Why did those things work or not work
that WebExtensions might solve?

On 6 October 2016 at 19:14, Brendan Barnwell <brenbarn at brenbarn.net> wrote:
> 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
>
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev