25 ms·

Why Did Mozilla Remove XUL Add-Ons?

• fouc 6y ago
  > And then, as someone pointed out on reddit, I realized that we still haven’t taken the time to explain in-depth why we had no choice but to remove XUL-based add-ons. > * very quickly, add-on developers realized that anything they did could break anything else in the system, including other add-ons and Firefox itself, and they often had no way to prevent this; > * similarly, anything Firefox developers did could break add-ons, and they often had no way to prevent this; > * also, some of the changes that Firefox needed to remain competitive with Chrome were going to break most add-ons immediately, possibly all add-ons in the longer term; > * oh, and by the way, since add-ons could do everything, they could very easily do anything to the operating system, from stealing passwords to pretending to be your bank. --- It's a really long article with lots of background and technical detail, so I felt it safe to include a larger summary of the basic points than I normally would.
  • jolmg 6y ago
    >> * also, some of the changes that Firefox needed to remain competitive with Chrome were going to break most add-ons immediately, possibly all add-ons in the longer term; This is probably the most important point. The other points apply to almost any software that supports addons, including emacs, vim, zsh, etc. and they're not really an issue. >> * very quickly, add-on developers realized that anything they did could break anything else in the system, including other add-ons and Firefox itself, and they often had no way to prevent this; So they're careful. Any add-on that breaks other stuff doesn't really get adopted. Emacs shares the same namespace for everything. Addon developers just namespace their stuff by putting a prefix on their identifiers. It's not really an issue even for them. >> * similarly, anything Firefox developers did could break add-ons, and they often had no way to prevent this; So don't change Firefox so drastically. Well, I'd say it's nice for software to be stable, but web browsers are a good exception to that. If Firefox didn't try to keep up with Chrome, Chrome would probably have greater dominance. But yeah, other software would just be more stable. When a change needs to be made, the benefit is weighed against the potential of breaking addons, but I imagine that's probably OK with addon developers as long as the change was reasonable. >> * oh, and by the way, since add-ons could do everything, they could very easily do anything to the operating system, from stealing passwords to pretending to be your bank. Most times, addons are almost like any other program, and should be judged accordingly before installing. I imagine even after the restrictions were placed on addons, they're probably still capable of quite a bit of malice.
    • gibolt 6y ago
      Codebases and products aren't that simple. Changes and maintenance cost money and time. In this case, they deemed it to not be worth the expense to resolve the potential security issues (which can never be truly resolved).
    • marcinzm 6y ago
      >Any add-on that breaks other stuff doesn't really get adopted. Yes it does, Firefox is a mainstream browser not a niche product used by experts. Most people couldn't even figure out which of their fifty extensions was causing issues. So they just used Chrome.
      • Polylactic_acid 6y ago
        This is exactly it. Normal users don't think "Huh firefox is crashing, I'm going to disable addons one by one to work out if one of them is the cause" They just think "Wow, firefox is super buggy, I'm using chrome now" And then every time they see firefox mentioned online they leave their comment about how its super buggy and crashes all the time.
        • GoblinSlayer 6y ago
          I just had an idea: to install an extension require authentication by a one time random password, show the password in a modal window without ability to copy, the user will have to remember the password and type it into a field. The password length is equal to the number of installed extensions, so to install 50th extension, you need to type 50 character password.
    • duskwuff 6y ago
      > So they're careful. Any add-on that breaks other stuff doesn't really get adopted. This wasn't true at all. A lot of popular addons interacted with the browser XUL in incredibly intrusive ways. In particular, addons which altered the browser's tabbed browsing interface and/or behavior (like the various Tab Mix extensions, as well as Tree Style Tabs) tended to do so by making radical modifications to XUL, which would often break other extensions which interacted with tabs. > Addon developers just namespace their stuff by putting a prefix on their identifiers. That was not standard practice, unfortunately. Conflicts between extensions were commonplace; it was a rule of thumb to avoid installing multiple extensions which interacted with the same browser feature. > So don't change Firefox so drastically. This would have meant effectively freezing most UI development, to say nothing of more ambitious projects like e10s (multiprocess browsing). It would have led to the inevitable death of the project by stagnation. > Most times, addons are almost like any other program, and should be judged accordingly before installing. You heavily overestimate the degree of scrutiny that users applied to extensions. The fact that they could be installed from a web interface made users treat them very casually. > I imagine even after the restrictions were placed on addons, they're probably still capable of quite a bit of malice. XUL-era extensions had vastly more power than WebExtensions. They were equivalent in power to native executables -- they could run native code, read/write any file on the system, and communicate with any host, all without confirmation -- and there wasn't even any framework to allow developers to voluntarily restrict their power, because they ran in the same context as the rest of the browser chrome.
  • perryizgr8 6y ago
    > also, some of the changes that Firefox needed to remain competitive with Chrome were going to break most add-ons immediately, possibly all add-ons in the longer term; Sad part is that we lost extensions and Firefox is still slower, glitchier than Chrome.
    • bayindirh 6y ago
      Note: This is a comment I wrote to another article in HN and it still holds today: No. Just, no. I want to share something that I experienced very recently. I use Firefox and Chrome (just for using Taskboard) at work. I also use Firefox at home. Both systems are Debian. The perceived browser speed was Chrome (Work) > Firefox (Work) > Firefox (Home). I always thought it was about DNS resolution, so I started running DNSMasq at home on an OrangePi Zero but, it didn't make much difference. Two days ago, my home ADSL modem suddenly died. I replaced it with a more modern version and everything about speed has changed. Now The speed of Firefox at home is equal with the speed of Chrome at Work, Firefox at work is slightly behind. It can be said that Firefox is much more sensitive to network parameters like DNS response times, but its rendering engine and other capabilities are not behind Chrome.
      • nix23 6y ago
        > Now The speed of Firefox at home is equal with the speed of Chrome at Work, Firefox at work is slightly behind. Ehhh ;)
      • jeroenhd 6y ago
        As an avid Firefox user, the performance difference between the Javascript engines in Chrome and Firefox are always obvious to me. Firefox's network code, render pipeline, and everything else that gets the document to the screen is either just as fast or even faster than Chrome. However, the Javascript engine leaves something to be desired; the trend to make everything an application has ruined the performance of many sites. There's also downsides to the way Firefox protects your privacy. If you enable the default privacy blocking, some resources fail to load on websites, making many websites load fallbacks or lag while they're waiting for their ad script to initialize. Finally, I've noticed Firefox has significant performance issues in video decoding compared to Chrome. This manifests itself as memory leaks and some tabs being frozen (every tab within the same browser subprocess, basically) and can be resolved by killing the process that's been messed up, but it's still an issue for normal use. All in all I prefer Firefox, but there's still plenty of ways it can catch up to Chrome. If your work involves a lot of web applications, there's no denying that your experience in Chrome will be quicker.
  • ekianjo 6y ago
    > * oh, and by the way, since add-ons could do everything, they could very easily do anything to the operating system, from stealing passwords to pretending to be your bank. So now there's way less things that add-ons can do, and it's supposed to be all peachy for Firefox users? Talk about competitiveness.
    • KMag 6y ago
      They're much better off starting with a highly restricted sandbox and extending that sandbox in safe ways when demand is demonstrated. The alternative is letting their largely tech-naive user base install all kinds of add-ons under the illusion that it's no more dangerous than installing phone apps from an audited walled-garden app store. Mozilla doesn't have the resources to audit all of the add-ons out there, and generalized automated auditing with a wide-open API would require solving the halting problem. (Accurately enumerating all reached states of a Turing-complete program would allow you to check if it reaches the halted state, thus solving the halting problem.)
      • cultureulterior 6y ago
        But they don't extend the sandbox (Look at tab tree). Also, it's impossible to demonstrate demand for an extension that doesn't exist.
        • takluyver 6y ago
          I'm not sure what you mean about tab tree. There are tab tree WebExtensions.
          • eitland 6y ago
            yep, but you either have to let it coexist with the main tab bar or go further and further to manually disable that.
          • chaorace 6y ago
            Yes, but they are pitifully weak compared to the same addons back when they were implemented in XUL. It's not just because XUL was more free. WebExtensions as an API just lacks the scope for such enhancements. Mozilla essentially copies Google's API and they're very hesitant to make customizations, so major enhancement requests will just sit around for years without traction. I'll list out a few major issues with the current API for the sake of example: * No native hotkeys. Ok, fine, there are technically native extension hotkeys, but they break so often that nobody uses them. Even if they were fixed, the bindings are arbitrarily limited to two-modifier combinations. Instead, you're stuck hacking around the limitation by injecting hotkeys into each individual page via JS. If the page you're on isn't a normal webpage (new tab, 404, PDF...), you're out of luck. It's mouse time. Imagine the pain of writing and rolling your own high level key binding API, now imagine the additional memory/compute from running that in every single tab instance. This is already a huge mess that makes any tab extension a second-class experience. * UI extension is hopelessly neutered WebExtensions basically have 3 main places where you can render UI: solo pages, a toolbar popout, and the sidebar. Of these three, only the sidebar is a permanent, persistent place that works for the purposes of a tab extension. Unfortunately, the sidebar is hopelessly neutered. The sidebar is shared between all extensions AND the native bookmark/history managers, so bad news if you need it for something else! Since it's shared, you can't control the size/position programatically (Oh yeah... and the manual resize threshold is limited to about 1/6 horizontal screen width). To add insult to injury: the sidebar steals page focus, so I hope you enjoy clicking back into the web page every time you interact with the sidebar UI via mouse! This dovetails nicely with point #1. There's no way to bind a key to your extension's sidebar. That means you can't toggle your tab bar (a la F11). It also means you have to fish for your mouse, fiddle with the toolbar, then switch sidebar panes any time you lose the sidebar for any reason. Imagine the pain of supporting an extension that literally does nothing unless you get your users to dig into the toolbar and enable a little-known UI element. Now... imagine the pain of asking them to do that, repeatedly, whenever it goes away. * Horizontal tab bar is a pipedream Your control over actual tabs, in the actual tab bar, is incredibly limited. If you're not outright hiding the tab bar and replacing it with a sidebar hack, it's basically guaranteed to be a mess. You cannot style nor group tabs programatically. All you can do is hide or reorder them, which is a pretty bizarre decision, imo... The best that anyone can do for non-overhaul extensions, like "tab grouping", is stashing the UI away into the toolbar popout menu. I hope it's fairly obvious why this isn't an ideal way to present that information, especially when you consider that it's a focus-stealing modal.
