[ TL;DR : From reading your blog post I get the impression you, just as almost everyone else who read the announcement, myself included on my first read-through, took WebExtensions as the future one and absolute way of writing an extension. IMO, WE isn’t supposed to be the only way to code an add-on, but rather a framework to do it, replacing the SDK. ]

I think the biggest thing to keep in mind is the distinction between all the subjects covered in the announcement:

- as you said yourself, alternatives to XUL and XPCOM have become an increasing necessity, deprecating XUL-based add-ons and those that use XPCOM is the logical first step in getting there;

- signing has also become a necessity for its own reasons;

- so has e10s, I think we all want a faster and more stable browser;

- WE was introduced as the future alternative to the SDK, it is meant to (supposedly?) achieve the same goals, both in end-product functionality and in ease-of-development, with a few added bonuses, the biggest of which seems to be browser portability.

All of those points are valid, and they have nothing to do with each other. They just happened to be jumbled up in the same blog announcement because they’re happening at the same time (and logically there will be some overlap in achieving all these goals), so most of it was lost in the middle of the whole “holy hell” reaction. You’re right that the SDK has matured over the years, but if you look at it from the outside, it seems to me the SDK was a sort of pre-WE in itself: it has its own modules to interact with the browser in its own “arbitrary” ways.

IMHO, if I look only to the WE over SDK part and forget everything else, WE apparently aims to bring the best points from other established models (Blink) into Firefox, some things that the SDK doesn’t have or can’t do as it is.

Maybe those things could have been brought into the SDK itself as has been suggested all around, I guess the design decision there was more in favor of browser portability than continuance. Whether that’s actually good or bad, well I’m sure it’s good for those that developer for multiple browsers, and I’m also sure that it in itself shouldn’t really hurt those that develop only for Firefox.

I also wasn’t a fan of the SDK at first (I’ve still never used it actually), precisely because when it was in its infancy it could barely do anything useful. That’s the stage WE is in right now. And remember the goal at the time the SDK was created was “let’s bring as many developers as we can into using it”. Now apparently the goal with WE is “we want even more developers using WE than that”, and if it the point is to try and fit into it as much as add-ons need, as far as signs go I can’t say that’s particularly a bad one.

What is setting off this little wave of rage and despair is that unfortunately the announcement made it sound like WE will be the only way to create add-ons, which I believe is false. XUL-based and SDK-based add-ons aren’t the only formats, you can also create a blank bootstrap.js file and code a restartless add-on from scratch without using a single piece of the SDK. I did, many times over.

(I’m an optimist, I haven’t seen anything about dropping support for regular restartless add-ons, so I presume those will stay, even if they need some kind of special permission in the new WE permissions model to allow them to work. I did voice that idea just to be safe: https://webextensions.uservoice.com/forums/315663-webextension-api-ideas/suggestions/9440937-deprecate-xul-does-not-mean-deprecate-all-add-ons, and I wasn’t the only one apparently.)

I think that’s the key point, because while I agree there isn’t a rationale for WE to become the only way to create Firefox add-ons, that’s of course a little insane to say the least, there is definitely a rationale, and a good one IMO, for WE as a framework model to create Firefox add-ons. To that point, so far I’ve not seen any XUL-based add-on that couldn’t be converted into a restartless format, with more or less effort of course depending on the case:

- XUL deprecation is irrelevant, whatever you modify now you can still do so in an HTML environment as long as you have access to the DOM tree, and any anonymous nodes or XBL binding methods that go with it can be changed as well (now and in whatever comes to replace them) with some clever JS’ing;

- XPCOM also has alternatives apparently, although I won’t say much about them as I’ve never used them myself, I’m just basing that on the impression I get from what I gather here and there;

- signing isn’t a deal breaker, pretty much everything on AMO is signed already, add-ons not hosted there can also be signed (it is extremely easy to do it even), everyone can sign their personal add-ons without having them listed or made public, anyone can pick up an abandoned add-on and submit it as-is for signing and republish it, developers will be able to use unsigned versions in NIghtly and Dev.Edition and even in release and beta Firefox (those complaining about this should do proper research, “unbranded versions” means “exactly the same Firefox version except for the name and logo”), ESR will apparently keep the preference to not enforce signing, and lots more should be coming in the future, what more could anyone want? :)

- e10s, well in many cases that will take a little work I guess, but if I, an absolutely amateur coder with no academic background in any kind of computers sciences what-so-ever doing everything in his spare time, managed to rewrite FindBar Tweak, an add-on that was absolutely riddled with e10s-related problems because it touched web content in every step of the way, to an e10s-friendly format, then the same absolutely can be done for every other add-on out there, it only takes some effort, and you won’t believe the performance increase I tell’z ya’ :)

To quote myself, I’ve always believed it is the job of an add-on developer to adapt with Firefox, and not the other way around; after all, add-ons are made for Firefox, Firefox isn’t made for add-ons. (I know this is a point that many don’t agree with, but as far as middle ground goes, I think it’s the most appropriate way of looking at things.) Obviously some add-ons will be left behind if no one works on them, but if Firefox is rapidly and deeply changing, so must its add-ons.

With that in mind, we’re at a stage where every add-on needs to adapt, as Firefox itself is undergoing massive changes. WE comes as a (future) alternative, for those who decide to (re)write their add-ons from scratch, just as the SDK is/does now. But as long as it doesn’t become the only way to code add-ons as I hope it doesn’t, the world of Firefox add-ons will be fine, it just needs some evolving and work done in order to keep going.