14 DAY TRIAL // A week ago, Mozilla shed some light on its future, laying out a plan on how the browser is going to dramatically change in the upcoming months. While most of us understood "Chrome extensions were coming to Firefox," it is not as simple as we all thought.
First of all, Mozilla seems dead serious on implementing these changes. If you haven't been paying attention to what's going on in the Firefox Nightly and Developer Edition channels, the changes are already upon us. No ifs or buts.
Second of all, unlike previously thought, Mozilla is not accepting its role as second fiddle to Chrome. The Mozilla dev team has a pretty solid plan on how they can change the browser's "always crashing" image, and even if we don't like it, this includes a severe and very profound change to Firefox's core code.
To be true to my own instincts, I do believe this needs to happen. Firefox needs a new codebase. The browser has accumulated so much legacy code that everything has to be reimagined with today's Internet in mind, an Internet where speed and reliability matter as much as user customization features do.
Firefox has always been good at customizations, but as a recent study shows that most of today's users don't really care about customizations. What they care about is privacy and speed, and that's why browsers like Vivaldi and Edge, even if they're just a joke when compared to Firefox's features, tend to be more well-thought of, because they move and feel faster.
Servo, because C++ is not up to the task anymore
Making Firefox work faster requires a new engine. The Mozilla team, eventually, reached the same conclusion the IE team had when they created the EdgeHTML engine for Edge.
Mozilla's own answer to this quandary is Servo, currently just a research project, which aims to provide a new browser engine for Firefox, one that's written in Rust, instead of C++.
"Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races."
Because Rust is better suited to handle parallel code execution when compared to C++ and is also developed in house at Mozilla, this makes it the best tool for rewriting Firefox's heart.
On the downside of things, Rust has its problems as well. These are the language's immaturity, being a relatively new programming language, a pretty novel type system, and lower performance metrics when compared to C++.
Fortunately, Rust is being developed at a similarly fast pace as Dart and Go, two of Google's own programming languages, both considered mature enough to replace Java in Android, if the Oracle Java-related patent lawsuit ever goes so ugly as to arrive as such drastic measures.
Electrolysis, or multi-process support
But Servo is not the only big change that's coming in future versions. Arriving in Firefox 42 is Electrolysis, or e10s.
This project basically adds multi-process support to Firefox, just as Chrome did from its beginning. While previous versions of Firefox put all the code into one big operating system process and ran everything together, Electrolysis splits the browser's core functions from the Web content into two different processes.
This, while highly performant and security-centric, also limits some of the things add-ons are capable of doing, because some of the functions available in the browser code won't be able to reach the Web content that's being processed.
From their press release, Mozilla doesn't seem to care that this will break some add-ons, as this is seen as a necessary evil in order to achieve a higher performance level.
Electrolysis is scheduled for launch with Firefox 43, which is expected around December this year.
A new Add-Ons API
And since we're talking about breaking add-on compatibility, the hot topic around any major change to Firefox's code, we should not forget to mention the WebExtensions API, which many people seem to look at like it were the devil.
Add-on developers have expressed their hate and actual rage at Mozilla for even proposing something like this. We don't think in such extreme terms as they do, mainly because they are developers, and developers regularly hate "change" as a general notion.
A "change" for any developer requires a serious amount of work on their part. That can explain the vitriol in some of the comments you'll see on Hacker News, for example.
From a user's point of view, having an extensions system that's compatible with the one used by Chrome, Opera, Vivaldi, and possibly Edge, is a fantastic idea.
Add-on developers may be annoyed at Firefox for deprecating the old XUL and XPCOM Add-Ons API, but I, as a general user, couldn't care less.
What matters for me and the millions of other Firefox users is "choice." As long as Mozilla doesn't scalp its own Add-Ons repository and from a few tens of thousands of options I get a few hundred tomorrow morning, then everything is OK on my part.
Developers aren't really mad at the WebExtensions API if you think about it for a second. What they're mad at is the deprecation of the XUL and XPCOM APIs.
Firefox's extensions are notorious for granting developers a whole lot more access to core browser features when compared to Chrome. Developers are mad just like a baby is mad after you take candy away from it. They're mad because they've spent years learning XUL and now they see the technology (which only Mozilla uses) thrown to the trash bin.
A new add-ons API which they'll have to spend hours, days, or weeks exploring so that they'll be technically capable of porting their existing extensions.
Sure, there are some add-on developers who create both Chrome and Firefox extensions, but most of them are simple tools. The complex extensions usually require a team of developers, or use an add-ons framework like Kango.
Mandatory extension signing
Last but not least, the third decision in Mozilla's trifecta of Add-Ons major changes is mandatory add-ons signing, set to go live with Firefox 41 as an optional setting, and as a permanent feature starting with Firefox 42.
What this means in layman's terms is that Mozilla now needs to check and pre-approve every add-on you install inside your browser. If an add-on is not checked and "signed," starting with Firefox 42, the browser will refuse to install it, no matter what you do.
The decision is deeply rooted in Mozilla's new security policy, one that aims to protect users from scams and shady add-on developers.
While the browser was once known as a bastion of freedom when compared to Microsoft's limited Internet Explorer, due to the rise of malware, ransomware, scams, adware, and other security and privacy threats, the company has slowly changed its policy on this issue.
The entire process is not as apocalyptic as you think and is entirely automated. Most extensions on the Firefox Add-Ons portal have already been signed, and those that haven't were the ones abandoned and that we generally tend to stay away from because they might break with any new Firefox release.
Unfortunately, mandatory add-on signing also nullifies any advantages the WebExtensions API would have brought. While Vivaldi users can go on the Chrome Store and grab a Chrome extension they like, Firefox will not allow this.
Chrome extension developers who would want to see their code run as a Firefox add-on will need to register on Mozilla's Add-On portal and submit their code for signing.
While this isn't terribly complicated, most Chrome developers won't care enough to do so. Which basically means that Chrome extensions aren't really coming to Firefox as everyone thought, at least not if their developers don't want them to.
“Even Firefox is allowed to go through a mid-life crisis”
Contrary to popular belief, add-ons signing is not the decision that will kill the Firefox add-ons repository, and neither is the WebExtensions API or Electrolysis.
What will kill the Firefox add-on landscape is add-on developers. If, during this process of transition to its new self, Mozilla continues to give the impression it would like to plow through with its plan regardless of what add-on developer think, then most of them will abandon it for greener pastures.
To their credit, the Mozilla Foundation is not made up of stupid people. As gHacks has pointed out in one of their articles, at the same time Mozilla was announcing its new direction regarding add-ons, its dev team was also busy contacting add-on developers and providing assistance and support for its new WebExtensions API.
By making sure its developers stay happy, Mozilla is also making sure it carves more space to work on its facelift. By reworking Firefox's innards, Mozilla is also making sure it has a modern browser instead of a collection of tangled guts full of legacy code and a too permissive API.
In the end, if Mozilla wants to have a fighting chance against these newer, younger browsers, it needs to keep its add-on developers happy. If the add-on developers are happy, they'll port their existing add-ons and create new ones. This will make the users happy, and when the users are happy, then generally one thing happens: we see browser usage statistics shift.
In the meantime, let's sit back and watch Firefox go through its mid-life crisis, hope for the best, and then prepare for our own.