3 ms·

Everyone knew what the feedback from existing extension authors would be. Asking for "feedback" that you know you're going to ignore seems more disingenuous tha

by ender7 11y ago

Everyone knew what the feedback from existing extension authors would be. Asking for "feedback" that you know you're going to ignore seems more disingenuous that just admitting that you have to make a decision they don't like.

hobs 11y ago
I don't think they admit that in the document. I am a bit cranky over the entire thing, while I can understand the devs think this will be cleaner code, it sounds like a lot of time spent on working on things to get back to the status quo. From the article: "It sounds like you've made decisions without community input, why?" "We believe that moving Firefox away from XUL and XPCOM is a long-term strategic necessity. We need to find a way to do that. We have announced WebExtensions and the deprecation as early as possible so that we can get feedback from the community on how to make the transition. We know that WebExtensions will need to be improved. To innovate will require input and assistance from the community, which we are actively seeking. The path for WebExtensions will evolve in the coming weeks, months, and years, and we want the developer community to be a big part of that evolution." Let's break this apart a bit. They think its a necessity, so they did not ask others? I don't think this is anything but ignoring the question. They then go on to ask for help so that they can spend a bunch of time to return us to a status quo with less working extensions today, and continue to say that you should postpone development for a Firefox extension if you are thinking about working on one, "for a few months." Might as well start targeting Chrome since you cant even rely on FF to have a reliable API to even build a new extension against for a year. Not to mention all the time and energy spent learning XUL's magical inner workings all gone to rot. I guess there must be some HUGE technical impetus for this, because from my personal user perspective it seems mind bogglingly wasteful of time and resources.
- geofft 11y ago
  I'm a complete outsider to Firefox development (a former housemate used to work for Mozilla on something other than Firefox, that's about it), but as someone with strong opinions on browsers and security and not very strong opinions on extensions, it seems pretty reasonable to me. I'm really not comfortable with the extent to which XPCOM lets you load native-code libraries and call functions in them, and I'm not really sure I see a way that you can have something that works like current XPCOM but also uses strong sandboxing. Firefox is neither sandboxed nor multiprocess, unlike Chrome, and while this may not yet matter in the marketplace it's very much a "long-term strategic necessity" -- the architecture's technical debt will start biting them in terms of security profile. Meanwhile, the Servo folks (according to Google results for 'servo xul') seem to want to actively avoid XUL for Servo and are vaguely hoping to build the entire browser UI in HTML. If they make that work, then yes, the time and energy spent fighting with XUL will be a sunk cost, but I suspect most extension authors are familiar with HTML. To be fair, these are both decisions you make if your primary priority is building the best web browser possible. There is an argument that Firefox has already lost there to Chrome and that's not a battle worth fighting, and the priority should be building the best extensible web browser possible: it's something Firefox is already much better at, it's something that's harder for Chrome to be good at (because Chrome has already done this rearchitecting, being a much younger codebase), and it'll let Firefox compete on niche instead of competing head-to-head. And, clearly, Firefox is not a smoldering security disaster today, so maybe things will be fine in practice with a more moderate approach. If you take that worldview, then yes, they should be asking people who primarily care about extensions (developers and users). But if you don't take that worldview, if you ask people who care about browsers in general, they'll be supportive of this rearchitecture.

by ender7 11y ago

hobs 11y ago

I don't think they admit that in the document. I am a bit cranky over the entire thing, while I can understand the devs think this will be cleaner code, it sounds like a lot of time spent on working on things to get back to the status quo. From the article: "It sounds like you've made decisions without community input, why?" "We believe that moving Firefox away from XUL and XPCOM is a long-term strategic necessity. We need to find a way to do that. We have announced WebExtensions and the deprecation as early as possible so that we can get feedback from the community on how to make the transition. We know that WebExtensions will need to be improved. To innovate will require input and assistance from the community, which we are actively seeking. The path for WebExtensions will evolve in the coming weeks, months, and years, and we want the developer community to be a big part of that evolution." Let's break this apart a bit. They think its a necessity, so they did not ask others? I don't think this is anything but ignoring the question. They then go on to ask for help so that they can spend a bunch of time to return us to a status quo with less working extensions today, and continue to say that you should postpone development for a Firefox extension if you are thinking about working on one, "for a few months." Might as well start targeting Chrome since you cant even rely on FF to have a reliable API to even build a new extension against for a year. Not to mention all the time and energy spent learning XUL's magical inner workings all gone to rot. I guess there must be some HUGE technical impetus for this, because from my personal user perspective it seems mind bogglingly wasteful of time and resources.

geofft 11y ago
I'm a complete outsider to Firefox development (a former housemate used to work for Mozilla on something other than Firefox, that's about it), but as someone with strong opinions on browsers and security and not very strong opinions on extensions, it seems pretty reasonable to me. I'm really not comfortable with the extent to which XPCOM lets you load native-code libraries and call functions in them, and I'm not really sure I see a way that you can have something that works like current XPCOM but also uses strong sandboxing. Firefox is neither sandboxed nor multiprocess, unlike Chrome, and while this may not yet matter in the marketplace it's very much a "long-term strategic necessity" -- the architecture's technical debt will start biting them in terms of security profile. Meanwhile, the Servo folks (according to Google results for 'servo xul') seem to want to actively avoid XUL for Servo and are vaguely hoping to build the entire browser UI in HTML. If they make that work, then yes, the time and energy spent fighting with XUL will be a sunk cost, but I suspect most extension authors are familiar with HTML. To be fair, these are both decisions you make if your primary priority is building the best web browser possible. There is an argument that Firefox has already lost there to Chrome and that's not a battle worth fighting, and the priority should be building the best extensible web browser possible: it's something Firefox is already much better at, it's something that's harder for Chrome to be good at (because Chrome has already done this rearchitecting, being a much younger codebase), and it'll let Firefox compete on niche instead of competing head-to-head. And, clearly, Firefox is not a smoldering security disaster today, so maybe things will be fine in practice with a more moderate approach. If you take that worldview, then yes, they should be asking people who primarily care about extensions (developers and users). But if you don't take that worldview, if you ask people who care about browsers in general, they'll be supportive of this rearchitecture.