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.
Sorry, chrome is cute, but until someone implements adblock and flashblock plugins for it, it stays idle.
The Mozilla crew are still pissed at David Hyatt for choosing Konqueror over Gecko as "the best open source rendering engine available" when he defected from Mozilla to Apple.
That's why they will never consider WebKit. Too much pride.
cat
He's going from talking about rendering engine (webkit/gecko) to talking about how great the features are in Chrome (not the rendering engine, the browser). Then back to rendering engine (gecko). What exactly is your topic?
Just a hunch, but the writer doesnt sound intelligent enough to know the features of a rendering engine.
Recently, I'm seeing some indirect evidence of memory corruption in FF. After a while it fails to download images or connect to the network, for example. You restart the process and it all works like buttah again. Heck, Internet Explorer is more stable than this.
I guess fixing hard to repro bugs is far less glorious a job than bolting on a new JS interpreter (even though the old one was OK to begin with) or tweaking the UI.
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?
Google has Android. Apple isn't putting Chrome on the iPhone. End of discussion.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
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.
for getting the kinks ironed out before they hit the rest of us!
I think HTML need to compete with other formats, especially un-structural markups.
It is time to explore a un-structural markups, hopefully a standarized process will start soon. Structural markups is very expensive and incomplete. There are many cases which can not handle well, for example, it never handle footnotes nicely.
Excuse me, but -- what? Do you even understand what the term "structured" means?
Also, just because HTML doesn't have a convenient method for handling footnotes doesn't mean that it's a failure of structured markups in general. For example, see LaTeX.
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.
Haven't done much multi-threaded programming, have you?
Say, one thread locks a mutex and hangs.
Whoops! Now all the other threads that want that mutex will wait forever!
I kind of agree with you, but...
The whole point was that generally, these separate tabs will have very little need to interact. Your example of a global mutex brings up the question, of why you would have them all after a global mutex anyway instead of pretty much keeping to themselves.
Obviously something like a memory error or a few other things can bring the whole thing down by bringing down the main process all the threads are a part of. But contention as you raise the issue seems to be less likely than it would be in other kinds of multi-threaded apps where the threads have to communicate or otherwise work in unison with other threads, or at least more manageable and confined to already centralized things like browser settings.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
"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.
Could someone name some of these innovations?
One process per tab? IE8 did that before Chrome.
V8? Both Apple and Mozilla did those things before Chrome was announced.
Showing your favourite sites when opening a new tab? That's Opera's Speed Dial, except automatic and potentially constantly shuffling around, working against muscle memory.
Creating "standalone" applications from web pages? Mozilla and Apple were already doing that.
Incognito mode? IE8 again.
So what are these innovations?
Chrome's innovations are mostly in the JavaScript engine and the process-per-tab architecture, neither of which have much to do with the rendering engine: Gecko v. WebKit is mostly a peripheral issue.