I am wondering how the WebExtensions paradigm will affect current XUL-based addons, with or without implementation of existing native XPCOM APIs.
Will they stop working? Will they have to switch to using WebExtensions?
Thanks, Allasso
I am wondering how the WebExtensions paradigm will affect current XUL-based addons, with or without implementation of existing native XPCOM APIs.
Will they stop working? Will they have to switch to using WebExtensions?
Thanks, Allasso
My understanding, or perhaps it’s just my opinion, is that XUL-based add-ons will (eventually) be deprecated and later fully unsupported, regardless of how WebExtensions evolves. Since the plan seems to be to (again, eventually) get rid of all XUL in Firefox, deprecating XUL-based add-ons is one of the logical first steps.
Deprecating XUL-based add-ons within the general goals of the WebExtensions plan seems to me like it’s more of a “while we’re at it…” kind of thing; i.e. since WebExtensions-based add-ons aren’t, or can’t be in principle, XUL-based at all, might as well make WebExtensions the alternative to those then.
So yeah, they’ll stop working at some point, and if WebExtensions really become the only framework that Firefox add-ons can be built on (as seems to be the plan, and I’m still hoping it doesn’t turn out that way), then XUL-based add-ons will need to switch to WebExtensions.
Yes, XUL-based add-ons will have to be rewritten, with the Add-on SDK and Web Extensions currently being proposed as alternatives. For the Add-on SDK one has to consider that low-level modules aren’t guaranteed to continue working.
Mozilla have claimed that support for the high level SDK APIs will also continue, but the low-level APIs (obviously) will be deprecated. Note that none of this has actually happened yet, which is a good thing because WebExtensions is barely functional at the moment and they’ll need a year or two before many addons can even hope to be ported to it. Some will never be possible, and many of your most cherished addons will be history in a few years.
Things will break over time as they develop new features, and they won’t get fixed. Older addons will gradually stop working. For example, developing multi-process Firefox without having to babysit all the existing addons would have been far easier. Many addons would have been broken, but not a problem if they’d been deprecated already.
The one tiny tiny chink of light is that the SDK was originally intended (secretly, but pretty obviously) to be able to one day deprecate XUL addons and that never came to pass. Maybe Mozilla will come to their senses and realise that sophisticated addons are really the only thing keeping them alive, but perhaps not if the desktop is a relic in five years and mobile/tablet is the only game in town.
It’s not a question that the current XUL-based add-ons (especially of the non-restartless kind) aren’t a good way to develop extensions. They are also a significant burden for the development of the platform, not only because of the backwards-compatibility constraints but also because of the performance and memory overhead required here. Mozilla changing their mind and sticking with XUL would be very bad IMHO.
The question is mostly whether WebExtensions will eventually mature into something that can support the extension existing today. With the native.js
proposal they could but there is still a long road ahead.
Thanks for all the input, and making things more clear.
For me this all kinda takes the fun out of developing/maintaining Firefox addons. One of the things that drew me to this in the first place was creative freedom in extending existing APIs, and also creating outside-of-the-box interfaces by exploiting XBL (often to a pretty radical degree). And I preferred the more nuts and bolts approach as opposed to using the SDK. Someone has (probably fittingly) described the old way of addon development as the “Wild West”, and well, I guess I liked the Wild West.
I’m just one grain of sand with a relatively small user base and I realize that Firefox does not exist for me to have fun. This is in no way a sell to try to keep things as they are, and I can understand the arguments. But when the time comes I don’t know if I will have a heart to rewrite my addons, very possibly having to give up some of the functionality that makes them unique. I have had a few users declare that if my addons become extinct they will freeze FF updates and take the risk. I have to assume that there are users of a lot more popular addons than mine that are thinking the same thing. But I am guessing that cases like this would not be all that likely (but then again, who knows). And the truly dedicated addon developers will just do what it takes to keep their addons alive and well.
Again, I am not saying what Mozilla is doing is wrong; just a lesser of two evils kind of thing I guess. And I suppose that over time even if the old favorites become extinct, I imagine new ones will come to take the place in one capacity or another.
I will only speak considering the category of add-ons which modify the main window’s interface, which is the one I have the most experience with. I believe those cases will be more likely than you think. At least these kinds of add-ons will have an extremely hard job, if not impossible, in doing so through WebExtensions; I don’t mean simply adding a toolbar button or a regular extra toolbar at the top, but add-ons like Tree Style Tab, Tile Tabs or Classic Theme Restorer, among many others, which completely overhaul the interface.
If you’re interested, I posted my take on this here, from the point of view of my own add-ons which also heavily modify the browser window.