Linked by Thom Holwerda on Tue 9th Sep 2008 11:15 UTC
Mozilla & Gecko clones With the recent surge in WebKit adoption, many have stated to question the usefulness of Mozilla's Gecko browsing engine, claiming that WebKit is far superior. Some even go as far as saying that Firefox should ditch Gecko in favour of WebKit. Ars Technica's Ryan Paul explains why that is utter, utter bogus. "From a technical perspective, Gecko is now very solid and no longer lags behind WebKit. A testament to the rate at which Gecko has been improving is its newfound viability in the mobile space, where it was practically considered a nonstarter not too long ago. Mozilla clearly has the resources, developer expertise, and community support to take Gecko anywhere that WebKit can go."
Thread beginning with comment 329805
To view parent comment, click here.
To read all comments associated with this story, please click here.
FooBarWidget
Member since:
2005-11-11

Well isn't that the pot calling the white ceramic teapot black. Webkit zealotism? Might want to reflect back on the long running "Firefox" zealotism the online world has been suffering for years.


Zealotism against what? I've never seen Firefox "zealots" claiming that Firefox is oh-so-superior to Opera, KHTML, or whatever. They've only gone as far as promoting Firefox as superior to MSIE. But now we have Chrome, which has only been out for a few days, and we already have zealots declaring Firefox as dead.

So no, there is no pot.

Nice straw man. Certainly I have never said that.


Maybe you haven't. Lots of people certainly have. Just because you as an individual haven't doesn't make it a straw man.

For example, take a look at Ruby on Rails deployment. Most Rails production environments are multi-process, not multi-threaded. Yet people claim that Rails doesn't scale because it's not multi-threaded. Which isn't true, because processes are adequate alternatives, but the point is people *view* threads as superior.

Another example: the whole multi-core hysteria. Threads enjoy a lot of hype. Lots and lots of people say that software needs to be multithreaded if they want to leverage multiple cores. The fact is, the system *already* leverages multiple cores - via multiple processes. Despite this, the multi-core threading hysteria continues to exist, as if most people don't know that multiple processes can leverage multiple cores as well.

I'm not saying that threads really are better - it all depends on the situation. However, the fact that so many people turned from "threads are superior" to "processes are superior" after the release of Chrome, is suspicious at best. This is reason enough to believe that it has got more to do with emotions and hype than actually knowing what they're talking about.

Edited 2008-09-09 19:03 UTC

Reply Parent Score: 4

sbergman27 Member since:
2005-07-24

Zealotism against what? I've never seen Firefox "zealots" claiming that Firefox is oh-so-superior to Opera

Well, it's all relative, of course. No one is more annoying than the Opera crowd. (Except maybe some of the Stallmanites, but that's a different category.)

Many people who find browser crashes, even occasional ones, or the inability to kill one misbehaving window or tab to be an annoyance recognize that Chrome's process model makes a great deal of sense. It really doesn't matter what people say about RoR scaling. I've used it, TurboGears, and Django, (the latter 2 being Python based) and if you ask me it has nothing to do with processes vs threads and everything to do with the fact that Ruby is dog slow compared to pretty much any other available language. And I've never heard anyone claim that the problem was a processes vs threads one.

At any rate, the bottom line is that Google made a good solid technical decision, and if it did happen to change some people's minds about threads vs processes... what relevance does that actually have?

Now that both Chrome and IE (Ouch! It hurts to say that!) have implemented that beneficial architectural feature, the Mozilla guys will have to try to bolt it onto Firefox/Gecko. And it will be interesting to see how well that goes and how long it takes.

Reply Parent Score: 2

FooBarWidget Member since:
2005-11-11

Many people who find browser crashes, even occasional ones, or the inability to kill one misbehaving window or tab to be an annoyance recognize that Chrome's process model makes a great deal of sense. It really doesn't matter what people say about RoR scaling. I've used it, TurboGears, and Django, (the latter 2 being Python based) and if you ask me it has nothing to do with processes vs threads


Yes processes are useful for misbehaving sites. But that's not the point. The point isn't about questioning the real benefits and cons of processes vs threads, but the *perceived* ones. I'm saying that people suddenly *perceive* processes as being better than threads because Google's using it, and that if Chrome was developed by anybody else, the perception would be totally different and there would be no hype. If Chrome was developed by anybody else, people would scream death and murder because of the higher total memory usage, regardless of the ability to kill misbehaving tabs. And this Google hype is exactly what fuels the Chrome/WebKit zealotism.

And I've never heard anyone claim that the problem was a processes vs threads one.


A comment from http://weblog.rubyonrails.org/2008/8/16/josh-peek-officially-joins-...
"Finally! No more worriing because some requests sleep and thus block a whole mongrel."

This person's comment is not true: running multiple Mongrel (Rails) processes doesn't block the other processes. But my point still stands: people don't understand what processes and threads really are, and *perceive* threads as superior regardless of whether they actually are.

Edited 2008-09-09 21:28 UTC

Reply Parent Score: 2