6 ms·

I think that may be overly pessimistic: The post says they are working to extend WebExtensions in ways to allow addons that currently can't work in the Chrome e

by azakai 11y ago

I think that may be overly pessimistic: The post says they are working to extend WebExtensions in ways to allow addons that currently can't work in the Chrome etc. addon APIs. I'm not sure if that will address that concern, it depends how far they will go with that, but at least it is clear that doing much better than basic WebExtensions/Jetpack/etc. is intended.

nolok 11y ago
He is quoting a comment, he's not the author of what you read.
- azakai 11y ago
  Yes, sorry, I meant the comment was overly pessimistic. I'll edit.
tn123 11y ago
Since you're addressing my comment there: I don't think I'm overly pessimistic. Apart from having been in the game since mozilla suite and having experienced a LOT of things that didn't turn out so well, to say the least and keep it polite and curse-word free... The WebExtensions API is supposed to be an intentionally strictly defined API with a limited feature set; that just comes with the territory. It is supposed to give you access to a subset of Firefox features/internals. Compare that to the current extension "API": What Firefox can do, your add-on can do, and a lot of more things as well. You can customize Firefox to the point it really is a new browser (with thinks like Tab Mix Plus, Tree tabs, vimperator/pentadactyl) or just keep it (almost) vanilla, as you please. This is a major plus for users. Sure, for a lot of things the extension team may add a WebExtensions API. But that is limited to what that team deems worthy of their time, deems "useful", and deems "safe". It is no longer up to the add-on developer to decide what they would like to develop, but up to the WebExtensions API gatekeeper team on what they want to allow and what they then prioritize and create the actual APIs. Adding new APIs you may need will require you nag the team about it, though luck if you don't speak any language they understand, tough luck if they don't care or cannot care because their time is not infinite. What makes me even more pessimistic is seeing the Jetpack/Add-on SDK after years of development and how it still only can address only the most basic use cases. The number of SDK-based add-ons, even relatively simple ones, that have to resort to 'require("chrome")' is staggeringly high. If the pace of the Add-on SDK and the stability its API is any indication... Time to look for another browser... Except there isn't any comparable to what Firefox still is right now. And let's not forget: A change like this will break almost all existing add-ons in major ways. Many if not add-ons need to be rewritten in their entirety or at least in major chunks from scratch. Many add-ons will simply not make that huge investment in time required for that and simply die, without readily available replacements and leaving users behind scratching their heads.
- pcwalton 11y ago
  > What Firefox can do, your add-on can do, and a lot of more things as well. You can customize Firefox to the point it really is a new browser (with thinks like Tab Mix Plus, Tree tabs, vimperator/pentadactyl) Those are popular add-ons. See the post: "Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extensions as possible." > What Firefox can do, your add-on can do, and a lot of more things as well XPCOM has never exposed everything, and in fact has steadily reduced its scope since "de-COMtamination" began a decade ago.
  - tn123 11y ago
    Yeah, and the not-so-popular add-ons can screw themselves, I guess. Your add-on only has 10.000 users? 200 users? uhhh... Sorry, priorities. Then again, actually look at the vimperator or pentadactyl code... That code interacts and/or hooks a ton of stuff. Designing and implementing APIs just to support that will require a lot of time. And that is just one add-on. Furthermore, do you really believe that add-ons like vimperator or Tab Mix Plus or Stylish or SqliteManager would have been created if there was no "open API"? I don't think so. Also, did you know that a lot of the Chrome extension API was created after directly soliciting feedback from Firefox add-on developers? Yet, a ton of add-ons still couldn't or just weren't supported in the Chrome API. And added to that, the Chrome API kinda stagnated after that.
    - brighteyes 11y ago
      Maybe the Chrome API stagnated, but that doesn't mean the same will happen here. The stated goals already include addons impossible in Chrome's API.
      - the8472 11y ago
        But that still means you have to ask the gatekeeper first to please make an API available for what you have in mind. And the gatekeeper might say "no". Or say "sounds nice, but our backlog is thiiiiiis long". With the old model nobody had to ask for permission, they could just develop and then mozilla could choose to support their use-case through a less hacky API.

