I had written multiple XUL based addons that I used for personal productivity. When Firefox moved away from XUL/XPCom I think they removed not just an implementation (which I admit had many warts) but also the alternate vision of the Browser being extensible by end users who were almost on an equal footing with Browser developers. As a developer I can live with, support and cheer for a worse implementation of a better idea, but when you give up on that idea you rob me of any reasons I could use to support or evangelise for you.
It boils down to a simple question - does Firefox intend to go after power users in ways Chrome will not or cannot? The answer to this question used to be very clear to me in the first decade, now I think the answer is no. Even the Rust based oxidation efforts seemed limited to coming up with better implementation of the same primitives that Chrome offers, I didnt see anything about offering fundamentally different tradeoffs / choices.
If Firefox course corrects to going back to power users, I will be the first one to cheer them on. The vision for firefox has to be to reduce the gap between what browser developers can do and what end users can do.
I think your comment is a much more salient criticism.
In many ways, webExtensions could be a more accessible system than XUL addons if there was a serious effort to give the end-user more tools to use them. I honestly really like the overall architecture of webExtensions, and I like the idea of having more core code in modern Javascript. But there's a lot of weirdness around the ecosystem itself that makes building extensions into a chore.
There's a theoretical set of changes Firefox could make that would turn webExtensions into an extremely accessible, powerful user-facing feature for on-the-fly customizing and inspecting what their browser was doing. And I don't think it would need to be that inherently less secure.
It would need to approach security differently, but I feel like many of these are solvable problems, and many of the changes required (better sandboxing, active tab permissions) are stuff we want for extensions today anyway.
Some of the changes that came out of dropping XUL are really good. A lot of Firefox's styling is handled through CSS now. That should be a huge accessibility win for new users, and it should provide a nice gateway for new users to think more about moving on to making their own websites using the same technology. Except... userChrome.css is hidden in a config directory somewhere and not loaded by default[0]. They built a really nice way for users to quickly add minor styling customizations, and then they hid it from end users.
Sure - I can see that if we do arrive at a future where all of Firefox chrome is implemented via a HTML/CSS itself and it sits on top of a standardized core that exposes well documented APIs (which both end users and Firefox developers) can use for feature development - then yes we will be back to the world where someone outside Mozilla could build something like Komodo IDE on top of Mozilla tech.
One question I have as a user - what is an acceptable grace period for coming up with an equivalent replacement when you take an API away? Even the CSS styling not being loaded by default that you pointed out suggests that Firefox devs appear to view extensibility as something that they have to support cautiously and grudgingly. There is a chicken and egg problem here - if you make it harder to develop, build and ship non trivial extensions to end users then only a tiny fraction of users will use them. Then you will use the lack of usage of these extensibility features to deprioritize the development efforts that go into them.
I would really like someone to take on the task of building a "Workstation" browser - built for power users.
> There is a chicken and egg problem here - if you make it harder to develop, build and ship non trivial extensions to end users then only a tiny fraction of users will use them.
This is a really good point.
> what is an acceptable grace period for coming up with an equivalent replacement when you take an API away?
I really don't know.
I am frustrated with the current state of extensions in Firefox, even as I acknowledge that the situation in Firefox is still way better than it is in browsers like Chrome or Safari, and even as I remain hopeful that the Firefox extension ecosystem could be really good. I am sympathetic to the argument that it's an engineering resources problem. But, that also makes me really nervous about the Mozilla cuts that happened recently, because now how long are we going to wait for Servo to be in a usable state, if it even ever gets to a usable state?
Like you mention above, when you're forging a new trail in an underdeveloped area and making a case that users would benefit from these features if the ecosystem supported them enough and trained users to use them, you need some freedom to be flexible and experimental and to waste some resources forging that trail. And if resources are as scarce as Mozilla is claiming, then what are the features that are going to be cut first? The experimental, trailblazing ones, the weird ideas like, "shouldn't there be a section in the Firefox options where users can just live-edit the CSS to the browser?".
So I will concede that it is time to bury all the XUL/XPCom misgivings. We now need to rededicate ourselves to the same extensible vision using the new stack.
I think we need some kind of champion to make that point -- to prove that the extensible vision we did have and lost is still worth pursuing.
But that's not really a useful thing for me to say, because I have no idea where we can go to get that champion, and I'm at least low-key worried about Mozilla's ability and willingness to be that champion.
But agreed. I think it's about more than just XUL vs webExtensions, I think it's a broad tech/cultural issue about making the case that end-user-accessible control and customization is important.
> One question I have as a user - what is an acceptable grace period for coming up with an equivalent replacement when you take an API away?
Done correctly, the replacement should have already been there for one release before the deprecated method is removed; this is because the downstream developers also need to transition to the new code. Ideally there's some amount of time involved (so no releasing two versions in quick succession without letting people have time to move off the old way). That depends more on the scale of what people have been doing with your old APIs.
Note that the deprecated method only has to work; it doesn't need to be performant. That means doing it as a shim on top of the new way is fine (even though it's code that might be thrown away soon).
All of this has ~nothing to do with what Mozilla had been doing with Firefox, of course. I'm still waiting for features that existed in XPCOM that are no longer supported.
It boils down to a simple question - does Firefox intend to go after power users in ways Chrome will not or cannot? The answer to this question used to be very clear to me in the first decade, now I think the answer is no. Even the Rust based oxidation efforts seemed limited to coming up with better implementation of the same primitives that Chrome offers, I didnt see anything about offering fundamentally different tradeoffs / choices.
If Firefox course corrects to going back to power users, I will be the first one to cheer them on. The vision for firefox has to be to reduce the gap between what browser developers can do and what end users can do.