• roca 6y ago
  It's a good article, but in my experience explaining this stuff over and over again in HN and other fora, people don't actually want to know. They have their narrative and they're sticking to it.
  • zeveb 6y ago
    My issue is simply that I want an extension mechanism which I can use to do anything to my browser. For me, 'extension security' means 'I must write C++ to add the functionality I want,' and I never, never want to write C++.
    • sudosysgen 6y ago
      What prevents you from writing a patch for Firefox then? After all, it is one of the great advantages of FOSS. At this level of power you'd likely have to change the addon every upgrade anyways.
      • smegger001 6y ago
        because what you are purposing is fork a browser which is only slightly less complicated than fork operating system and involves a major investment in time/money to maintain.
        • newscracker 6y ago
          To whatever extent, there have been forks that are still alive today that support XUL extensions. Pale Moon [1] is one of them. [1]: https://www.palemoon.org/ https://www.palemoon.org/
        • sudosysgen 6y ago
          So would an extension with that kind of power. FWIW, extensions as they are already do require quite a bit of maintenance, and it is also reasonable unlikely that any one source file would be modified in one given update.
      • 6y ago
• newscracker 6y ago
  > I was very surprised to see that, years after it happened, some community members still felt hurt by this choice. Actually, it shouldn’t be surprising at all since people lost a lot of useful functionality that still do not have replacements today. Users were not stuck on XUL as a technology. They cared about functionality and power user functionality! I’m using mainline Firefox and not some fork that still supports XUL addons, but I still miss not having good replacements for:† * Tab Mix Plus (I haven’t seen any replacement for this; and if you haven’t used this in the XUL world, you wouldn’t know the value of it) * Lazarus (form saver) * Session Manager (no, other session saving extensions still feel iffy to me) For reasons I haven’t delved into, these extensions cannot live in a WebExtensions world today. So yes, I’m one of the people hurt by the choice not of removing XUL, but not providing alternatives even several years later. > The main drawback is, of course, that WebExtensions do not give add-on developers as much power as the promiscuous extension mechanism. I hope that all the power that add-on developers need can eventually be added to WebExtensions API but that’s something that takes engineering power, a critical resource that we’re sorely lacking. I don’t have a lot of hope since years have passed with progress in making some more addons work with WebExtentions but not really close to being there for other addons. Though the Firefox team has said it’s currently not planning to implement Manifest V3, if and when it does (and depending on how it does), that could potentially make uBlock Origin obsolete. That would be a much larger blow to the users. †: Please let me know if you have suggestions for great replacements for the first two extensions.
  • fireattack 6y ago
    They also made lots of promises about supporting these popular addons in WebExt era in particular, you should still be able to find plenty of meta-bugs about them on Bugzilla [1]. Of course, most of them never happen, and people are disappointed. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1226546 https://bugzilla.mozilla.org/show_bug.cgi?id=1226546
  • mintplant 6y ago
    uBlock Origin is important enough to Mozilla that it's featured prominently on the add-ons pages, it was the first add-on made to work on the new Firefox for Android ("make uBlock work" was its own milestone item), and Mozilla developers have actually contributed design work back to the project. Couple this with the positioning win of having uncrippled blocking compared to Chrome, and you can rest assured that Firefox won't break uBO.
