3 ms·

The idea of a well-defined extensions interface is not a bad idea. In fact, it's a very good idea. For as much power the old, everything-goes extensions model g

by kibwen 4y ago

The idea of a well-defined extensions interface is not a bad idea. In fact, it's a very good idea. For as much power the old, everything-goes extensions model gave you, it also meaningfully prevented Firefox from evolving for years. Remember that decade where Firefox shed market share to Chrome for being too "slow" and "bloated"? Yeah, and it was that way because Mozilla couldn't change a damn thing without half of the entire extensions ecosystem imploding with every release. You need a well-defined API if you want to have any hope of improving the browser without breaking the whole world every week. Chrome had such an API, and it was popular, so Firefox lifted it. That's not nefarious, that's just smart. I'm happy that they managed to pull it off, and I'm happy that alternative browsers continue to exist in order to resist Google's death grip on the web.

adra 4y ago
If they cared and their slowdowns were simply related to addons, they could always sample the overhead of said addons and show a warning. My moderate use of addons in FF didn't feel too aggressive, but then again I'm not in the clique with dozens of open windows. There were times of fast/slowness in FF. It was never bad enough to chase me off the platform, but to say the slow ess was simply saddled on addons is probably disingenuous.
- Karellen 4y ago
  It's not that the addons were slow. It's that the architecture in Firefox that was needed to support the addons was slow - even if there were no addons in use.
- spiffytech 4y ago
  The slowness wasn't caused (just) by slow addons. As I remember it, Firefox was unable to move to a multi-process architecture as long as old extensions were supported.
  - mook 4y ago
    My recollection was that they had some multi-process things, though the problem was that they had to keep breaking extensions as they added more and more. I believe multi-process NPAPI plugins was somewhere around 3.6 or 4? (Of course, 4 took forever to ship too… that was great for extensions though, because it meant no API breakage during that time.)
- adjav 4y ago
  It's not that the add-ons were slow, it's that the architecture built to support those add-ons made the browser as a whole inherently slow. Everything was quite siloed, and required a series of dynamic dispatches to accomplish anything. This allowed extensions to easily change lots of core functionality, but also meant that the entire Firefox codebase had become a public API, and practically any change made would break something.
- deleted 4y ago
  [deleted]
modo_mario 4y ago
>Remember that decade where Firefox shed market share to Chrome for being too "slow" and "bloated"? The only part I remember where Firefox was notably slower was videos when Google led Firefox for a ring around the rosie when they singlehandedly decided to use a proprietary codec for their youtube videoplayer after first making everyone believe they were working on using a different one which FF started working on supporting. I can't count the amount of complaints i heard of firefox being slow there.
- imbnwa 4y ago
  Is this when you had to make sure you were brute forcing the HTML5-based playback?
eitland 4y ago
> Remember that decade where Firefox shed market share to Chrome for being too "slow" and "bloated"? Except it wasn't. I used Firefox a lot on Windows and Linux and didn't have the slightest problems. The only reason I see why Chrome took over was a rather insane push, about the same level of intensity as IE6, from Google, using everything: - artificially reducing performance of Firefox on key Google properties (Google Calendar, YouTube) - bundling Chrome with Adobe - ad campaigns on the front of Google where no one else has been allowed to serve ads (this alone must have been worth billions) - lies ("switch to a better browser" they wrote even when I was using Firefox) Google needs to be punished - big time - for this abuse.
- dmitriid 4y ago
  They keep doing it: https://twitter.com/dmitriid/status/1625756307297914883 https://twitter.com/dmitriid/status/1625756307297914883
- Miraste 4y ago
  Firefox was slower than other browsers at the time. A lot slower, and buggier. There are plenty of benchmarks. I’m a Firefox user now, but before Quantum I didn’t touch it because it really was terribly dated.
  - eitland 4y ago
    We might have different usage patterns. I regularly ran it with multiple extensions and 400 - 600 open tabs and didn't feel Chrome was better. And I'm the kind of person who can start a 2 hour troubleshooting session over a few tens of milliseconds unexpected lag. Edit: maybe Chrome was hopeless with multiple tabs or maybe one of the older memory saver extensions was so much better it made up for it, or maybe it just matched my hardware/SW at the time extremely well (high end HP laptops with Windows or Linux), or maybe it was just a feeling, I don't know. But I know I spent a significant part of my work day in the browsers and Firefox felt significantly better even when I wanted to try the then new and cool Chrome.
    - 4y ago
2h 4y ago
> The idea of a well-defined extensions interface is not a bad idea. when I am forced to register on addons.mozilla.org, just to install an extension that I wrote, yes, that is a bad idea. Give users the option to say "yes, I understand that this is not an 'approved' addon. install it anyway"
cxr 4y ago
> Remember that decade where Firefox shed market share to Chrome for being too "slow" and "bloated"? Yeah, and it was that way because Mozilla couldn't change a damn thing without half of the entire extensions ecosystem imploding with every release. This is misleading. Like wildly so. The imprimatur that the Firefox team was working under meant that they absolutely could, and very often did, break things from release-to-release. The long, slow decline related to slowness at the core of Firefox had very little to do with extensions (the unwillingness to break them, that is). The real reason is that the work needed for what was eventually delivered in the overhaul that made XUL obsolete was work of the sort that takes a long time to complete. If anyone had stumbled upon working patchsets for those goals stuff through divine revelation and had the ability to say so, then they would have broken things sooner. If anything, keeping XUL extensions around while all this work was being done helped prop up Firefox's user numbers for a while longer. (Compare to if XUL, while still technically viable, had been killed 10 years ago with a feature flag by fiat and then multiprocess, parallel rendering, and other deliverables related to Gecko Rustification were still as many years away as they actually were.)

