Followup: modularity, WebExtensions, and going faster

[Jared Hirsch]

Hi all,

I'd like to comment on the contributor-specific arguments made in
Benjamin's article, which seem to be:

- contributors struggle because of the module structure and poor APIs;
- contributors ask for better docs, but the docs are unavoidably bad
because the APIs are bad.

TL;DR: I think the bigger problem is poor docs, not poor APIs.

I'm a webdev, like many of our contributors. I work on the Test Pilot team,
where I've gotten a crash course in Gecko / addon development over the past
1.5 years, starting with building the Universal Search addon.

I'm used to working with a variety of less-than-perfect, evolving,
overlapping APIs; that's the Web Platform that webdevs know and love.
Inelegance is no barrier to contributing.

However, I'm also accustomed to having good learning resources: blog posts,
examples, API docs, and, if all else fails, a carefully-worded spec. And
this is where we, at Mozilla, fall short.

I've personally found that the XPCOM interfaces make sense, but I generally
have to read a *lot* of source code to learn how to use them.

Insofar as the WebExtension API proposal is intended to make life better
for contributors, I'd suggest investing in the docs instead.

Cheers,

Jared

On Mon, Oct 10, 2016 at 2:27 PM, Emma Humphries <emma at mozilla.com> wrote:

>
> On Mon, Oct 10, 2016 at 1:52 PM, Richard Newman <rnewman at mozilla.com>
> wrote:
>
>> 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.
>
>
> ​My experience has been with building front-end applications, and I can't
> say that it maps to WebExtensions.
>
> But this conversation reminded me of SoundCloud's talk at the 2013
> HTML5Conf on the pain of building your application on your public API, and
> it captures some of the problems we ran into when we tried rewriting
> WhiteHat's reporting tools on top of our public rest API.
>
> https://www.youtube.com/watch?v=W8B9xT1QRb0​
> ​
>
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161010/e905d454/attachment.html>