People blame chrome for being memory hog and it's probably exactly for this reason. I fully expect mem usage to go up for E10S release as well... As a daily FF user both at work and at home, I'm not sure if that's a good thing.
Most people still claim Firefox is a memory hog, but from my observations Chrome uses a lot more from it's one process-per-tab model compared to Firefox's single process for many tabs. It might not be significant for a small number of tabs, but as someone who frequently has 50 tabs open (I know, I have a problem), I'm concerned at how much this could increase things.
That said, memory usage isn't my biggest concern, I generally have no shortage of memory, and don't particularly care if my browser is using 1GB of RAM. If this improves stability and performance (which seems to have gotten much worse recently on OS X in particular), then it's a fair trade off.
> but as someone who frequently has 50 tabs open (I know, I have a problem)
How do people get work done WITHOUT having 50 tabs open? It's a pretty regular occurrence for me, between having MSDN, the PostgreSQL handbook, documentation for a half dozen libraries, my "read later" list, etc., there's almost never a day I am not drowning in tabs. Thankfully, the Tree-Style Tabs extension saves the day here!
I don't know why people do that. Having 50 of them open does not increase your brain processing capacity, you probably still work with like 10 at maximum. My day typically consists of 6-7 pinned ones and 10 tops dynamic. As a rule, if the tabs reach the end of 1920x1080 screen, it's time to close something :) No tree-style required.
I am normally flipping between groups of them over the course of 15 minutes, I may not touch them all within the same window of time but they all have a purpose - and beyond that the tree helps me keep track of my thought process as I typically open most links in a new tab, so I can see the hierarchy I am working with.
I'm not sure if Chrome has an option to disable it, but the thing I dislike the most about Chrome is when you open a past session and it reloads every. single. tab. Firefox is smart: it only reloads the page when you click it. This saves plenty of memory, but Chrome... oh boy.
Memory usage is closely being watched as part of the 10s transition. Of course, e10s is not a free lunch, but according to early claims [1] it's 20% more than non-e10s Firefox and half the usage of Chrome's multi-process implementation.
I'm using nightly builds since about two years and can't remember when exactly I enabled E10S. When I enabled it, I noticed around 20mb more memory usage. So imho this is a good thing, not that much memory for a lot more safety and if Firefox crashes for some reasons, all I have to do is clicking the "reload tabs" button.
It mostly feels smoother, i.e. less laggy. To me, that's most noticeable when scrolling, which comes from the added implementation of Asynchronous Panning and Zooming (APZ).
Basically, beforehand when you turned your scroll wheel, Firefox first sent a scroll event to the webpage, then the webpage could execute whatever it needed to execute on scroll, and then Firefox actually scrolled the page.
With APZ, that's now handled in parallel, i.e. it already scrolls what's there and alters it at the same time with whatever the webpage wants to do on scroll.
This also applies for zooming the page, as you might have guessed from the name, and as far as I can tell also to resizing the window.
Other than that, all animations in the browser UI are a lot smoother, too. For example, I can now just hold down Ctrl+T (which opens new tabs) and it happily chugs through playing the tab-animation hundreds of times with seemingly the only limiting factor being my screen's refresh rate. (And that's on a below-average laptop.)
I've used the developer channel and regular Firefox side by side the entire time and haven't noticed a difference to be honest. One extension I use (rikaichan) froze in e10s, but was fixed.
The goal must be a single controller ("UI") process and multiple content processes for each tab, otherwise they'll be missing out on the advantages of a multiprocess model, namely, stability and isolation.
It's not supported, but you can go into about:config and change dom.ipc.processCount to a number higher than one. I haven't had any trouble running at the number of hardware threads, minus one for the UI.
> The goal must be [...] multiple content processes for each tab
According to the wiki page you linked, it doesn't seem to be the goal for them:
"The (practically) unlimited process count is on some platforms not a realistic goal, and having a separate process for each open site instances or even sites does not seem like a reachable goal (for now at least). Which means using content processes as a security membrane cannot be a goal either."
If this is true, I don't see any advantages of e10s introduction.
They're going to find out that managing processes by themselves is going to be very difficult (similar to M:N threading), and opt for a Chrome-like model where each tab is its own process.
I don't think going full process per tab is the answer either, I think that some kind of system that adds additional processes for heavy tabs while keeping as many on single content processes would be a good middle ground.
I thought the plan was for Firefox to use the same process-per-tab model as Chrome, but this post does seem to imply that it's just 2 - "we’re using project Electrolysis to split Firefox into a UI process and a content process."
They also go on to say that "After that, we’ll be working on support for multiple content processes.", so I assume the plan is to have one perocess-per-tab eventually. I'm surprised they aren't there already though, considering this has been in the works for a few years now.
There was a period where electrolysis didn't receive much work, and then there was a second push to get it working. That's why it seems to be taking so long.
As for process-per-tab, I can't find anything official about it on the bug tracker. The problem with that option is it leads to quite high memory usage, and hides the existence of memory leaks (chrome really likes to eat my ram). We'll have to see how memory usage goes as they experiment with multiple content processes.
It is starting with just two for now, but will be increased after more optimization. There's a setting you can modify in about:config that will allow you to manually set the number of processes if you want to experiment with it.
At least Chrome is relatively fast. The only reason I use Firefox is because of a couple of plugins, but otherwise I would dump Firefox and switch to something else (and the plugins barely affect the speed). I really don't know what has been happening to Firefox in the past few months/couple of years, but that's not the browser I remember.
Try disabling all of your extensions or using the “Refresh Firefox” command in about:support. These days I rarely notice a difference between the two except on extremely JavaScript-heavy sites – things like asm.js demos, not Gmail – when E10S isn't enabled and so the UI blocks.
RAM is cheap. Getting hacked isn't (especially when you consider ransomware these days). That's the reason Chrome is the most secure browser around, and Firefox isn't even invited to Pwn2Own anymore.
That's nonsense. They did not target Firefox, because it has not made any major (architectural) changes in regards to security, since they've last targeted it.
No major changes means that there will also likely not be any new security vulnerabilities and therefore they would almost certainly not find anything new.
This does not mean that Firefox is less secure, it just means that Mozilla has not innovated much. And if you look at actual statistics, you'll see that Firefox is not behind at all.
You could maybe make a separate case that this will lead to bad security in the future, as some innovation is inevitably going to be necessary, but with addon signing, E10s, WebExtensions and Servo all up and coming, you'll have a hard time to actually defend that case.
Which is hard to do when Google competes unfairly, even illegally – which they did, for example with using AdSense for Chrome ads everywhere, and not paying website owners where the ads were displayed the normal rates, or by adding fraudulent banners "Your browser (Firefox) is outdated, upgrade to Chrome now" to Google Search.
Well, it's wrong, because it can not only be done, if Firefox has users. You don't need to care what 99% of the world population is doing. As long as Firefox exists, you can use it.
You could say that without many users, there won't enough real-world exposure, but at the same time, Firefox will also be targeted far less, so you wouldn't have to worry about security vulnerabilities as much.
And while yes, if at some point Chrome becomes Internet Explorer 2.0 and webpages target nothing else anymore, that could cause Firefox to be hardly usable, but that's then an entirely different nightmare and not anymore relevant to the current situation.
But it isn’t – the amount of open source devs working on FF depends on how many people use FF, and the amount of fulltime devs depends on funding, which depends on the amounts Yahoo or Google pay, which depend on how many users Firefox has.
With no devs, you can’t implement those features or the security easily.
And especially for security you’ll want fulltime employees.
Also, you’ll have to pay more than Google pays their Chrome devs to ensure the people will keep working for you.
We built Firefox 1.0 and shipped it to the world with zero revenue. Open Source is funny like that. Some people work on it because they love it, not because they're being paid.
Indeed, and one can surely maintain Firefox 1 or 2 easily with a bunch of volunteers.
But maintaining a whole OS with a whole virtualization layer, a whole sandbox system, several supported scripting systems, its own scheduler, its own graphics stack, and support for compatibility with any bug a competing system has?
Modern browser are reaching complexities we’ve only seen in whole operating systems before. You don’t see a bunch of volunteers maintain everything from Linux to KDE at once, it’s hundredthousands of people working in a very different way.
To be able to compete against Google, be able to force them to implement features you pioneer, and force them to avoid implementing other features, to be able to keep up with them and reach better security than them, the current Firefox team is not enough.
> Chrome is at best visible source – Google controls development, not the community
Chromium is open source, Chrome is open core. Chromium may also be cathedral (rather thean bazaar) development model, but that's only distantly related to open source or not (bazaar is facilitated by open source, but not required for it.)
Google even openly discourages forks, or any contribution that doesn’t fit their ideals.
It’s only truly open if development is controlled by a democratic community, or if it’s easily possible to be forked and competed with.
Which isn’t the case.
And for users open development is a lot more important than open source: Being able to get their own changes into the browser, ensuring the browser is made by the users, for the users.
Google may discourage forks, but there's nothing they can do to prevent one, and forking Chromium is no more difficult than forking any other project its size.
... or any contribution that doesn’t fit their ideals.
That's one of an OSS project maintainer's more important jobs. I used to maintain some decent-sized open source projects, and part of my job was to say "no" when someone wanted to add something I didn't think belonged (for whatever reason).
Forking Chrome is useless, Google can just take a bunch more of engineers to work on it, add some features to chrome, and extinguish your project again.
Forking Chrome would be like fighting against Embrace, Extend, Extinguish after you’ve already lost (which we have with Chrome, compared to what KHTML used to be like)
That's true of any large open source project, whether heavily backed by a company or not. You need both users and developers to make a fork successful.
Regardless, though, there's nothing that says the hypothetical developers of a Chromium fork couldn't devote some time to merging reasonable fixes & new features from upstream.
