Bill McCloskey, a Mozilla engineer, writes about Firefox internals, including multiprocess Firefox, the Quantum project, add-on changes, and Searchfox.
HN links it for details on multiprocess Firefox, including its small memory overhead, and for Mozilla's Quantum and Searchfox history.
> "Would you mind linking to some of those blogposts."
A quick parsing of https://wiki.mozilla.org/Electrolysis yields "Memory Usage of Firefox with e10s Enabled" [1] and its followup "Are they slim yet?" [2], with [1] closing with these words:
"Simply put: the more content processes we use, the more memory we use. On the plus side it’s not a 1:1 factor, with 8 content processes we see roughly a doubling of memory usage on the TabsOpenSettled measurement. It’s a bit worse on Windows, a bit better on OSX, but it’s not 8 times worse. Overall we see a 10-20% increase in memory usage for the 1 content process case (which is what we plan on shipping initially). This seems like a fair tradeoff for potential security and performance benefits, but as we try to grow the number of content processes we’ll need to take another look at where that memory is being used."
Some comments at https://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/ also hint at pre-existing discussion on the one-process-per-tab subject, but sadly without linking to it. You'd probably followup with a mailing lists search.
[1] http://www.erahm.org/2016/02/11/memory-usage-of-firefox-with-e10s-enabled/
[2] http://www.erahm.org/2016/02/12/are-they-slim-yet/
--
As for "What's the best way for a non-contributor to follow Firefox development?", I follow https://planet.mozilla.org/ , and if that's too much of a firehose to your taste, maybe try https://hacks.mozilla.org/
As to NoScript:
- from a linked Mozilla blog post:
> [...] A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist. Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extensions as possible. [...]
(https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/)
- then, from a link posted at the end of the Mozilla blog post (in an "Update" section):
> [...] One concern people have is that their favorite add-on is no longer going to be supported, especially add-ons for power users. Some of the ones being mentioned are:
> [...] NoScript, [...]
> We’re working with Giorgio Maone, the developer of NoScript, to design the APIs he needs to implement NoScript as a WebExtension. [...]
(https://billmccloskey.wordpress.com/2015/08/21/firefox-add-on-changes/)
I would be astonished if Servo is usable as a mass-market web browser in 12 months. Writing a rendering engine is hard because there is quarter of a century of legacy to deal with. By the metric of "can I use this for 100% of my browsing needs" Servo is far from being complete.
Much of Mozilla's "quantum" work is actually about improving C++ code e.g. the Quantum DOM project [1], which is a drive to improve scheduling so that a single background tab, even in the same process, can't jank the tab you are currently using [2]. Importing servo components wholesale simply wouldn't help here because Servo doesn't have a sufficiently complete DOM implementation, and I'm not sure the implementation it has contains all the desired properties.
[1] https://billmccloskey.wordpress.com/2016/10/27/mozillas-quantum-project/
[2] I am occasionally taken to refer to this project as "Presto: the good parts"
So Firefox does support multi-processed tabs through Electrolysis (its IPC layer). From what I understand this is used primarily on Firefox OS to sandbox app runtimes.
Doing one process per tab, which is what Chrome does, comes at a very steep cost in increased memory usage. If you compare a Chrome and Firefox instance holding 20 or 30 tabs, the memory consumption is going to be dramatically different.
Bill McCloskey did a nice writeup on this back in December: http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/
His article explains how you can try out the experimental multi-process support in Firefox, but that it works differently to Chrome's. I think Chrome's way of doing it wastes a lot of system resources and that we need to be more clever about how we spend a user's system resources.
First, see https://billmccloskey.wordpress.com/2015/08/21/firefox-add-on-changes/
1. these ideas are being announced far in advance of any actual changes
2. firefox devs (see link above) actively want to support current popular extensions, by adding to the Web Extension APIs
In fact, you can participate in this discussion with Mozilla devs more directly: https://webextensions.uservoice.com/forums/315663-webextension-api-ideas
Nobody working on Firefox wants to take away your most useful extensions, become a "clone" of Chrome (or any other browser) or otherwise has ulterior motives. The goals is really about improving performance and security and making add-ons easier to write and port between browsers.
Firefox has a long way to go.
* Australis
* Electrolysis (http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/#when)
* Fx Accounts
Speed wise, I really think Fx is pretty much on par with Chrome. There are areas where Fx is faster and Chrome is faster. In general, both are great.
If you install a lot of addons/extensions, I will expect some performance hit. But that's an not excuse, yet I personally not a big fan of addons (well, addons are common in web development) anyway so that doesn't really concern me.
Memory hike usually happens with plugins (flash, java applet) but normal browsing is fine. Plus I have 16GB to spare...