by azakai 11y ago

nolok 11y ago

He is quoting a comment, he's not the author of what you read.

azakai 11y ago
Yes, sorry, I meant the comment was overly pessimistic. I'll edit.

tn123 11y ago

Since you're addressing my comment there: I don't think I'm overly pessimistic. Apart from having been in the game since mozilla suite and having experienced a LOT of things that didn't turn out so well, to say the least and keep it polite and curse-word free... The WebExtensions API is supposed to be an intentionally strictly defined API with a limited feature set; that just comes with the territory. It is supposed to give you access to a subset of Firefox features/internals. Compare that to the current extension "API": What Firefox can do, your add-on can do, and a lot of more things as well. You can customize Firefox to the point it really is a new browser (with thinks like Tab Mix Plus, Tree tabs, vimperator/pentadactyl) or just keep it (almost) vanilla, as you please. This is a major plus for users. Sure, for a lot of things the extension team may add a WebExtensions API. But that is limited to what that team deems worthy of their time, deems "useful", and deems "safe". It is no longer up to the add-on developer to decide what they would like to develop, but up to the WebExtensions API gatekeeper team on what they want to allow and what they then prioritize and create the actual APIs. Adding new APIs you may need will require you nag the team about it, though luck if you don't speak any language they understand, tough luck if they don't care or cannot care because their time is not infinite. What makes me even more pessimistic is seeing the Jetpack/Add-on SDK after years of development and how it still only can address only the most basic use cases. The number of SDK-based add-ons, even relatively simple ones, that have to resort to 'require("chrome")' is staggeringly high. If the pace of the Add-on SDK and the stability its API is any indication... Time to look for another browser... Except there isn't any comparable to what Firefox still is right now. And let's not forget: A change like this will break almost all existing add-ons in major ways. Many if not add-ons need to be rewritten in their entirety or at least in major chunks from scratch. Many add-ons will simply not make that huge investment in time required for that and simply die, without readily available replacements and leaving users behind scratching their heads.

pcwalton 11y ago
> What Firefox can do, your add-on can do, and a lot of more things as well. You can customize Firefox to the point it really is a new browser (with thinks like Tab Mix Plus, Tree tabs, vimperator/pentadactyl) Those are popular add-ons. See the post: "Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extensions as possible." > What Firefox can do, your add-on can do, and a lot of more things as well XPCOM has never exposed everything, and in fact has steadily reduced its scope since "de-COMtamination" began a decade ago.
- tn123 11y ago
  Yeah, and the not-so-popular add-ons can screw themselves, I guess. Your add-on only has 10.000 users? 200 users? uhhh... Sorry, priorities. Then again, actually look at the vimperator or pentadactyl code... That code interacts and/or hooks a ton of stuff. Designing and implementing APIs just to support that will require a lot of time. And that is just one add-on. Furthermore, do you really believe that add-ons like vimperator or Tab Mix Plus or Stylish or SqliteManager would have been created if there was no "open API"? I don't think so. Also, did you know that a lot of the Chrome extension API was created after directly soliciting feedback from Firefox add-on developers? Yet, a ton of add-ons still couldn't or just weren't supported in the Chrome API. And added to that, the Chrome API kinda stagnated after that.
  - brighteyes 11y ago
    Maybe the Chrome API stagnated, but that doesn't mean the same will happen here. The stated goals already include addons impossible in Chrome's API.
    - the8472 11y ago
      But that still means you have to ask the gatekeeper first to please make an API available for what you have in mind. And the gatekeeper might say "no". Or say "sounds nice, but our backlog is thiiiiiis long". With the old model nobody had to ask for permission, they could just develop and then mozilla could choose to support their use-case through a less hacky API.