So, a rather cryptic topic title, but I'm not sure how else to state what seems to be clear plans of Mozilla to deprecate just about everything that makes Mozilla and Gecko code what it is. I've listened with increasing amazement to some things that have been relayed to me over the past couple of weeks, to the point where I think people should be aware of what's happening and what's going to happen. We may see the end of extensions to Firefox sooner than anticipated. We may also see the last bastion of customizability gone for good on a shorter term rather than a longer term.
Deprecation of binary XPCOM components in extensions
Benjamin Smedberg wrote:It is time to stop supporting binary XPCOM components in extensions. These represent significant compatibility and stability risk to Firefox users. Ideally we'd stop supporting them altogether, but they are still used by the application in a few important cases.
This may bite extension developers because so far it's only been made known in the pre-release channels that not everyone will follow.
Plans for Servo/Rust
Servo/Rust is going to be a development project for Firefox that looks like it will be replacing the gecko graphics engine -- bits and pieces at a time. Mozilla has, apparently, dedicated budget for this kind of work (see bug #1175663). See also the main repository for Servo, which looks to be an effort at completely replacing Gecko once done. https://github.com/servo/servo
Deprecation of XUL and XBL
More recently, I got information about Mozilla planning to deprecate XUL and XBL from the browser back-end as well, on the shorter term (before moving to Servo). If this happens, all but add-on SDK extensions will stop working, and a good number of SDK extensions may also no longer function if they use XBL. The following was relayed* which is... very disturbing news for the way Firefox is currently running: XUL is the language/framework used to build the interface. It is an easy to learn, extensible markup language that allows you to easily build interface modules and dialog boxes (if you've actually looked at Pale Moon Commander's code, you can see how simple it is to build something like that with XUL):
We intend to move Firefox away from XUL and XBL, but the discussion of how
to do that is in the early stages. There are a ton of unanswered
questions: what technologies/best practices for web development should we
adopt in its place? How does this affect add-on developers? Is there
space for a native-code main-window on desktop like we have on Android?
How much time should we spend on this vs. other quality issues?
So, without XPCOM binary components, and without XUL&XBL, there's no extensibility left in the browser -- you can't change a native-code main window on-the-fly that easily as is possible with XUL, since it is basically built up using a markup language that can be manipulated.
And without the Gecko web browser engine, later on, what is left of the original concept of Firefox?
*This is the original text that was relayed to me:
EDIT: And more! Updated Oct 2015 to add the following.
Deprecation of extensions as a whole (XUL, bootstrap and SDK alike)
As it came out, Mozilla is now planning to completely remove support for Mozilla extensions, to be replaced with Chrome WebExtensions using a limited and inflexible API. This effectively requires all extensions for Firefox to be rewritten, and only "select ones" will have Mozilla write specific APIs for them that would allow them to perform tasks no longer possible otherwise.
We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera
For our add-on development community, these changes ... will also require redevelopment of a number of existing add-ons.
We have decided on an approximate timeline for the deprecation of XPCOM- and XUL-based add-ons.
(further down they mention 12-18 months from the date of that blog post)
Deprecation of NPAPI plugins
Yes, even the plugins rooted in Mozilla's ancestral roots (Netscape) are under fire. The reasons touted for this are "performance", "stability" (crashes) and "security", neither of which are compelling reasons to remove plugin support altogether.
The "stability" part is a non-issue, since.. we have OOPP (the plugin container). If a plugin crashes, only the plugin crashes, not the browser. So what's the bug deal?
The "security" part is the rather naive approach that users cannot make decisions based on what plugin functionality they want or need, and the extensive and user-friendly way to selectively enable plugins on individual sites is apparently "not secure enough" for Mozilla (at the surface), so the entire plugin framework will be disabled (with the notable exception of Flash being given special treatment). It's an example of "security through removing choice" like putting a browser user in a padded cell so they can't accidentally cut themselves, instead of providing a warning that a knife is sharp.
My thoughts about the real reasons
My thoughts about the real reason behind these changes? It all boils down to going for a rewrite of Firefox into something else that is merely a shell on top of a collection of system tools. This is a very common thing to see for mobile platforms where "Apps" don't have a choice but to stick to the SDK/API provided by the manufacturer of the phone OS. The underlying reason there is undoubtedly also going to be reducing the actual work Firefox needs to do.
Remember my "microbrowser"? That is doing something similar: talking to a system control to provide a system back-end with a custom front-end; but is that actually a full browser in itself? Absolutely not.
It also falls in line with moving to a second try at a "Metro-style app" (see Mozilla's browser.html effort to bring the B2G framework for mobiles (Firefox OS) to the desktop... Yes, really...). It also falls in line with what I see as Mozilla's inability to make the base technologies behind their own product work in a Chrome-like multi-process environment.
IOW: A lot of time and money was invested in technologies (e10s, b2g) that don't work with Firefox's technology or have turned out to be a flop, and instead of discarding it (and discarding non-functional code is, contrary to what some might say, a big part of programming), this investment must somehow be made to work, even if it requires a changeover of the actual product it was built to enhance.