• filmgirlcw 6y ago
  This is a great article but it saddens me that it had to be written because all these years later, community members are still mad their extensions don’t work. I guess I’ve underestimated all these years that what David described as the problems with XUL and the reasons it had to go away weren’t commonly understood. As the post states, it was clear as far back as 2010 (and honestly earlier), that XUL extensions were both Firefox's killer feature and also the reason that it got its ass kicked by Chrome (and to a lesser-extent, Safari). Extensions were amazing but the tax it created for performance, development, and security ended up becoming what made the browser so slow. Chrome and Safari didn’t have extensions but they had speed and built-in features that replicated many of the most popular extensions. And once Chrome added extensions support — and support that didn’t require that add-on development tax — it was over. I found this bit of the post really telling: > And yet, there was no choice for Mozilla. Every day that Mozilla didn’t ship Electrolysis was one day that Chrome was simply better in terms of architecture, safety and security. Unfortunately, Mozilla delayed Electrolysis by years, in part because of the illusion that the Firefox benchmarks were better enough that it wouldn’t matter for a long time, in part because we decided to test-drive Electrolysis with FirefoxOS before Firefox itself, but mostly because we did not want to lose all these add-ons. >In the end, Mozilla decided to introduce WebExtensions and finally make the jump towards e10s as part of the Quantum Project. We had lost years of development that we would never recover. This aligns with what has always been my personal view which is that Mozilla waited too long to make the changes it needed to compete with Chrome and by the time it finally did the hard thing and lose extensions and start over. When you consider that there was still time after Chrome was released but before Quantum where IE had the largest browser share (it wasn’t a long period of time post-Chrome, but it existed), that’s indicates to me that there was time both before and after Chrome's introduction for Mozilla to rip the band-aid off and drop XUL for the greater good of the browser. After all, IE didn’t have extensions in any comprehensive way, which could have given Firefox to refactor and approach. Sadly, Mozilla waited too long. But what really makes me sad is that there are still diehards mad that XUL died. When to me, we should all be angrier that it was allowed to live as long as it did.
  • thayne 6y ago
    > community members are still mad their extensions don’t work I suspect a lot of these people aren't very familiar with the details of the technology involved, or the tradeoffs involved. The were simply (understandably) upset when suddenly their favourite extensions stopped working. And in the early days WebExtensions, there weren't any good replacements for a lot of popular plugins. Even now, there's no way to do some of the things plugins did before.
• jd3 6y ago
  While I understand from a technical and business perspective (particularly due to the security implications of needing to manually review each and every new addon) why Mozilla eventually went down the WebExtensions route, having personally revived the old XUL/XPCOM "MessageFaces" addon (a Plan9/unix era vismon/faces knockoff for Thunderbird/SeaMonkey) from 2004 when I was in college in ~2016, I was devastated to hear that Mozilla was removing support for XUL/XPCOM and the Add-on SDK from Firefox. Nothing that the extension achieved is even remotely possible anymore — adding custom column in mailbox Thunderbird XUL, custom icon vbox in the Thunderbird mail header, reading from a browser profile directory to display picons, windowed preferences, etc. I find this sad. https://github.com/JohnDDuncanIII/messagefaces/ https://github.com/JohnDDuncanIII/messagefaces/ http://cs.gettysburg.edu/~duncjo01/sites/messagefaces/ http://cs.gettysburg.edu/~duncjo01/sites/messagefaces/ https://kinzler.com/picons/ftp/ https://kinzler.com/picons/ftp/ What's most sad to me is that my workflow was never quite the same after I stopped using SeaMonkey with many of the famous XUL-based extensions (Old Addons Page, Chatzilla, MessageFaces, etc.) — it was aesthetic bliss, particularly with the Orthodox (Netscape/Mozilla Suite) complete theme. I've ranted about this in the past, but I still feel like XUL was a bit ahead of its time (see Facebook's JSX). Had Mozilla invested more development time in fleshing out the XULRunner APIs and marketing it as a universal platform-independent "native" UI language, perhaps the modern web ecosystem would look a bit different today. I fear that the web today is slowly converging, aesthetically speaking, through the further limitation of site interfaces and UI, into a corporatized unary devoid of any creativity/novelty.
  • narag 6y ago
    I still feel like XUL was a bit ahead of its time But you said that you understand that from a technical perspective they had to replace it. That sounds more like a dead end than ahead of its time, unless there's something more? IMHO, it was the wrong solution for a number of problems. Most of them don't exist anymore.
    • jd3 6y ago
      Sorry, i should have clarified — i feel like XUL, at a very early stage in the web's development, helped inform what advanced / platform independent interfaces might eventually look like (Facebook JSX -> React -> React Native, svgs, dom parsing, etc). In recent years, particularly through the proliferation of things like JSX, javascript with XML-based extensions seems to be quickly becoming (for better or for worse) the dominant interface rendering paradigm. I agree that XUL was, ultimately, probably the wrong solution due to a number of reasons, but its effects are definitely still somewhat visible in the ecosystem today. What i'm still trying to figure out is how we recapture the freedom and aesthetic creativity that thrived during the early years of the web. We can argue that this was mostly a cultural/demographic shift in users, but I would also argue that, as McLuhan noted, shifting interfaces (particularly through a uniformity of aesthetics) can influence culture.
