>Excellent performance and reliability. Quantum delivered a lot of performance wins, and work continues at a rapid rate on reliability. Unfortunately, to be com

>Excellent performance and reliability. Quantum delivered a lot of performance wins, and work continues at a rapid rate on reliability. Unfortunately, to be competitive on performance and reliability given Mozilla's funding required dropping XUL :( Not really true. For starters, they did not drop XUL with Quantum. In fact, they did not drop XUL to this very day[1]. The thing they did drop was XUL and low level access for extensions, copying the "well-defined" extension API from chrome[2]. This was largely a political decision, not a technical one. The aim here was to make extensions more secure by limiting their capabilities, to provide a common stable API to piggy-back on the success of Chrome and get more Chrome-only extensions on board by providing a largely compatible API, and to polish up Firefox reputation by removing the "Firefox breaks some of my extensions with every update" problem[3]. Of course, it kinda backfired, as it largely removed one of Firefox competitive features other browser lacked (extreme combustibility and very powerful add-ons), and people, especially the power users who drove the word-of-mouth, wondered why they still should use Firefox if it just feels like another Chrome. From my vantage point, it didn't polish the reputation, quite the opposite, it destroyed a lot of reputation and goodwill. >- Excellent performance and reliability. Firefox performs better for me in general[4], and it eats fewer of my system resources doing so. But YMMV, of course. >A simplified, modern UI. It's fair to argue about specifics here like "tabs as buttons", but not about simplification overall. This may frustrate power users, but power users are the vast minority. I do like the current UI, even tho I was rather skeptical at first. It's not perfect of course (when is something ever), but I like it a lot better than say Chrome's UI. Of course, given mozilla's track record in this regard, it probably will be reinvented soon :P [1] E.g. while the main UI file is now browser.xhtml not browser.xul, it's actually a mix of (x)html and xul in there, with a lot of the UI still implemented in XUL. They did remove some XUL widgets (especially those that were not actually in use by Firefox anymore, only used by either extensions before the WebExtension forced migration or by third party projects like Seamonkey), and IIRC they killed XBL (which was basically WebComponents for XUL, long before WebComponents was a thing), as XBL was particularly finicky, old and unmaintained and riddled with bugs. https://searchfox.org/mozilla-central/source/browser/base/content/browser.xhtml#123 https://searchfox.org/mozilla-central/source/browser/base/co... [2] Implementing the chrome-API badly, I might add. There is still a ton of bugs years later where behavior differs significantly from Chrome. And quite a few APIs that aren't implemented at all. In effect, every reasonably complex extension has to have browser specific code, or avoid certain APIs entirely and come up with creative work arounds that hopefully work consistently in different browser. I am not blaming the team which implemented this stuff; they did the best with the very limited resources mozilla gave them to get an initial implementation going, and then after the initial roll out from what I saw the team was effectively largely disbanded and reassigned, leaving only enough resources to kinda-maintain the existing implementation but not really enough resources to fix all the glaring parity bugs and missing features, instead hoping that volunteers would fill the gap here (and some gaps were indeed filled that way, but not too many). [3] Which was a bit of a problem, indeed, as extensions did not really have a stable API to use. While mozilla largely tried avoiding major breaking changes by e.g. providing a compat-layer if they changed something or carefully announcing such changes in advance meaning features relying on these changes were often delayed in favor of giving extensions a grace period to adopt to the upcoming stuff, this wasn't always possible and it wasn't always known in advance what change would actually break (a lot, or at least important) extensions. And such compat-layers added to the maintenance cost, and delaying features added to the impression that mozilla was slow-moving. Providing a chrome-compatible API was probably a good idea, providing only a chrome-compatible API probably not. [4] Except notoriously on youtube, where it still performs well enough, but worse than Chrome.