4 ms·

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 tha

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

by dman 6y ago

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?".

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

mook 6y ago

> 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.