• InfiniteRand 6y ago
  I understand the reasoning behind why XUL and XPCOM had to go, but I learned about this technology when I was in college, just starting to become really passionate about technology, and Mozilla sold these things as "important" ideas, technological paradigms that were not just the best way forward but would make the world a better place by making development easier, exposing more things to power users, allowing better sharing of common components, etc. Except in the end these were not the best way forward (well, at least for now, old technological paradigms do come back periodically, making the whole idea of an obvious unified "best way forward" questionable), and so Mozilla had to ditch them, and I understand that. But that means when Mozilla is preaching that WebAsm or Rust or whatever is a truly revolutionary technology that will save the world, well, I don't ignore Mozilla, I just don't trust in their technological foresight like I used to. In the bigger scheme of things, I tend to be more skeptical that programming paradigms like this really are revolutionary in general. Programming paradigms are interesting ideas, but I no longer see them as some forward march of progress that is paving the way to a golden age of technology. I feel a little silly that I once thought this way, and a little silly for once being as passionate as I was for Mozilla.
  • jen20 6y ago
    Rust - noted by a wide cross-section the industry as a huge step forward in memory safe languages - and XUL seem like an unfortunate equivalence to draw.
  • jonchang 6y ago
    I think you're confusing the implementation with the idea. XUL wasn't the right path forward for bringing web technologies into the desktop as we can see with the failure of XULRunner but a ton of apps are written today with Electron and HTML5. E4X was an interesting idea bringing XML into Javascript as native objects, but the ultimate implementation lives on as JSX with React.
    • sfink 6y ago
      As someone who had to maintain E4X within SpiderMonkey: sadly, that's another great example of the wrong technological path. JavaScript is too dynamic, it gives you too much rope to hang yourself, and E4X was apparently not designed with that in mind. It was so nice when we removed E4X and didn't have to worry about `x` being an object during a lookup `obj[x]`. To give an example of the flavor of issue: when building an array (even from a literal), you couldn't push a series of values to the stack and then construct an array out of them, because with E4X between elements 2 and 3 you might end up invoking arbitrary code with access to the array so that it establishes a setter on element 4 and adds a `valueOf` hook to what you're passing as element 5, but oh wait that's the same object you already inserted as element 0, and anyway the array might be frozen now and... (I'm making this up; I know the issues were similar to this but I probably don't have the details quite right.) E4X was a rich, rich source of security bugs. I'm sure a simplified form of it is possible and would be quite cool, but that niche is already filled now with JSX for better or worse.
• simula67 6y ago
  Not trying to armchair quarterback here, just speculating for entertainment > Around this time, Mozilla started paying serious attention to Chrome. Chrome had started with very different design guidelines than Firefox: > * at the time, Chrome didn’t care about eating too much memory or system resources; > * Chrome used many processes, which gave this browser heightened security and responsiveness by design; > * Chrome had started without an add-on API, which meant that Chrome developers could get away with refactoring anything they wanted, without this development tax; as Chrome introduced their extension mechanism, they did it with a proper API, which could usually be maintained regardless of changes to the back-end; Was it possible to do this inside Mozilla? Release a new browser with different branding that does not have these handicaps. Then, let the marketplace decide which browser to pick. If it won out, announce publicly that ongoing investment would be on the new browser.
  • jonchang 6y ago
    This sounds like a pretty bad financial and strategic plan. So you suggest that Mozilla should have concurrently developed two browser engines, doubling the cost of its engineering while also competing with itself?
    • throwanem 6y ago
      Like what they did with Servo?
      • jonchang 6y ago
        Servo was always a research project, and not a full browser replacement intended to compete with Firefox. As the article states, many components of Servo eventually ended up in Firefox.
  • paulryanrogers 6y ago
    I'd argue that the Firefox's implementation of the WebExtension standard (inspired by Chrome) has turned out to actually have the better API with Promises and a vendor neutral prefix. That said, you're right that the independent competition made everyone better. Sadly with Chromium becoming the defacto web spec we won't get as much innovation.
• causality0 6y ago
  The XPCOM-based extension mechanism was mostly dropped (we still use it internally) See, that's the rub. Many of us would choose to have add-ons that break every time the browser updates, or delay browser updates until our mission-critical extension is updated. You didn't give us that choice though. You said "do it the way we want you to do it or piss off." Looking at Firefox's 3% market share, most of us chose the latter.
  • cinquemb 6y ago
    Some of us didn't care because we were already running our own forks and could deal with the old way and the new way.
  • Yoric 6y ago
    Our experience is that add-on developers didn't like that. Only the few add-on developers that actually made money from their add-ons could afford to rewrite their code every 6 weeks. Clarifying the article.
• dman 6y ago
  I had written multiple XUL based addons that I used for personal productivity. When Firefox moved away from XUL/XPCom I think they removed not just an implementation (which I admit had many warts) but also the alternate vision of the Browser being extensible by end users who were almost on an equal footing with Browser developers. As a developer I can live with, support and cheer for a worse implementation of a better idea, but when you give up on that idea you rob me of any reasons I could use to support or evangelise for you. It boils down to a simple question - does Firefox intend to go after power users in ways Chrome will not or cannot? The answer to this question used to be very clear to me in the first decade, now I think the answer is no. Even the Rust based oxidation efforts seemed limited to coming up with better implementation of the same primitives that Chrome offers, I didnt see anything about offering fundamentally different tradeoffs / choices. If Firefox course corrects to going back to power users, I will be the first one to cheer them on. The vision for firefox has to be to reduce the gap between what browser developers can do and what end users can do.
  • danShumway 6y ago
    I think your comment is a much more salient criticism. In many ways, webExtensions could be a more accessible system than XUL addons if there was a serious effort to give the end-user more tools to use them. I honestly really like the overall architecture of webExtensions, and I like the idea of having more core code in modern Javascript. But there's a lot of weirdness around the ecosystem itself that makes building extensions into a chore. There's a theoretical set of changes Firefox could make that would turn webExtensions into an extremely accessible, powerful user-facing feature for on-the-fly customizing and inspecting what their browser was doing. And I don't think it would need to be that inherently less secure. It would need to approach security differently, but I feel like many of these are solvable problems, and many of the changes required (better sandboxing, active tab permissions) are stuff we want for extensions today anyway. Some of the changes that came out of dropping XUL are really good. A lot of Firefox's styling is handled through CSS now. That should be a huge accessibility win for new users, and it should provide a nice gateway for new users to think more about moving on to making their own websites using the same technology. Except... userChrome.css is hidden in a config directory somewhere and not loaded by default[0]. They built a really nice way for users to quickly add minor styling customizations, and then they hid it from end users. [0]: https://www.userchrome.org/how-create-userchrome-css.html https://www.userchrome.org/how-create-userchrome-css.html
