| > Recently Firefox said they were moving away from threads to processes. I think that's a mistake. Killing Chrome was a pain at times because when it does hang all the child processes had to be killed independently. It was possible to restart Chrome with orphaned processes. What a mess. Your argument against a multi-process architecture is you once encountered a process-reaping bug in chrome. Can't even. > I refuse to use Chrome because it has crappy performance and usability. I worked as a platform engineer at Mozilla for several years. I heard so many unfounded opinions about <browser>'s <performance/memory/whatever> consumption that ran contrary to every benchmark and defied every attempt to extract statistics from the user that you'd think I would be numb to it. But I still get chills. The advice was always the same though. "Does this occur if you open a fresh profile without your 900 tabs or 50 addons?" -- "If I'm going to do that I might as well switch to Chrome!" -- Well, I mean, okay. > Chrome developers are crap developers and they hide behind processes because they don't have the chops to do threads. I hate to see Firefox move in that direction. Maybe Firefox needs to since Firefox is adopting Chrome extensions. But I refuse to use Chrome because it has crappy performance and usability. Hopefully Firefox doesn't move in the same direction. This is insulting to a lot of very smart people who spent an enormous amount of time working on these engines. You can't just infer two traits about random software, attribute it to the biggest technical difference you can see, and then state that as fact. A multi-process architecture is much more difficult to get right than a multi-threaded one, and every single modern browser is pursuing it because it is worthwhile on numerous axis. Citing nothing but a vague luddite sentiment, you assert the hundreds of engineers who have spent years working on chrome don't "have the chops" to "do threads". Wat. |