by kibwen 4y ago

adra 4y ago

If they cared and their slowdowns were simply related to addons, they could always sample the overhead of said addons and show a warning. My moderate use of addons in FF didn't feel too aggressive, but then again I'm not in the clique with dozens of open windows. There were times of fast/slowness in FF. It was never bad enough to chase me off the platform, but to say the slow ess was simply saddled on addons is probably disingenuous.

Karellen 4y ago
It's not that the addons were slow. It's that the architecture in Firefox that was needed to support the addons was slow - even if there were no addons in use.
spiffytech 4y ago
The slowness wasn't caused (just) by slow addons. As I remember it, Firefox was unable to move to a multi-process architecture as long as old extensions were supported.
- mook 4y ago
  My recollection was that they had some multi-process things, though the problem was that they had to keep breaking extensions as they added more and more. I believe multi-process NPAPI plugins was somewhere around 3.6 or 4? (Of course, 4 took forever to ship too… that was great for extensions though, because it meant no API breakage during that time.)
adjav 4y ago
It's not that the add-ons were slow, it's that the architecture built to support those add-ons made the browser as a whole inherently slow. Everything was quite siloed, and required a series of dynamic dispatches to accomplish anything. This allowed extensions to easily change lots of core functionality, but also meant that the entire Firefox codebase had become a public API, and practically any change made would break something.
deleted 4y ago
[deleted]

modo_mario 4y ago

>Remember that decade where Firefox shed market share to Chrome for being too "slow" and "bloated"? The only part I remember where Firefox was notably slower was videos when Google led Firefox for a ring around the rosie when they singlehandedly decided to use a proprietary codec for their youtube videoplayer after first making everyone believe they were working on using a different one which FF started working on supporting. I can't count the amount of complaints i heard of firefox being slow there.

imbnwa 4y ago
Is this when you had to make sure you were brute forcing the HTML5-based playback?

eitland 4y ago

> Remember that decade where Firefox shed market share to Chrome for being too "slow" and "bloated"? Except it wasn't. I used Firefox a lot on Windows and Linux and didn't have the slightest problems. The only reason I see why Chrome took over was a rather insane push, about the same level of intensity as IE6, from Google, using everything: - artificially reducing performance of Firefox on key Google properties (Google Calendar, YouTube) - bundling Chrome with Adobe - ad campaigns on the front of Google where no one else has been allowed to serve ads (this alone must have been worth billions) - lies ("switch to a better browser" they wrote even when I was using Firefox) Google needs to be punished - big time - for this abuse.

dmitriid 4y ago
They keep doing it: https://twitter.com/dmitriid/status/1625756307297914883 https://twitter.com/dmitriid/status/1625756307297914883
Miraste 4y ago
Firefox was slower than other browsers at the time. A lot slower, and buggier. There are plenty of benchmarks. I’m a Firefox user now, but before Quantum I didn’t touch it because it really was terribly dated.
- eitland 4y ago
  We might have different usage patterns. I regularly ran it with multiple extensions and 400 - 600 open tabs and didn't feel Chrome was better. And I'm the kind of person who can start a 2 hour troubleshooting session over a few tens of milliseconds unexpected lag. Edit: maybe Chrome was hopeless with multiple tabs or maybe one of the older memory saver extensions was so much better it made up for it, or maybe it just matched my hardware/SW at the time extremely well (high end HP laptops with Windows or Linux), or maybe it was just a feeling, I don't know. But I know I spent a significant part of my work day in the browsers and Firefox felt significantly better even when I wanted to try the then new and cool Chrome.
  - 4y ago

2h 4y ago

> The idea of a well-defined extensions interface is not a bad idea. when I am forced to register on addons.mozilla.org, just to install an extension that I wrote, yes, that is a bad idea. Give users the option to say "yes, I understand that this is not an 'approved' addon. install it anyway"

cxr 4y ago

> Remember that decade where Firefox shed market share to Chrome for being too "slow" and "bloated"? Yeah, and it was that way because Mozilla couldn't change a damn thing without half of the entire extensions ecosystem imploding with every release. This is misleading. Like wildly so. The imprimatur that the Firefox team was working under meant that they absolutely could, and very often did, break things from release-to-release. The long, slow decline related to slowness at the core of Firefox had very little to do with extensions (the unwillingness to break them, that is). The real reason is that the work needed for what was eventually delivered in the overhaul that made XUL obsolete was work of the sort that takes a long time to complete. If anyone had stumbled upon working patchsets for those goals stuff through divine revelation and had the ability to say so, then they would have broken things sooner. If anything, keeping XUL extensions around while all this work was being done helped prop up Firefox's user numbers for a while longer. (Compare to if XUL, while still technically viable, had been killed 10 years ago with a feature flag by fiat and then multiprocess, parallel rendering, and other deliverables related to Gecko Rustification were still as many years away as they actually were.)