4 ms·

The conspiracy theorist in me wants to believe that this is not incompetence, but sabotage. Everyone uses Google products; if they work fast in chrome and slow

by pinusc 6y ago

The conspiracy theorist in me wants to believe that this is not incompetence, but sabotage. Everyone uses Google products; if they work fast in chrome and slow on firefox, people will blame Firefox, not Google. And therefore will eventually switch to Chrome. Good strategy to steal market share.

shadowgovt 6y ago
It's not intentional sabotage; it's positive feedback loops. Using Chrome, your tooling experience developing software at Google is, maybe, 1% faster. Some of that is core (TBH, FF's engine is old and creaky and webkit-derived browsers out-perform it on all kinds of metrics, though FF has significantly closed the gap). Some of it is that teams develop for Chrome first, because it's the first browser shortcut available. Plus, Chrome has all kinds of extensions built in-house at Google to make your life easier, and those have to be rewritten from scratch if someone wants them for FF also. So now when you're doing UI development and testing it, your first testbed is always Chrome, because it's what you're using as a developer. So bugs always get seen first in Chrome, and only seen in FF if your team has acceptance testing requirements or you happen to have a team member who uses FF. So the gap widens: now using Chrome in Google is, maybe, a 5% better experience, because you're that much less likely to hit bugs the developing team hasn't hit yet. And th positive feedback loop continues. The only way I'm aware of to stop this is to force teams to put half their engineers on using FF as their primary browser, and I've never seen a team willing to do so. FF has die-hard supporters inside Google, but few are so die-hard they're willing to intentionally slow down their own development velocity by using a less-supported browser. Google's too competitive to incentivize that. (Note: this applies to bugs that crop up between OS platforms also, because that happens---sometimes, the details of Chrome on MacOS surface a bug that never shows up on Linux. Some teams do require one engineer at least to use Mac, because the MacOS userbase is big enough that there's financial incentive to not break it. FF has like 5% market share; there's no such incentive there).
- lol768 6y ago
  > those have to be rewritten from scratch if someone wants them for FF also. What? Why are they not standard WebExtensions?
  - shadowgovt 6y ago
    Because (a) most of them predate the standardization of WebExtensions and (b) that API still isn't standardized enough to make building against it as cheap as building a chrome specific extension. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Build_a_cross_browser_extension https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
fsflover 6y ago
Former Mozilla exec: Google has sabotaged Firefox for years (zdnet.com) https://news.ycombinator.com/item?id=19669586 https://news.ycombinator.com/item?id=19669586
mraza007 6y ago
Agreed but if they work fast in chrome just use chrome for that otherwise keep using firefox I left using chrome 3 years ago and I haven’t really missed out and I honestly love firefox

by pinusc 6y ago

shadowgovt 6y ago

It's not intentional sabotage; it's positive feedback loops. Using Chrome, your tooling experience developing software at Google is, maybe, 1% faster. Some of that is core (TBH, FF's engine is old and creaky and webkit-derived browsers out-perform it on all kinds of metrics, though FF has significantly closed the gap). Some of it is that teams develop for Chrome first, because it's the first browser shortcut available. Plus, Chrome has all kinds of extensions built in-house at Google to make your life easier, and those have to be rewritten from scratch if someone wants them for FF also. So now when you're doing UI development and testing it, your first testbed is always Chrome, because it's what you're using as a developer. So bugs always get seen first in Chrome, and only seen in FF if your team has acceptance testing requirements or you happen to have a team member who uses FF. So the gap widens: now using Chrome in Google is, maybe, a 5% better experience, because you're that much less likely to hit bugs the developing team hasn't hit yet. And th positive feedback loop continues. The only way I'm aware of to stop this is to force teams to put half their engineers on using FF as their primary browser, and I've never seen a team willing to do so. FF has die-hard supporters inside Google, but few are so die-hard they're willing to intentionally slow down their own development velocity by using a less-supported browser. Google's too competitive to incentivize that. (Note: this applies to bugs that crop up between OS platforms also, because that happens---sometimes, the details of Chrome on MacOS surface a bug that never shows up on Linux. Some teams do require one engineer at least to use Mac, because the MacOS userbase is big enough that there's financial incentive to not break it. FF has like 5% market share; there's no such incentive there).

lol768 6y ago
> those have to be rewritten from scratch if someone wants them for FF also. What? Why are they not standard WebExtensions?
- shadowgovt 6y ago
  Because (a) most of them predate the standardization of WebExtensions and (b) that API still isn't standardized enough to make building against it as cheap as building a chrome specific extension. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Build_a_cross_browser_extension https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

fsflover 6y ago

Former Mozilla exec: Google has sabotaged Firefox for years (zdnet.com) https://news.ycombinator.com/item?id=19669586 https://news.ycombinator.com/item?id=19669586

mraza007 6y ago

Agreed but if they work fast in chrome just use chrome for that otherwise keep using firefox I left using chrome 3 years ago and I haven’t really missed out and I honestly love firefox