• Animats 6y ago
  Over many years, I had to port an addon from Greasemonkey to XUL to Jetpack to WebExtensions. The number of add-on users steadily dropped as the number of Firefox users dropped. Now, if you write a Firefox extension, and it's not a Mozilla-recommended extension (something you have to beg for) anyone installing it gets a scary notice: "This is not monitored for security through Mozilla's Recommended Extensions program. Make sure you trust it before installing." This is after going through Mozila's approval and signing process. Unsigned extensions won't install at all in the release version of Firefox. Firefox extensions aren't something worth working on any more.
  • JanisL 6y ago
    > Firefox extensions aren't something worth working on any more. Unfortunately I now totally share this sentiment, I had an extension that delayed page loads in a realistic way to test slower connections. I started on back when XUL was the way to do it but dealing with the churn led me to give up. When XUL was being deprecated I ported to the newer way but I could tell that the churn was starting to get annoying and that my enthusiasm had changed. As much as I would have liked to continue work with that extension with the recent changes I'm glad I gave up when I did. I'd really like to see something change to make working on extensions feel like it's more worthwhile again. Do people think that things are likely to stabilize in the next few years?
    • dralley 6y ago
      The entire point of switching to WebExtensions was that things could be stabilized permanently.
      • deleted 6y ago
        [deleted]
    • Animats 6y ago
      Browser extensions are probably going to go away, at least in Chrome. Google needs to control ad blocking. They've never been a big thing on the Chrome side anyway. Firefox is down to 8.61% market share worldwide. As Google removes user control, they can make Firefox go along, since they're Mozilla's biggest revenue source.
• AlexandrB 6y ago
  From an engineering point of view, it's understandable that XUL add-ons had to go - this article lays out the case very well. But from a product point of view, Firefox lost its "killer app". Now the choice to use Firefox over Chrome is mostly an ethical one. That's a tough sell for most people, and it certainly won't get someone who's never used Firefox excited to try it. Chrome may soon give Firefox a little win here by nerfing uBlock Origin, but is that enough?
  • Fej 6y ago
    uBlock Origin is already a bit nerfed on Chrome, and will likely be completely gone in the near future. That's Firefox's killer app for "regular" users, and power users too. It's a matter of getting the word out. Mozilla likely won't outright bundle its features as to not completely alienate Google, since they are their main source of revenue, but seem to be okay with promoting it otherwise, as it is on the front page of addons.mozilla.org and was the first extension (and the only one, for a time, and still only one of nine) supported in the new Firefox for Android. There are also "normal" users who do not care about blocking ads and tracking, or do not know about the performance issues, malware risk, and other reasons for using a blocker and have not made such a decision, trusting the browser to act in the best interest of the user. (We know that last bit doesn't work anymore.) (Regarding uBlock Origin, gorhill has expressed that he will not neuter the extension to work with Chrome's API change, reference: https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-456179825 https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss... )
    • totetsu 6y ago
      From that page. w3engine: "Firefox will be abandoned in the next year" 34 downvotes. https://github.com/uBlockOrigin/uBlock-issues/issues/338 https://github.com/uBlockOrigin/uBlock-issues/issues/338
      • majewsky 6y ago
        Why should I trust this random nobody who doesn't have even a single commit in their GitHub profile page's activity list? Also, the comment you describe is from May 2019, so their timeline of "within the next year" is already refuted by reality.
• T3RMINATED 6y ago
  Mozarrela is dying
• hoseja 6y ago
  This feels analogous to videogame modding. You either let/don't prevent the modders from messing with the very core of the game, which brings total overhaulability but also total vulnerability and jankiness; or you give them a nice modding API that, depending on how much effort you put into it might be rather powerful, safe and and convenient but IMO is fundamentally crippled in comparison to the former approach, it's as if you have to imagine all the ways people might want to mod your game beforehand. Also, I have this bad taste in my mouth from Mozilla getting all that Google money just hours after sacking their developers, like it was a condition.
  • FeepingCreature 6y ago
    Afaict, all the best modding APIs are made by dogfooding them internally as much as possible, such as for scripting.
  • anoncake 6y ago
    Third option: You give them a nice modding API and let them access the core of the game. That way you gain the benefits of a modding API without restricting modders' creativity.
    • sgift 6y ago
      Only a third option if you don't care about all the problems the article tells us about. Full access by third party developers and being able to update code are simply at odds with each other. There's no way around it.
      • anoncake 6y ago
        That is simply not true.
        • Yoric 6y ago
          How so?
• Santosh83 6y ago
  Let's be clear on one thing that seems to be perpetually discussed whenever there is a Firefox thread: what has lead to its declining usage. It is not removing XUL 'power' extensions and replacing them with 'neutered' WebExtensions mechanism. It is not choosing to closely align with Chrome in terms of UI/UX and functionality. It is not the letting go of Brendan Eich and the newer (much criticised) management. It is not because of Mozilla foundation highlighting a few 'social justice' issues here and there. The decline of Firefox is because of one thing only - the enormous marketing and engineering clout of Google and their utterly ruthless, relentless, anti-competitive pushing of Chrome across Android and all their web properties and even through ads all over the world. More specifically, it is their bundling of Chrome as the default, preset browser on the world most popular mobile operating system that really swung the tide decisively in their favour. Once ordinary users got used to Chrome on Android, they would naturally seek out the same browser on their laptops and desktops, to minimise interoperability issues and maximise familiarity. And while pre-installing Chrome on Android (and by the way, it is pre-installed even on most laptop/desktop purchases by "helpful" OEMs - such is its viral reach) may not be strictly illegal as per anti-monopoly laws (because alternatives are 'freely' available on the default app store), the fact remains that if a program that comes with the OS is "good enough", the very vast majority of users will not bothering changing it, and thus Google managed to cripple all other browsers while still subtly side-stepping any potential lawsuits. So the decline of Firefox is in my opinion a social/political phenomenon and nothing to do with its technical competence or extendibility vis-a-vis Chrome. It is certainly a more than competent drop-in replacement for Chrome (unlike say w3m or NetSurf), but who will bother to do the replacement in the first place, as long as Chrome continues to be "good enough" (which is does excellently) and it doesn't outrageously hurt the user base by some extraordinarily shocking screw-up (and Facebook shows, even such odious abuse will be condoned by the user base by and large when the network effects are too big).
  • Fej 6y ago
    I would recommend readers to skim the Wikipedia article on tying, or a similar article on the subject: https://en.m.wikipedia.org/wiki/Tying_(commerce) https://en.m.wikipedia.org/wiki/Tying_(commerce) A shorter article: https://www.investopedia.com/terms/t/tying.asp https://www.investopedia.com/terms/t/tying.asp Microsoft was convicted by the US for tying Windows and IE in the 90's, and Google was more recently convicted by the EU for tying Android and Chrome. US regulators have declined so far to do the same for the latter, although the political winds seem to be changing.
