[callahad]

My response was solely critiquing an exchange which ended up looking like:

    if (requestFeature(x)) { complain(); } else { complain(); }

That flow doesn't get anyone to a better place, but there are tons of ways to refactor it into productive dialogue. Let's do more of that.

I promise you that I legitimately do hear the frustrations felt by long-time power users of Firefox. I don't agree with all of them, but I do my best to represent them internally nonetheless. To your concerns regarding stable APIs: that's exactly what WebExtensions are designed to address: decoupling add-on APIs from implementation details so that we can keep add-ons working, even as we refactor Firefox to be faster, more stable, and more efficient.

[alphapapa]

> To your concerns regarding stable APIs: that's exactly what WebExtensions are designed to address: decoupling add-on APIs from implementation details so that we can keep add-ons working, even as we refactor Firefox to be faster, more stable, and more efficient.

Ok, that sounds nice, but is this yet another extension API that does it Chrome-style, restricting extensions to a solitary button in a solitary toolbar, rather than giving them the freedom to truly extend the browser and its UI? Because if I wanted handicapped extension APIs, I'd just use Chrome.

And besides, isn't that what Jetpack was supposed to be? How long until the next extension API that will get it right This Time?

One of the foundational pillars of Firefox is its powerful extension API, however messy and difficult-to-refactor it may be. Take that away, and it's just another browser, no better than Chrome.

[callahad]

> How long until the next extension API that will get it right This Time?

WebExtensions are likely to be The One True API. Chrome, Opera, Edge, and Firefox all support them, and we're all working on standardizing them at the W3C: https://www.w3.org/community/browserext/

> If I wanted handicapped extension APIs, I'd just use Chrome.

Though we're trying to avoid reinventing wheels, we're not limiting ourselves to Chrome's APIs. For example, https://bugzil.la/1242871 extends Chrome's webRequest API to provide additional metadata needed by the NoScript and RequestPolicy add-ons. The initial development is focused on Chrome parity, since that covers most add-ons, but once we get there you'll see more of an emphasis on landing APIs that are needed by existing, more powerful Firefox add-ons.

If you're an add-on developer yourself and are concerned about APIs you need, please fill out this survey so we have a record of it: https://docs.google.com/a/mozilla.com/forms/d/1PtRXcs9UHVMjg...

[alphapapa]

> If you're an add-on developer yourself and are concerned about APIs you need

I'm actually not, and one reason is because I've seen over the years how extension authors have to keep up with the churn constantly breaking things, and that's not a pool I want to wade into. I'm amazed that, e.g. the Pentadactyl authors have the time and patience to do so.

So, if this new API stabilizes things long-term, that's fantastic. I would love to have extensions that never break again.

But forgive me for being skeptical, because with the CADT-style development models ruling the world nowadays, what usually happens is, the old API is deprecated and dumped before the new one has feature parity, leaving authors and users hanging. And with Mozilla's trend of imitating Chrome, this seems even more likely.

I can hear the cries now of, "The old API is too hard to maintain, so we're removing it in Firefox 72. We hope to reach approximate feature parity by Firefox 84, but we do not plan to reimplement all features in the new API. Regrettably, this will prevent some addons from being ported to the new API," with the implied, "But 'no one' [compared to the number of users on the Internet] was using those addons anyway, so who cares." And cue me switching browsers.

Please prove me wrong. :)