5 ms·

It's soo more than that. They'd destroyed all the old UI in favor of Chrome-style HTML+JS instead of platform-native XUL They added all sorts of weird commerci

by tomc1985 6y ago

It's soo more than that. They'd destroyed all the old UI in favor of Chrome-style HTML+JS instead of platform-native XUL They added all sorts of weird commercial initiatives to someonething that was supposed to be privacy-oriented and nonprofit They torched an entire ecosystem of extensions so they could be more Chromelike They put out landing pages and press releases full of weasely PR speak instead of the "mainstream engineering" vocabulary they used to use Maybe Firefox should get in touch with the Pale Moon guys and use their code as a basis for resurrecting everything that made FIrefox great

dralley 6y ago
> It's soo more than that. They'd destroyed all the old UI in favor of Chrome-style HTML+JS instead of platform-native XUL It's a browser, the entire purpose of a browser is rendering HTML+JS quickly and efficiently. XUL primitives are not, on average, faster or more "platform-native". >They added all sorts of weird commercial initiatives to someonething that was supposed to be ... nonprofit You understand the problem here, do you not? People complain that they're almost completely reliant on Google for revenue, and they also complain about "weird commercial initiatives" to mitigate their reliance. >They torched an entire ecosystem of extensions so they could be more Chromelike XUL / XPCOM had significant, tangible problems. It's not just about being "chromelike", not at all. https://mozilla.github.io/firefox-browser-architecture/text/0003-problems-with-xul.html https://mozilla.github.io/firefox-browser-architecture/text/... https://mozilla.github.io/firefox-browser-architecture/text/0005-problems-with-xbl.html https://mozilla.github.io/firefox-browser-architecture/text/...
- tomc1985 6y ago
  > XUL / XPCOM had significant, tangible problems. Significant problems that could have been fixed > XUL primitives are not, on average, faster or more "platform-native". At least on Windows they mapped to their native components. Sure spacing and a few other things were a little off (maybe because it mapped to GTK? I don't remember) but the look and feel then was vastly superior than the Electron-looking garbage that extensions have to do now. > You understand the problem here, do you not? People complain that they're almost completely reliant on Google for revenue, and they also complain about "weird commercial initiatives" to mitigate their reliance. You're not understanding me. Most folks have no problem with Pocket and whatever else. What they have a problem with is bundling it with the browser in a way that can't be removed, and then putting out a press release full of PR speak about how important and essential these extras are. These commercial iniatives were made mandatory, even when their beta versions were downloadable extensions I'm all for Mozilla reaching out to whoever they want to partner with. But keep that shit out of the master repo. The downloadable base should be pure platform and nothing else, with extras as preinstalled, removable extensions. Essentially, the Winamp model > https://mozilla.github.io/firefox-browser-architecture/text/.. https://mozilla.github.io/firefox-browser-architecture/text/.... What I see there are mostly people issues that come with not wanting to pay for the talent you need to get the job done. It looks like they had the money to do this but it feels like they spent it on admin and marketing folks instead The XBL document mentions more systemic problem but I maintain that they could have been fixed iteratively
  - dralley 6y ago
    >The XBL document mentions more systemic problem but I maintain that they could have been fixed iteratively ... >Significant problems that could have been fixed It is not like the Firefox developers do not understand the value of iterative change. That was after all the basis for Project Quantum. If this were true, they would have done it. But I'll let a Mozilla engineer explain this instead: https://dblohm7.ca/blog/2015/08/30/on-webextensions/ https://dblohm7.ca/blog/2015/08/30/on-webextensions/ https://dblohm7.ca/blog/2017/11/16/legacy-firefox-extensions-and-userspace/ https://dblohm7.ca/blog/2017/11/16/legacy-firefox-extensions...
  - sfink 6y ago
    >> XUL / XPCOM had significant, tangible problems. > Significant problems that could have been fixed Mozilla agreed with you for a long, long time. But we eventually realized that while yes, we could continue to keep fixing those problems, that the opportunity cost was large: fixing XUL issues was taking the place of improving stuff that web pages actually use, and it would be better to not be splitting the effort both ways. (I work for Mozilla, though mostly not on the stuff being discussed here.)

dralley 6y ago

> It's soo more than that. They'd destroyed all the old UI in favor of Chrome-style HTML+JS instead of platform-native XUL It's a browser, the entire purpose of a browser is rendering HTML+JS quickly and efficiently. XUL primitives are not, on average, faster or more "platform-native". >They added all sorts of weird commercial initiatives to someonething that was supposed to be ... nonprofit You understand the problem here, do you not? People complain that they're almost completely reliant on Google for revenue, and they also complain about "weird commercial initiatives" to mitigate their reliance. >They torched an entire ecosystem of extensions so they could be more Chromelike XUL / XPCOM had significant, tangible problems. It's not just about being "chromelike", not at all. https://mozilla.github.io/firefox-browser-architecture/text/0003-problems-with-xul.html https://mozilla.github.io/firefox-browser-architecture/text/... https://mozilla.github.io/firefox-browser-architecture/text/0005-problems-with-xbl.html https://mozilla.github.io/firefox-browser-architecture/text/...

tomc1985 6y ago
> XUL / XPCOM had significant, tangible problems. Significant problems that could have been fixed > XUL primitives are not, on average, faster or more "platform-native". At least on Windows they mapped to their native components. Sure spacing and a few other things were a little off (maybe because it mapped to GTK? I don't remember) but the look and feel then was vastly superior than the Electron-looking garbage that extensions have to do now. > You understand the problem here, do you not? People complain that they're almost completely reliant on Google for revenue, and they also complain about "weird commercial initiatives" to mitigate their reliance. You're not understanding me. Most folks have no problem with Pocket and whatever else. What they have a problem with is bundling it with the browser in a way that can't be removed, and then putting out a press release full of PR speak about how important and essential these extras are. These commercial iniatives were made mandatory, even when their beta versions were downloadable extensions I'm all for Mozilla reaching out to whoever they want to partner with. But keep that shit out of the master repo. The downloadable base should be pure platform and nothing else, with extras as preinstalled, removable extensions. Essentially, the Winamp model > https://mozilla.github.io/firefox-browser-architecture/text/.. https://mozilla.github.io/firefox-browser-architecture/text/.... What I see there are mostly people issues that come with not wanting to pay for the talent you need to get the job done. It looks like they had the money to do this but it feels like they spent it on admin and marketing folks instead The XBL document mentions more systemic problem but I maintain that they could have been fixed iteratively
- dralley 6y ago
  >The XBL document mentions more systemic problem but I maintain that they could have been fixed iteratively ... >Significant problems that could have been fixed It is not like the Firefox developers do not understand the value of iterative change. That was after all the basis for Project Quantum. If this were true, they would have done it. But I'll let a Mozilla engineer explain this instead: https://dblohm7.ca/blog/2015/08/30/on-webextensions/ https://dblohm7.ca/blog/2015/08/30/on-webextensions/ https://dblohm7.ca/blog/2017/11/16/legacy-firefox-extensions-and-userspace/ https://dblohm7.ca/blog/2017/11/16/legacy-firefox-extensions...
- sfink 6y ago
  >> XUL / XPCOM had significant, tangible problems. > Significant problems that could have been fixed Mozilla agreed with you for a long, long time. But we eventually realized that while yes, we could continue to keep fixing those problems, that the opportunity cost was large: fixing XUL issues was taking the place of improving stuff that web pages actually use, and it would be better to not be splitting the effort both ways. (I work for Mozilla, though mostly not on the stuff being discussed here.)