• wtallis 6y ago
  This article really doesn't match my recollection of how things went down. It implies that the switch to a multi-process model (Electrolysis/e10s) was held up pending the switch to WebExtensions. But I'm pretty sure I remember a transition period during which all my XUL-based extensions were either rewritten to support multiprocess or deprecated, which was years before XUL extensions were actually killed in favor of the less-capable WebExtensions. The article talks about this like it's a path they rejected, even though I'm pretty sure it actually happened. That transition was also a lot less painful than the switch to WebExtensions: over a period of several browser releases, I watched as the list of extensions preventing my browser from turning on the multiprocess capability dwindled. All the most important and popular extensions I was using made the switch smoothly with no major user-facing changes in capability or UI, which is the exact opposite of how the WebExtensions switch went. It would really help if this article could use dates and/or version numbers to establish the timeline of events it's talking about.
  • Yoric 6y ago
    (article author) Thanks for the feedback, I've just updated this part of the article to clarify it. I don't remember exact dates, though, so I won't be able to add them. But yes, you are right, there was a time during which a number of old-style extensions were ported to be compatible with e10s. It was possible for some, impossible for others, hard when it was possible, and most add-on developers didn't port them, either because it was too difficult or because they had grown tired or the _maintenance tax_ I mention. And yet, after they had ported their add-ons to be e10s-compatible, the add-ons broke nevertheless, one by one, for all the reasons mentioned in the article. At some point, we threw the towel.
    • wtallis 6y ago
      > At some point, we threw the towel. You threw in the towel before your most important extension developers did. Well-maintained popular extensions like NoScript and TreeStyleTab remained functional throughout the e10s transition with fixes delivered before the breaking changes in Firefox made it to stable releases, but they were irreparably harmed by the WebExtension transition. Their WebExtension versions are still not up to feature parity, despite ongoing maintenance. It's quite obvious that the WebExtension model is better for users and developers of simple extensions. But it continues to not be an adequate substitute for the kind of extensions that gave Firefox real advantages over Chrome and other browsers. It's not at all apparent why those advanced, killer app extensions had to die in order to get the bulk of the extension ecosystem moved over to WebExtensions.
• gcb0 6y ago
  > addons can change things and break the browser. Good. That's a feature. I install addons. It's not a site i visit with no consideration. This is the same thinking of apple. People install random apps so let's restrict apps to the point the user cannot have a text editor on their phone! meh! This is all dumb! Now it is impossible to have the choice to install an addon for tweaking hidden options. Everyone should live with the crap that is about:config and user.js (or only about:config, because they thought user.js too dangerous on mobile too!) I trust an open source browser by random people, why not an open source addon that gives me the functionality i need?
  • Yoric 6y ago
    Did you read the rest of the article? That was not a summary of why the old model could not be kept, just of why it was promiscuous.
• noomen 6y ago
  A couple of years ago I swore I would never leave ff, but they decided to just neuter the add-ons and remove most of them. So I didnt think twice. Moved to waterfox, and then to Palemoon. I'm happy. I'm sad they're losing, but they need to be adults about it and do what needs to be done. I and many others are waiting to go back as soon as they fix things.
  • calcifer 6y ago
    This comment is seemingly a reaction to the post's title and doesn't address (or even acknowledge) the contents of article. Do you disagree with the technical rationale the author has presented?
    • sprash 6y ago
      The content of the article does not really make a technical argument. It just says "XUL can not be fast, because I said so". The code of Firefox has always been a historical grown mess with a lot of loose ends that need to be entangled. I'm convinced that a XUL version can be made fast as well if you spend the appropriate amount of engineering hours on it.
      • Yoric 6y ago
        (article author) Pretty sure I didn't write that :)
• BoppreH 6y ago
  Funny seeing this here, I just switched to Vivaldi yesterday because of this. I really wanted to use mouse gestures and Vim-like controls again, and the WebExtension version of those addons is not nearly reliable enough. The problem seems to be that those control extensions can only work by injecting Javascript into webpages, which (1) takes a moment to work when the page is loading, and (2) doesn't work in New Tab page. The effect is that even basic shortcuts like "next tab" fail to work often enough that I'm willing to switch browsers.
• moltar 6y ago
  I was pissed off and left Firefox for Chrome not because they removed XUL add one, but because they didn’t have a good replacement. Chrome extensions are ugly and have no unified design. They are glorified web pages in a floating window. I liked XUL because it provided a framework for extension authors and extensions felt like part of Firefox. I eventually returned to Firefox and I find the extensions to be not so terrible.
• thinkingemote 6y ago
  We were told why they had to remove these extensions when they did so. they also said that they would replace the APIs soon. That they (still) haven't replaced them is why we are still angry with them. A failed promise. We don't need to know why they made this change, we need to know when their promises will be kept.
• giovannibajo1 6y ago
  Thanks for the article, it provides very good insights. In the article, there are a couple of passes that mention “benchmarks” where Firefox was faster than Chrome. It sounds like those benchmarks, albeit I assume they were correct, were actually providing a distorted reality of what “fast” actually means, because I distinctly remember people (including myself) switching to Chrome in early days because it was simply objectively faster. It sounds like the existence of those benchmarks have had a net negative on Firefox: it provided a false confidence that the browser was “fast”, and possibly delayed the refactorings that eventually managed to really speed up Firefox again. You mention that Chrome used “UX tricks” but I assume what this means is that Chrome developers were actually driven by more correct benchmarks: the ones that actually translate to a better experience for the end user. Since I’m always intrigued by the topic of false benchmarking and how complex it is to do correct benchmarks that don’t fall into traps, I’d love to hear what those benchmarks you mention were measuring, and if you agree that they gave a false assurance to the Firefox team.
  • Yoric 6y ago
    To summarize, we were benchmarking for throughput: how long between the time you click and the time the operation terminates. For a long time, we absolutely crushed Chrome on most of these benchmarks. Firefox started faster, loaded pages faster, switched between tabs faster, JavaScript executed faster, downloads were faster, ... Chrome developers were benchmarking for responsiveness: how long between the time you click and the user interface shows that something is going on. And that's all that end users actually see. Chrome showed its initial window faster (although it took more time until you could actually do anything with it), was slower at loading pages (but stopped its throbber earlier), slower at switching tabs (but the screen changed faster to show you that it was switching tabs), ... Which ones were the "correct benchmarks" remains an open question, but it's clear which ones the users perceive/remember as being faster! Of course, the better architecture that Chrome used meant that they eventually got faster at throughput, too, on computers that had sufficient RAM.
