4 ms·

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 implement

by dman 6y ago

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.

danShumway 6y ago
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. [0]: https://www.userchrome.org/how-create-userchrome-css.html https://www.userchrome.org/how-create-userchrome-css.html
- dman 6y ago
  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.
  - danShumway 6y ago
    > 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?".
guywhocodes 6y ago
I think that you can take the magnitude of this departure as a promise to never return. I expect it to become the Safari you would have to install.

by dman 6y ago

danShumway 6y ago

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. [0]: https://www.userchrome.org/how-create-userchrome-css.html https://www.userchrome.org/how-create-userchrome-css.html

dman 6y ago
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.
- danShumway 6y ago
  > 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?".

guywhocodes 6y ago

I think that you can take the magnitude of this departure as a promise to never return. I expect it to become the Safari you would have to install.