Slashdot Mirror
Why Mozilla Is Committed To Using Gecko
Ars Technica has published an article about Mozilla's commitment to use the Gecko rendering engine instead of using Webkit, which was adopted by Apple and Google for use in the Safari and Chrome browsers. I have been using Chrome on my work PC and find many of its features compelling, and wonder how soon we will see its best innovations in Firefox. Why is Gecko worth keeping if it is outdated and bloated?
Why is Gecko worth keeping if it is outdated and bloated?
Because it's bloated as a single app, but less bloated then opening up a new process (or more than one!) for every single web page loaded. Until every computer in use has multi-gigabyte memory, including handheld devices, there will be a need for something lighter than webkit
Variety is the spice of life. If every browser used the same engine, there'd be no competitive spirit to improve it. Besides, when was a monoculture ever a good thing?
I've been using Konqueror for my primary browser for several years now, but still respect the Mozilla group and wish them the best of luck. As long as everyone follows the standards (which the Open Source browser folks have excelled at), the more the merrier!
Dewey, what part of this looks like authorities should be involved?
This article ignores the real question: Why change? I personally see nothing 'outdated' or 'bloated' about Gecko, and there is no point in changing if Webkit provides no real advantage.
Why is Gecko worth keeping if it is outdated and bloated?
You've begged the question, there. The fact is that Gecko isn't outdated and bloated. Mozilla has kept the code up-to-date. They've improved rendering and javascript performance remarkably in recent Firefox releases.
Personally, I'd rather see alternatives being independently developed and improved; all the while competing with each other for mindshare and technical superiority. The alternative, of relying on a single rendering engine for all browsers, is a bad idea. History has taught us it will lead to stagnation and quirky (rather than standards-compliant) rendering.
While it is certainly true that the mozilla codebase has a rather sordid past, its trajectory has been extremely encouraging(particularly given that it essentially includes its own cross platform widget set, used by mozilla apps and a few others). Javascript performance is competitive with the best, memory performance has steadily improved, and rendering support is quite credible.
I can understand why a third party, starting a project from scratch, might be disinclined to use Gecko; but Gecko seems to be very much on the worthwhile side of the "improve vs. scrap" question.
First of all, WebKit itself doesn't impose the multi-process model that Google's Chrome uses. For example, Safari uses WebKit, and it runs as a single process.
With that cleared up, now, here's the more important flawed assumption in your post: that having the broswer use n processes to display n pages will require n times as much memory as doing it all with n threads in one process. That's far from true, because such a browser can be architected so that the processes use shared memory for all shared resources and state.
The multi-process architecture will carry additional memory overhead, but done correctly, it will scale up much better than linearly. The real costs are the costs of process creation and switching in the OS, plus the costs of the inter-process communication method. Using shared memory for the latter is cheap, but it can potentially make one process bring down the others, defeating the purpose of isolating each page into a process; it's a balancing act, and the memory overhead really depends on what tradeoffs one picks here.
Are you adequate?
Actually, I take that back. The only real overhead is the OS overhead for separate processes.
The architectural choice of what memory contents should be shared between processes and which should be private aren't specific to the multi-process architecture. The same choices and tradeoffs exist in a multi-threaded application; you can choose between having each thread have its own copy of some piece of memory (uses more memory, but isolates each thread from the others), or have all the threads share it (uses less memory, but access must be synchronized, and any bugs involving that shared memory may make one thread bring others down).
Are you adequate?
That's why they will never consider WebKit. Too much pride.
Not because the enormous investment in XUL - including the wealth of third party themes / extensions / etc?
Webkit & Gecko have different goals & strengths. It would be impractical for firefox to switch. This a pragmatic decision & nothing to do with pride.
There are shills on slashdot. Apparently, I'm one of them.
IE has had the same rendering engine, Trident, since IE4 (1997). MS may claim significant improvements in standards support, but in reality, they seem to only pick the bugs that have names. After five publicly available iterations (up to IE7), why is their overall standards support at least 25% below, on a feature by feature basis, nearly every other rendering engine?
Plus, I have yet to hear anything to rebut the rumors that MS simply can't fix Trident because the code is such a mess, and they "don't want to break websites", which is one of the most backwards arguments for anything on any topic.
Gecko is what they developed.
This is like having an article on Redhat's commitment to the Linux kernel.
As if they could just arbitrary change their flagship product to use the BSD kernel instead.
Or like discussing Microsoft's commitment to the Windows platform.
Just because unix/Linux-based kernels and software are becoming more popular in some circles does not mean that it is conceivable for M$ to drop the Windows kernel in favor of a *IX one.
If Gecko in Mozilla dies it will be because they have developed a better Gecko, or because Mozilla as a whole has died.
1. Threads are Hard
2. Threads are not magic bullets
3. Threads introduce WHOLE NEW CLASSES of bugs
Threading is only as hard as a bad design makes them. If you have to share data among threads so much that you have to put locks all over the place, that's really a tell-tale sign that the design isn't all that good to begin with. Really, the best threaded designs are almost like lightweight processes to begin with. Keep the number of points where data must be shared across execution chains low, and everything tends to fall into place.
This is my sig.
"Actually, that is far and away the best reason to not mess with it. The user experience is paramount, and when you mess with that, you have failed."
Here is news for you: Every use of a browser has two users - one providing the content, one recieving it. MSIE has constantly failed the first half until IE8.
Chrome is all new and bright and shiny, Firefox has some (plenty?) memory leaks, and all of a sudden we go from comparing browsers to making sweeping statements over their respective rendering engines? Why?
How is a rendering engine that scores 85% on ACID3 "outdated"? Why should Mozilla drop a codebase that is quite successful in the marketplace, and that they know intimately and have full control over in favour of one they don't know all that well and is controlled by Apple, just because it's (arguably) king of the hill right now?
Frankly, the summary is a troll -- and the article feels like little more than a jab at free clicks.