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 329781
To view parent comment, click here.
To read all comments associated with this story, please click here.
FooBarWidget
Member since:
2005-11-11

This Webkit/Chrome zealotism is getting out of hand. Before Chrome, almost everybody would claim that threads are "superior technology" compared to processes (whether they're really "superior" depends on the context) and that processes waste resources. With the coming Chrome, everybody turned 180 degrees and started hyping the process model.

Even after being shown that using processes makes the browser use as much memory as IE8, people would still accept it. If it was Firefox that's using so much memory, people would have screamed death and murder. This just shows that the primary reason people say good things about Chrome, is because it's from Google. If Chrome were developed by anybody else, people would scream "bloat!".

Also consider this:

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.


This is yet more proof that most fanboys have absolutely no idea what they're talking about. Back in the days, people said the same thing about GNOME and KDE: that KDE is far superior, that GNOME or $RANDOM_GNOME_APP should ditch GTK and use Qt instead. It never happened. The acclaimed "far superiority" was apparently not superior enough.

Fanboys totally ignore the economics of rewriting a web browser just to use a different rendering engine/toolkit/etc. It isn't economic to do so. Lots and lots of man hours will be utterly wasted if Mozilla is to embark on such a journey. The fanboys also seem to treat Firefox as mortal enemy #1, while it is still Internet Explorer that's preventing me from writing fully standards compliant websites (I often have to resort to hacks to make things render correctly in IE; not so in every single other browser). Yet the fanboys still continue to say irresponsible things like "Firefox sucks, Chrome rocks, kill Firefox and replace it with Webkit lolololol!!!!111"

Edited 2008-09-09 17:03 UTC

Reply Parent Score: 10

rycamor Member since:
2005-07-18

Heh... totally in agreement. Google/Chrome/Webkit is an interesting project, but I see no reason to treat this whole thing like a political horse race.

Mozilla/Firefox/Gecko is not going anywhere. Yes, there was a time when its future was very shaky (1999 - 2001), but they stuck with it. No project is perfect, and the Mozilla project has it's difficulties for sure, but still, there is an amazing amount of wisdom among the various members of the Mozilla team. In spite of many differences, complications, and a huge technological base to get under control, they pulled it off.

The V8 Javascript engine may have one advantage in process isolation (which as a Unix guy I tend to favor), but from what I see, it is still nowhere close to being cross-platform, and I wonder if it supports any of the new very nice features added to Javascript 1.7 and 1.8, much less how prepared it will be to leap to Javascript 2.0 (ECMA 3.1). There are very good things in store here for the Mozilla world, not only in features but in performance, so it's definitely not "game over" or anything close.

Reply Parent Score: 4

sbergman27 Member since:
2005-07-24

This Webkit/Chrome zealotism is getting out of hand.

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.

Before Chrome, almost everybody would claim that threads are "superior technology" compared to processes

Nice straw man. Certainly I have never said that. And being POSIX-like OS oriented, I'd have to look around for someone who *was* willing to say such a thing. Threads can yield lighter code, and maybe even faster code sometimes. But they don't yield the kind of stability, reliability, accountability, and debugability that a modern application platform needs. Chrome's process model is a godsend and there is nothing "turnabout" in saying that.

Edited 2008-09-09 18:52 UTC

Reply Parent Score: 2

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

stestagg Member since:
2006-06-03

Before Chrome, almost everybody would claim that threads are "superior technology" compared to processes (whether they're really "superior" depends on the context) and that processes waste resources.


Please don't talk about things you don't understand. Using threads [or not] in certain situations can massively impact performance, either for better or worse. In high-concurrency server applications (like ROR, for example) being able to serve requests on a thread rather than a new process can be hugely beneficial because of the unavoidable time that it takes to initialize the Ruby engine, parse the application, and initialize data every time the process starts. The same is true for memory.
If you're serving 100 requests a second, then you need to get RoR starting up in far less than 1/100th of a second or you'll get a bottleneck.

With Chrome, the emphasis is not on raw performance, but on security. The speed costs of using separate processes are not noticeable to the end-user yet the security benefits are. Especially when a plug-in crashes on you.

Reply Parent Score: 4

FooBarWidget Member since:
2005-11-11

Where did you get the impression that I didn't understand it? I said *other* people claim that threads are superior. I said that the perceived superiority of threads is a common view point. I didn't say that that's my stance. In fact, I explicitly mentioned that whether threads or processes are superior depends on the circumstance.

As for RoR, what you claim is simply not true. Take a look at Phusion Passenger and Ruby Enterprise Edition, which use advanced preloading and copy-on-write techniques to ensure that startup time of Rails processes are low. Phusion Passenger can spawn 20 Rails processes in about the same time it takes to spawn 1 process. No joke - you can even verify it for yourself. So please, don't accuse me of not knowing what I'm talking about.

Edited 2008-09-10 15:58 UTC

Reply Parent Score: 2