[pauljohncleary]

Extensions are a form of vendor lock in, Google were killing Mozilla in that space because:

- network effects (chrome is more popular than ff)

- chrome extensions are so much easier to write than XUL ff extensions

Now webextensions are implemented in FF, it's incredibly easy to port extensions across (I ported one earlier this week, took about 20 minutes!)

Tree style tabs and all that jazz aren't going away yet.

It's a killer move from Mozilla and makes FF a first class citizen of the web again.

[Akkuma]

It isn't just that chrome extensions are easier to write than XUL ff extensions. It is also that XUL ff extensions are poorly maintained in various ways with more gotchas. Additionally, FF's extension signing was largely a mess and in less than a year we're transition from JPM to another build tool.

You can't even go from unlisted to listed on Firefox's addon site.

[reitanqild]

My question still stands though:

Will the new Firefox support real extensions or just wannabe-extensions like Chrome?

[rhelmer]

WebExtensions are a superset of what Chrome does. Things like tree-style tabs will be possible in Firefox with the new extension system, for instance.

There are already several WebExtension APIs implemented that Firefox supports that Chrome does not, the difference now is that APIs are being built specifically for extension authors to use, rather than Firefox internals being directly accessible (which certainly allows you to modify anything, but is intractable to maintain backwards compat and secure).

Many authors of popular extensions are working on specifying and prototyping the APIs they need.

[Sir_Cmpwn]

The primary concerns I have, which I left Firefox over, are:

- Dropping XUL breaks backwards compatability and it seems Mozilla is willing to break it before they provide adequate replacement APIs

- The design of the new addon signature requirements turns AMO into a walled garden and I very much do not appreciate that

[rhelmer]

> Dropping XUL breaks backwards compatability and it seems Mozilla is willing to break it before they provide adequate replacement APIs

The problem is not XUL. Modifying HTML or XUL DOM via JS is roughly equivalent (setting aside XUL-only features like XBL, does this matter for many extensions?)

The problem is all the internal JS APIs that add-ons can call right now, there are too many to secure and ensure backwards compat. This is why extensions break between releases so much. It's also pretty hard to program against, so there are a lot of common bugs and it's very difficult to ensure any level of security, since Firefox extensions can do anything.

WebExtensions are intended to be a superset of the APIs Chrome exposes, new APIs are being added all the time. It must be possible to implement them securely and maintain them over time, unlike the current situation with internal-only APIs.

> The design of the new addon signature requirements turns AMO into a walled garden and I very much do not appreciate that

I disagree. Signing is required to make it more difficult for malicious extensions to persist in the wild. There's no requirement to host on AMO, just a requirement to sign if you want your extension to run in Firefox release builds.

If the extension is later found to be malicious, it can be revoked without having to depend on the ID (which is set by the add-on and trivial to circumvent).

> The primary concerns I have, which I left Firefox over

Which browser did you switch to? There's still time to participate and influence outcomes, old-style extensions are still supported today...

[paulryanrogers]

Technically you don't have to distribute through Mozilla, just submit for signing. While it's true they remain a gatekeeper it's not as bad as the IOS app-store.