The killer feature in Chrome was and is the multiprocess implementation. I use Firefox for intranet browsing at work and Chrome for personal browsing: the former is a sloth compared to the latter, and hangs even for seconds when loading a big page whereas Chrome will happily use as many of my 12 cores as it likes and it just doesn't even slow down.
Firefox has had their comparable hack (Electrolysis?) in some prototype stage for a long time but the thing is Chrome actually delivered it... years ago. This turned the roles into a catch-up game where Firefox tries to match Chrome instead of other browsers trying to match Firefox, and the setting has remained as such since then.
The difference is still astronomical and I'm not at all convinced that a new user interface could have much effect there. The browser UI has pretty much standardized 15 years ago.
> Chrome will happily use as many of my 12 cores as it likes and it just doesn't even slow down.
I spend a lot of time profiling browsers and I don't see a lot of multicore usage when browsing in current engines. Usually layout and painting is happening for one page at the time—the tab you're looking on—and multicore performance for them is really poor in current engines.
I have not seen browsers saturate 12 cores. For example, go to [1] in your browser: no browser engine saturates maybe more than a core and a half as it chugs along struggling to reflow.
I think that Chrome- (and IE-)style per-domain process-based parallelism provides some benefits, but mainly in getting stuff like Gmail and Facebook notifications off the main thread, not really in improving throughput.
I think the main benefit of the multiprocess model is not increased performance on any one website. It is that when a website in one tab decides to calculate pi to a trillion digits, it doesn't bring down the whole browser and all the other tabs along with it.
I read that phrase as "I open as many tabs as I want and Chrome renders them all on different cores." I guess I got that partially from the subsequent mention of Electrolysis as a comparable effort.
right now my firefox uses 49 threads. Guess what? the kernel scheduler run them on all cores.
chrome uses 5 processes and 7 threads in 2 processes, 11 threads in another, 1 in nacl helper and 27 in the main process. Guess what? the kernel scheduler also run them on all cores ;-)
Although, does Firefox not use separate threads for each tab? If so, then it would seem like in normal operation, it should be possible to achieve parallelism. Of course, I do still see whole-browser lockups in Firefox, and what I really miss is the ability to actually diagnose misbehaving tabs.
Also, I think the Chrome debugger has surpassed Firefox's, especially with the experimental stack traces in asynchronous flows of control.
NoScript might be worthwhile 15 years ago, as you browsed 90s porn sites. Today, you're just making your own web browsing life difficult, hoping the "security benefits" of your paranoia outweighs all the broken functionality you'll be constantly making exceptions for, or flat out missing out on because you don't know it's there.
Other than that, it means people can't mine bitcoin with my CPUs and power bill, I'm immune to ~90% of browser-only exploits (as opposed to ones in things like flash, PDFs, etc., which I am still far less likely to get hit by than a javascript(flash, etc.)-enabled-by-default user), and a few random and generally non-critical things won't work. Even dropdown menus still work as they are generally done in CSS these days.
If a site really needs javascript, I can whitelist it while leaving google tracking scripts, adverts, disqus, etc. disabled.
It's 2014, most sites assume javascript, and the "graceful degradation" is never "graceful".
Me and all people doing front-end work I know of, who even care for any kind of "graceful degradation" (that's a minority of front-end-devs!), always go over "the layout breaks and some fonts are wrong for users with javascript disabled" with "but they cans still click the links and read the text, so we'll just leave it this way" (because the alternative will be putting at least 3x as much work into it, and nobody would pay us for it ...just as nobody would pay for a website without "live filtering" and "ajax loading" and all nowadays).
So you're basically choosing a stone-age-degraded-experience to be able to spare some CPU cycles.
(the security and privacy arguments are valid though, and you're 100% right on these... but as more and more sites become SPAs, you'll basically have no choice than whitelist more and more untill you'll have to whitelist everything)
NoScript gives you a chance to evaluate a site for trustworthiness. Yes, you have to click 1-2 times when you load a new domain that you trust, but it's worth it for that one site that looks sketchy or that you get mislead into clicking onto. For people who automatically execute JavaScript, it's already too late, but NoScript users have an opportunity to avoid this cantankerous situation.
NoScript will expose phishing schemes immediately, for instance, because it will recognize that the scripts being executed are not coming from the previously-whitelisted domain for Google.
>you'll basically have no choice than whitelist more and more untill you'll have to whitelist everything
Even if that is the case (which I do doubt), if it means I still have google analytics, advertisers, disqus, and random dodgy sites I've never before visited blocked (e.g. when a site gets compromised by injecting malicious javascript), I don't mind.
Actually, after trying NoScript not long ago my web experience dramatically improved. Where I need to enable JS I can do it in two clicks, while where I don't have to, everything is faster and not cluttered with useless stuff. I like it!
>Where I need to enable JS I can do it in two clicks
But there's no reliable way of knowing where you need JS.
It's not like every useful component on a site reveals its whole story with JS disabled. There could be a data viz animation that strengthens the topic of an article you're reading. The author refers to "the above visual" but doesn't mention it's an animation (because he assumed everyone would see the animation). All you see is a still image - the fallback to the animation. You aren't aware there's a useful animation showing the schematic of an engine part in motion, for example.
The animation was cool, you totally missed out!
However, if the way you use the web is more about fetching specific content or services from specific places - your favs basically, and you don't like to explore, then if it works for you then I won't judge :)
I'm often using different browsers on different devices and only some of them have NoScript installed, and from my experience I can tell that usually if something doesn't work without JS, it's perfectly visible that it's broken until you whitelist it. I can also tell via tiny toolbar that something is blocked on the site, so if it doesn't include lots of analytics or social media cruft then I usually just unblock it on any pages that focus on useful content.
Before I actually installed it, I had the same concerns like you described, but the reality showed that it's moot, and the advantages were even higher than expected, so I sticked with NoScript :)
I tried using Chrome (from a decade+ of using Firefox) and while it is definitely faster in some instances, it is also laggier in others. Tab switching is noticably slower for me, for instance. I also found it frustrating that it would draw an unusable interface before it was done loading, which 'felt' faster, right up until I wanted to actually use it.
Chrome has some good points though - its scrolling feels much better, one tab (flash) crashing doesn't take out the entire browser and I can just switch to another tab until it recovers and (obviously) Google products have much better performance. Ultimately though, its slowness in other areas, plus its inherrently broken mouse gestures, meant that I switched back to Firefox.
I do wish Firefox was a bit faster moving. I know there are difficulties in dealing with a huge, old codebase, but I just wish features that Chrome has had for years, like chromeless app windows and multiprocess would just hurry up. Features like window-based private browsing took years to migrate from Chrome, and it's frustrating as you said to be perpetually caught in a game of catch up.
> one tab (flash) crashing doesn't take out the entire browser
It hasn't been the case for years. Plugins are sandboxed. (plugin-container.exe)
The broken mouse gestures on Chrome are the single most important dealbreaker for me. I will never go back to a browser without good mouse support (which Chrome isn't).
Eh, I still get lockups for whatever reason, and I have to wait 30 seconds for the browser to recover, I can't just switch tab and do other things while I'm waiting like with Chrome.
Designers tend to be extremely annoyed by Chrome's scrolling. I should count the time I've heard this or something similar from a designer: "but let's use css-transitions instead of free-form scrolling, it's so-much-smoother on Chrome than that ugly chunky scroll, and most of our users are on Chrome so let's just move over that ugly free-scrolling, it's so 90's anyway" (if he/she actually got the argument this far, I'm already imagining having a foot on his/her neck and driving a chair foot through his/her skull repeatedly while splashing his/her brains on the walls...)
That's the most detrimental effect of Chrome's scroll I think: it makes designers want to look for alternatives to scrolling websites, and unfortunately for all of us, these "gorgeous" but completely user-hostile alternatives exist. And good luck if you get on such a website with js disabled if it wasn't coded in a gracefully degradable way...
>That's the most detrimental effect of Chrome's scroll
No, that is just designer's dumbness. Scrolling should be a system setting and browsers should not override it but just read and use it (I am looking at you, Firefox). And websites certainly should not override it with at all.
Yeah, but if I randomly pick any 2 Windows apps, the probability that they will scroll the same is very low. Heck, even the bultin Windows Explorer I'm staring at on Windows 8 has nice smooth scroll on the main folder pane and "chunky" scrolling for the folder tree on the left, that's two scrolling behaviors in the same window, for a builtin Windows app (!!!).
Thing are more consistent on Mac OS, but on Windows and Linux these kinds of GUI functionality are still at the "wild west" level, so the only sensible choice is to implement what's "better looking for the user" in your application, which all browsers except Chrome seem to do, btw, and they've arrived at a convergent result while doing it...
And "designer dumbness" is real, but it's root cause is in the fact that lots of good graphic designers are "control freaks", and when they know that something is "technically possible", they don't care how much work it takes, and it takes them a lot to "grok" how detrimental the overall result is for UX.
I solved the problem for myself by staying as far away as possible from "design-driven development" or teams led by designers... but it is a fact that such teams exist at lots of small agencies and startups and that they do shape the field, unfortunately.
This actually might be a fairly uncommon use case - I tend to scroll by clicking the middle mouse wheel and dragging down. On big, multimedia-heavy pages like The Verge (which can clock in at multiple megabytes in size), scrolling on Firefox is laggy, and on Chrome it is smooth.
I'm very suspicious about this astronomical performance difference you're talking about.
Like many I run both firefox and chrome all day long.
I literally cannot tell which one is faster.
Firefox does use all the cores like Chrome does btw - it's called multithreading - and both of them seem to do approximately an equal okay-ish job at it (maybe servo does a much better job but thats not useable yet).
The only times where as a user i can see chrome multiprocess model shines is:
- sec vulns where chrome sandbox is not bypassed
- stuff actually crashing or hanging
Needless to say both cases are quite rare on either browser (and when flash hangs in firefox, it does for a few seconds before firefox proposes to kill it - while in chrome it only hangs the current tab)
Note also that:
- electrolysis can be enabled right now by an about:config option
- i run firefox and chromium on linux - i guess your mileage may vary on other platforms (?)
When I do calculations in the browser, opening a second window halves the performance in the first window in FF. In Chrome the performance stays the same.
I run Firefox and last I tried Chrome it did use more RAM for the same content. However, I wonder: since Chrome runs its tabs as a collection of processes does that mean individual tabs could be swapped out by the OS without affecting the rest?
I just tried opening 30 YouTube videos with 15 additional HTML (non-Flash) tabs. My system used 6 GB of RAM (Linux 64 bit). So unless you're watching 100 YouTube videos at a time, or have more than 200 tabs open at a time, I really don't see how that's a problem.
You're ignoring the fact that many users have applications other than a browser open, and that those applications also consume memory. Start hitting the swapfile and any performance advantage disappears. It is in the best interest of everyone to make applications use less memory, since all the applications (and the OS) have to share what the system has.
> It is in the best interest of everyone to make applications use less memory, since all the applications (and the OS) have to share what the system has.
There is always a trade-off between speed and memory usage. For my use cases, I prefer this particular trade-off for a browser. I realize you might not have the same preference.
Am I the only one that doesnt like this "feature"? The reason I dont like it is because now, instead of being limited to 25% of my total CPU usage, at times Chrome happily pins all four of my cores. Granted that this is probably a result of poor plugin/webpage interaction (although, I havent been able to determine what combination...being a heisenbug and all), in Firefox, the worst case is still 25% maximum CPU usage.
You're not the only one. I can't remember the last time Firefox crashed on me. I fill those tabs up real good. It does a fine job on both my medium-spec work computer and high spec home gaming PC!
Chrome isn't for me, it's one-core-per-tab thing is not something I need or want. I hate the idea of the browser using too much system resources, I prefer how Firefox does it.
I do not think there is such difference in FF and CR performance. Both browsers are relatively close. Firefox however hangs in some common cases where as Chrome handles general cases better.
CR however is worse when it comes to multi-tab browsing with over 20 tabs!
Yes, with just a few tabs open Chrome's multi-process architecture shines at cost of being a memory hog. As a result Chrome starts thrashing long before FF.
FF 8-13 really shined in memory usage. Unfortunately even by their own internal benchmarks, it's gone downhill since since 13.
In the Firefox Nightly channel, you can test Electrolysis (e10s) using the "File > Open e10s Window" menu. Addon compatibility is still a work in progress, but many popular addons like Adblock Plus mostly work today.
In case you want to use Chrome for both, Chrome actually has a built-in multi-user system, so you can have two cookie jars. If your company uses Google Apps this would make even more sense.
This is not an issue of the design. Opera (<=12), a single process browser, had much better performance than Firefox.
Biggest problem with Chrome I see (performance-wise) is that tabs that weren't in use for a while take quite some time to load. My guess would be their memory gets swapped out. I don't know how Opera did it, but switch to any of ~hundred opened tabs is instantaneous.
Whether Opera does it or not I don't know, but in Windows at least you can lock pages in physical memory [1]. It's not really a good general purpose technique, however.
It's a lot easier to implement multiprocess when you're building a brand new product without a decade-plus old add-on and plugin ecosystem that you need to support.
Firefox has had their comparable hack (Electrolysis?) in some prototype stage for a long time but the thing is Chrome actually delivered it... years ago. This turned the roles into a catch-up game where Firefox tries to match Chrome instead of other browsers trying to match Firefox, and the setting has remained as such since then.
The difference is still astronomical and I'm not at all convinced that a new user interface could have much effect there. The browser UI has pretty much standardized 15 years ago.