• jiripospisil 6y ago
  An alternative explanation about why XUL extensions needed to go by a Firefox dev Mike Conley [0], drawing pretty much the same conclusions and then some. The same thing that happened to Firefox happened to Babel [1]. Babel's plugin API exposes the internal structures and APIs to plugins, which means they're unrestricted in what they can do, but it also means that it's very hard to change things in the codebase because you might accidentally break plugins that rely on the previous behavior / APIs. This is one of the primary motivations behind Rome [2]. [0] https://www.youtube.com/watch?time_continue=4542&v=6D6idUjkvqk https://www.youtube.com/watch?time_continue=4542&v=6D6idUjkv... [1] https://babeljs.io https://babeljs.io [2] https://romefrontend.dev/blog/2020/08/08/introducing-rome.html https://romefrontend.dev/blog/2020/08/08/introducing-rome.ht...
  • dayjobpork 6y ago
    I'd like to live in a world were instead of developers just breaking an existing api, they leave the existing, in use apis and add new ones. It's ridiculous how often shit just breaks because an api is changed in an update.
    • dewey 6y ago
      Because in 90% of the cases the API isn't removed for fun but because something in the backend changed. You can't just "leave the existing" as that still means work if you have to write some translation layer from the old format to the new format. It's not like it would be free to keep the existing one around.
    • hapless 6y ago
      That approach is what made XUL and XPCOM un-maintainable -- a giant catalog of APIs in which large fractions were legacy, but non-removeable.
    • masklinn 6y ago
      I'm sympathetic, but literally most of the article is about how hard Mozilla tried to do this, and how it slowed them to a standstill and precluded improvements entirely.
• orange8 6y ago
  > One of the topics that came back a few times was the removal of XUL-based add-ons during the move to Firefox Quantum. I was very surprised to see that, years after it happened, some community members still felt hurt by this choice. Know your users. If I wanted to use chrome, I'd have used it. What made Firefox Firefox was its powerful addon eco-system. Now its just a poor chrome imitation.
• wejick 6y ago
  When this kind of topic comes up, people are starting to talk about X things then at the end they say: 1. That's why I'm using/stopping using Firefox a while ago 2. I hope Firefox can be hanging in there, but I don't want to touch it 3. Oh look that's cool new project is awesomen, but I'm sticking with Chrome It's just interesting to see
  • Karunamon 6y ago
    1 is understandable all on its own. 2 can be explained by a feeling of betrayal. Mozilla's target user isn't me anymore, and quite frankly isn't most of the HN readership either. At least Chrome is the devil I know. Chrome's privacy "issues" are well known and documented, and are fairly trivially worked around. I'm not too worried about them claiming to be for privacy and then one day silently installing an addon that invades it. And that's not even getting into the addon mess. Or the other addon mess, where their nannying resulted in the worldwide breakage of all addons for all Firefox users. 3 can be explained for similar reasons as 2. I know where I stand with Chrome, and I already got more-or-less forcibly kicked out of the Firefox camp. There's a level of certainty here that doesn't exist with FF or whatever the new upstart browser is - I don't have this nagging fear that Google is going to do something with Chrome to make it more annoying or less useful. That is a very real fear I have with Firefox, and it's one that's been borne out repeatedly ever since addongate. If there's a choice between an option which gives the user more control and and option which gives the user less or takes some away, Mozilla usually picks the latter.
• kwoff 6y ago
  XUL in my memory is a kind of tragedy. It seemed to me to represent a future where GUIs could be programmed on any platform using an HTML-like language. Previously you had to individually write GUIs as applications, using languages like C++ or Java. Then web applications became more popular, and XUL seemed like it could sort of unify all the special applications some day. By roughly 2010, I think HTML5 was taking away some of the appeal of XUL, and at the same time the increase in popularity of smartphones led to a reversion to specially-built "apps". I hope some day there will be a popular "browser app" that everyone builds apps on.
  • Yoric 6y ago
    Mozilla made the conscious decision of supporting open standards, which meant pushing for and contributing to HTML5 instead of extending XUL. But yeah, there's still nothing quite as powerful as XUL.
• superkuh 6y ago
  Browsers that split off because of the killing of XUL and establishment of the Firefox walled garden continue to operate using XUL and the giant (and still improving) ecosystem of add-ons that defined what Firefox was. There are no problems even with a ten thousandth of the resources that Mozilla has. Mozilla removed XUL and all the power features because they were incompatible with building a chrome clone that could protect users from themselves. They did this because market share became more important than features and the vast majority of people don't want or even understand that their browser can be customized.
  • Yoric 6y ago
    Can I assume that you didn't read the article?
    • superkuh 6y ago
      No. But I can assume that you weren't paying attention back when all this happened rather than this rewrite of history. Also, did you even read the article? It literally follows the thread I laid out but then tries to justify itself. ie, "Around this time, Mozilla started paying serious attention to Chrome."
      • Yoric 6y ago
        Well, I did write that article, and I'm fairly confident that the only intersection with the narrative you're suggesting is that once sentence.
        • superkuh 6y ago
          It's likely you'll never understand why so many former Firefox users are still angry about you killing Firefox and replacing it with a user-hostile chrome clone then. But just in case you do actually care and aren't just trying to re-write history as you see it: It's because of the "fixes" you describe were all making things easier, faster, and less powerful. Those aren't what Firefox's old userbase wanted. Firefox was the customizability. Now FF is just another safe javascript engine with a GUI. The forks of FF that remained FF still exist just fine on a fraction of the resources Moz has despite all your complaints of unmaintainability.
