Slashdot Mirror
Mozilla Announces Quantum, a New Browser Engine For Firefox (softpedia.com)
An anonymous reader writes: Mozilla is currently working on a new browser engine called Quantum, which will take parts from the Servo project and create a new core for the Firefox browser. The new engine will replace the aging Gecko, Firefox' current engine. Mozilla hopes to finish the transition to Quantum (as in Quantum Leap) by the end of 2017. The first versions of Quantum will heavily rely on components from Servo, a browser engine that Mozilla has been sponsoring for the past years, and which shipped its first alpha version this June. In the upcoming year, Mozilla will slowly merge Gecko and Servo components with each new release, slowly removing Gecko's ancient code, and leaving Quantum's engine in place.
Yes and No. It is an effort to make a new browser engine, starting with Gecko and slowly replacing parts of it until none of Gecko remains. In the sort term it can be considered an improvement of Gecko, but in the long run will be a whole new engine.
They're not actually building a new browser engine, much less calling it Quantum. This is an internal project name (project, not product!).
If I understand correctly, they've been experimenting with Servo, a browser engine they've built using the Rust programming language. Rust aims for speed, concurrency and safety, which is highly desirable but hard to achieve on modern (multi-cpu/multi-core) devices using conventional programming languages.
Now their plan is to gradually replace bits and pieces of Gecko (the current rendering engine) with parts from Servo. This is a process they already started and which will take some time to complete. Some of the benefits are already present in their nightly browser builds, others at least sound very promising.
If you want to learn more about the project and/or the resulting transition, take a look at these articles (the post at softpedia is quite misleading IMHO):
- https://medium.com/mozilla-tech/a-quantum-leap-for-the-web-a3b7174b3c12#.s4zttcbxe
- https://billmccloskey.wordpress.com/2016/10/27/mozillas-quantum-project/
(I hope this helps to clear up some of the confusion)
There have been a lot of moving pieces to the Firefox project.
* First, the code base was meant to be universal, with options to support a range of OSes and hardware. This involves a lot of not-so-sexy problems like word size, address space, endian-ness, etc. that don't come up a lot anymore. It also has it's own home-made (pseudo)thread system, because some of those supported OSes did not have nativemultithread capabilities. Since this is at the base of all code, things higher up have a lot of clunky support code.
* To make this all work, everything is modular with defined interfaces. This takes more memory, but makes for a more stable yet versatile design.
* Firefox was meant to be a lightweight version of the Mozilla browser. (Time makes fools of us all.) The idea was that CSS and javascript could be used to build out your UI as if it were a webpage.
* Building on that, since this chrome layer was never hard-coded anyway, it makes it easy to re-write with extension code. In fact, the extensions can do damn near anything by interfacing with gecko modules directly (or by building their own).
Now the problems:
* The Gecko engine is basically functional, but was never designed to do a lot of the goofy crap modern Web API standards are pushing forward. (Web API is basically aiming to make your browser into a universal interface for your entire computer. That way "web apps" have access to all the resources they could possibly need... though, sadly, almost no thought seems to have been given to making it secure.)
* Gecko is also way too bulky to ever work on a mobile phone, which is how a lot of the web is being consumed now. They had to fork and rewrite code to get out a workable android version.
* The extensions that did more than change the display meant that you either couldn't change internal interfaces, or that doing so would break everything. The way the chrome code was written meant that changing it would often break theme add-ons. Most of the time this just leads to angry users and people who refuse to update. But it also leads to a lot of bugs filed and support requests that ultimately stem from badly-coded, out-of-date extensions screwing everything up. Mozilla mostly considers this a perception problem, since the browser seems to be more broken because of the extensions.
* Firefox had a lot of preferences. These could all be edited at runtime, and took up a lot of memory with the properties themselves, and with the branch logic needed to support some of them.
* Firefox has been very leaky on a per-tab memory basis.
So where have they been going:
* legacy OSes and architectures aren't supported. Not enough horsepower to actually make the modern web work on, say, BeOS.
* Mozilla threads are deprecated in favor of real multithreading done through OS API calls.
* They've gone to a Google Chrome-like model for extensions, where there's a general extension API. They're open to expanding it however is necessary to get extensions with large market share -- such as NoScript and Firebug -- to work, but at some point we can expect that there are things they just have no interest in adding in.
* They've been trimming preferences release after release. There's not even anything to turn off javascript now unless you have an extension. (The logic is that the modern web is basically un-digestable without javascript.)