Earlier quoted context omitted.
> Ouch, the comments over there are extremely negative. Humans are loss-sensitive. When Coca-Cola did blind taste tests for New Coke, it was overwhelmingly preferred. When they told people which was which, the preference for New Coke increased . Instead, when they removed Coca-Cola Classic from the shelves, people clamored for it back. People want the thing they cannot have. Scarcity creates desire. To some, this is…
> To some, this is a simple engineering trade-off. You can't have sandboxing, tab isolation, and responsiveness improvements with XUL add-ons in any kind of feasible or sustainable way. Certainly you can: it's software--anything is possible. The issue is that they don't want to make the effort. I think this is because the developers are no longer the people who built Firefox, and they want to reinvent Firefox and put…
As the IRC channel topic on #jsapi on irc.mozilla.org says, "Nothing is hard to implement in isolation."
No, not everything is possible given finite resources. Some things are possible only if you sacrifice others. That might be actual things you need to remove, or the opportunity cost of adding more complexity to satisfy contradictory constraints and hence not improving something else.
As a concrete example here, if you have an extension model that relies on synchronous access to the page DOM _and_ the UI at the same time, and now you want to put those two things in different processes, you have a few options:
1) You can throw out the extension model. 2) You can write some complicated synchronous IPC proxies.
Make no mistake, option 2 _does_ mean trading off responsiveness: if the web renderer process you are trying to poke at is busy, then you will end up having to wait, and if you wait in a sync proxy that's a pause in the UI process. And that's what you're trying to avoid in the first place.
Note that people did in fact create the sync proxies, as a temporary measure, while working on providing better APIs to be used instead, to make the transition easier for extension authors. There are conflicting opinions on whether this is the right time to get rid of the sync proxy bits, but it does in fact need to happen at some point.
As for your opinion that "the developers are no longer the people who built Firefox", here's another data point. My first commit to Gecko (this is before there was a Firefox) was sometime in June 2001. I'm not trying to reinvent anything for the sake of reinvention. But I do think there are fundamental problems with both supporting the existing XUL addon ecosystem and making a number of long-delayed architectural changes that we don't feel like we can delay any longer. Again, we can argue about whether this is the right time for those changes. But I think it is. As a simple example, needing to support the existing XUL addon ecosystem would make the Stylo project (using the Servo style system in Gecko) harder. So if we're trying to get Stylo done by sometime this year (which we are), that gives you an end-of-life of ... well, right about the Firefox 57 release.