• kevincox 6y ago
  I don't care about XUL addons. What I cared about was addons with full access to the browser. I understand that they wanted to move, and that addons would break. But I would still love to be able to list non-sandboxed extensions in the store even if they came with a big warning "this extension will probably break with every new version of Firefox". There is still functionality that can't yet be replicated with WebExtensions. For example I was maintaining VimFx as an unsigned extension for a while after it wasn't allowed in the store. Sure, it broke often, but the fixes were generally easy. However what really killed it was the lack of interest from not being able to be listed in the store and not being able to run on stable Firefox releases. If we could attract even a handful more maintainers I'm sure we could have kept it mostly up to date. To this day I can't get back some of the functionality that I lost. Firefox is now just a different chrome. Sure, it is made by a different company, but the user functionality is now almost identical. (Sure, Firefox has about:config, but that is limited to what Mozilla imagined) I'm really glad that Mozilla adopted WebExtensions. I think it is an amazing solution for most extensions. Plus it is safer and cross-browser. However there are a couple of extensions that need full access, and I wish that was still an option, even if there is no stability guarantee.
  • cycloptic 6y ago
    Honestly, your best bet now if you really want to target the stable branch seems to be to maintain a patchset on top of omni.ja. I see no reason that these type of modifications need to be dressed up like they're an extension.
    • kevincox 6y ago
      Because it is convenient. I don't want build my own Firefox distribution on every machine I use. All I want is to be able to include a script into the browser's chrome process and have an easy way to publish and share. This is basically Firefox extensions used to be. (well also XUL patches, but that could have been done with JS too)
      • cycloptic 6y ago
• deleted 6y ago
  [deleted]
• _pdp_ 6y ago
  My company and I have no interest in supporting Firefox in the future and yes, I still feel betrayed when they dropped XUL. Many people did. Even with WebExtensions, the Firefox extension review process is substantially lacking compared to the kind of developer experience I get with Chrome. The exact same extension takes a few seconds to release on the Chrome Webstore, vs. the laborious process I have to get through when releasing on Firefox. The last straw for me was when the Firefox Extension reviewers asked me to provide a full-size package so that they can compile the extension themselves to compare if it matches the one that is submitted and if the output differs by some characters due to, let's say the order of the keys in a dictionary, though, it gets rejected. It does not matter if you have been supporting this extension for many years. It does not even matter if you are shipping the same code to Chrome and Firefox as well. For companies that develop desktop-grade applications using web technologies, the only natural choice is Electron. It is stupid, for sure, because it forces developers to ship large binaries but what are the alternatives. QT? GTK? Please. The most popular non-native desktop applications are either based on Electron, Java, or some custom UI framework. XUL had the chance to be the better cross-platform UI, and it was for some time until it was killed and with that, it lost an unmeasurable amount of developer time and future loss of productivity and a chance to be an actual alternative rather than a copycat. As many others already pointed out, Firefox is Chrome, except that Chrome is still faster. The demise of Firefox will hurt many at a personal level but frankly, it will hardly have any effect on the world because at the end of the day, WebExtensions are portable and Chrome is the pioneer in this space.
  • aftergibson 6y ago
    That might be very frustrating as a developer, but considering the amount of malware distributed on the Chrome Webstore this review process makes me want to use Firefox more.
    • _pdp_ 6y ago
      I work in Security. This process produces no substantial results. They should invest into automation not some ill thought manual review process. This is part of the reasons why the Firefox extensions store is in decline. It is enough to look into the numbers to get the full picture.
• lemoncucumber 6y ago
  There is no XUL, only Dana.
• rayshan 6y ago
  This may be an unpopular opinion: I'm very grateful for all browsers to switch to WebExtensions. To me, for the web to win as a platform, standards are a must. I'm a new WebExtension indie dev. I just launched my first extension on the Chrome, Firefox, Edge stores. Opera is in review. Safari 14 took 15 minutes and 1 commend, just waiting for it to drop. I couldn't have shipped this quickly by myself if not for the WebExtensions standard. It leaves me time to focus on building what users want and telling users about what I built. Yes I did have to settle for less developer power and control. I'm totally ok with it. Feel free to AMA! [0] https://twitter.com/rayshan/status/1292270249362956288 https://twitter.com/rayshan/status/1292270249362956288
  • 0xffff2 6y ago
    >To me, for the web to win as a platform, standards are a must. What does that mean exactly? What are the other platforms that the web is competing against?
    • ebruchez 6y ago
      iOS and Android native apps with their walled gardens.
      • 0xffff2 6y ago
        Hmm. As a crotchety old man (well, I'm 32, but still), I hadn't even considered mobile. I was thinking Windows/macOS/Linux native apps as the probable alternatives. In either case though, I think this is just one more reason to hate Web Extensions. I don't want browsers to win over native applications. (Of course "applications" that are little more than a bundled browser are even worse, whether on mobile or desktop.)
        • rayshan 6y ago
          @ebruchez is right. Also by win, I really mean to compete head-to-head with the native platforms. I love a good native app as much as anyone. The recent Epic vs. Apple fight shows that we need more open alternatives like the web platform. Ones that are free to develop for and free to distribute. I'm looking at you Apple, charging me $99 for a developer account just to distribute a Safari 14 web extension in the app store.
• phendrenad2 6y ago
  A great read. However, this part remains unfulfilled: > we still haven’t taken the time to explain in-depth why we had no choice but to remove XUL-based add-ons. I'm still waiting for an acceptable explanation. The author basically says "XUL was too vulnerable to security problems and crashes" but why couldn't it be left in? I think the real answer is a mix of "We don't have the developer resources (despite millions in revenue every year) to work on it, those resources are going to develop stuff like Pocket" and "We know better than the users, and the bug reports are tiresome, so let's lock it down and disallow people from using XUL addons" This all happened due to pressure to compete with Chrome, but I think in doing so, Firefox lost it's uniqueness and became just another Chrome follower rather than a contender for web leadership.
  • Yoric 6y ago
    > The author basically says "XUL was too vulnerable to security problems and crashes" but why couldn't it be left in? There's an entire section called "The problems with XUL" that attempts to respond to this question (and another one called "The problems with XPCOM"). Do you feel anything is missing in either section?
• gwbas1c 6y ago
  As a developer, APIs changing and going away is a part of life. Apple deprecates APIs on macOS and iOS all the time. Even the concept of porting from an older to a newer OS is quite common. Everyone rewrote DOS applications for Windows 3.x, then Windows 95, then Windows NT; Everyone rewrote applications for Apple II, MacOS classic, then OSX. But, when I read this article, it exposes a clear need for powerful 3rd party browser APIs; even though the API may change between browser releases. (This, BTW, is what happens on Mac. If you develop a MacOS application, every year or so you need to tweak it.) Also, there's a clear need to install 3rd party plugins that can do things to screw up the browser. (This, BTW, is why desktop computers let you install whatever you want, and why you can sideload on Android.)