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 use Gecko?

[suck_burners_rice (1258684)]

Because it has a cooler name than the boring sounding WebKit. Besides, it'll save you 15% on car insurance.

Re:Why use Gecko?

[smitty_one_each (243267)]

Thought it was so easy, even a caveman could code it.

Re:Why use GEICO (advertisement)

[Eccles (932)]

I never heard of Amica until a friend got rear ended by one of their customers.

Well that's a novel marketing approach...

Seriously, though, perhaps they save money by not blanketing the airwaves with commercials.

lite

[TheSHAD0W (258774)]

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

Re:lite

[Just Some Guy (3352)]

You're confusing Firefox-the-browser with Gecko-the-renderer. There's no reason Firefox couldn't have one process per tab, and most Webkit/KHTML implementations currently use one process per browser window (like Firefox).

In short, pick something else to distinguish them. You're way off this time around.

Re:lite

[naasking (94116)]

and most Webkit/KHTML implementations currently use one process per browser window (like Firefox).

Firefox does not use one process per browser window. Firefox uses one process per user profile.

Re:lite

[by Anonymous Coward]

Webkit doesn't specify that you have to use a separate process for each page. That's a Google Chrome feature.

Um, are you sure of that?

[Estanislao Martínez (203477)]

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

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.

Amendment

[Estanislao Martínez (203477)]

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.

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).

Re:lite

[kestasjk (933987)]

Isn't Chrome the only browser out there which does this? And doesn't it actually just do it with separate processes and not individual threads?

Maybe I'm missing something, but it doesn't seem incredibly shameful to me.

Re:lite

[et764 (837202)]

IE 8 actually a process-per-tab (almost) model, like Chrome does. The logic of how to split tabs and stuff into different processes is different, but the general idea is the same. One thing Chrome does that IE doesn't, as far as I know, is that Chrome runs plugins like Flash in a separate process, while IE still keeps them in the tab's process.

The threads vs process distinction is very important, actually. Processes each get their own address space, while threads share an address space. This means processes can't write to each other's memory (except through things like shared memory segments), whereas threads can trample all over the other threads. A thread per tab model does protect you from a rogue Javascript freezing the browser's UI, but it doesn't protect you from a poorly written plugin that does something stupid like dereference a NULL pointer. If you really want reliability, you want processes instead. The downside is that processes are a lot heavier than threads.

Re:lite

[chromatic (9471)]

... unless there's thread contention, or memory corruption, or a deadlock, or they use a non-thread-safe library with a global lock, or one thread has to handle a signal, or there's a segfault, or....

Re:lite

[multipart/mixed (163409)]

> How is that hard to see? It's not exactly a great insight.

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!

How's THAT for great insight?

Repeat after me:
1. Threads are Hard
2. Threads are not magic bullets
3. Threads introduce WHOLE NEW CLASSES of bugs

Re:lite

[bigstrat2003 (1058574)]

I never said it was trivial to implement, just necessary. One doesn't imply the other.

Re:lite

[StrategicIrony (1183007)]

Given infinite resources to code and debug applications, that may be the case.

On the other hand, given realistic design specifications, given the current level of compilers and code verification, the advantage to spawning new threads all the time for processes that aren't super I/O intensive is quite often far overshadowed by the complexity introduced by doing that.

Obviously, it's a design decision, but threaded tabs simply put more onus on the developers to sit around troubleshooting race conditions and inter-thread communications, rather than actually focusing on user-oriented features and performance enhancements.

6 in one, half dozen in the other.

But you don't do yourself any service by dogmatically insisting on it, like it's a magic bullet.

You sig is funny btw

But I want to eat cookies all the time! I want to do it!!.

Yes... and threads too. :-)

Re:lite

[aldousd666 (640240)]

In Chrome, they're not threads. They're processes. It's like launching each as a separate app. There won't be any locks, deadlocks, contention, etc, any more than there is for your copy of Firefox and IE running at the same time. And when you kill one process, all it's memory space goes back onto the free pile, and wont' become fragmented.

Re:lite

[jhol13 (1087781)]

There won't be any locks

The difference of threads v.s. processes has nothing to do whether there are locks or not.

If you have a shared resource you must use locks - no matter if you use processes or threads.

I do not know about Chrome but I'd imagine it does not use shared resources (separate windows, sockets, etc.) which may or may not be a good thing (share cookies of several tabs?). Or maybe it locks only for a (provably) short time ("getGlobalCookie")?

Design matters

[tjstork (137384)]

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.

Re:lite

[sir fer (1232128)]

3. Threads introduce WHOLE NEW CLASSES of bugs

ah, so that's why MS is so keen on adopting multi-threaded programs.

1.Introduce new buggy software

2.Offer paid support for said software

3.Eventually fix old bugs but introduce new ones

4.Profit

Re:lite

[by Anonymous Coward]

slashdot would suck without multiple threads.

Re:lite

[jorgevillalobos (1044924)]

There is no excuse for a modern browser to not have this, especially in light of the fact that their main competitor (IE) is developing it.

Here's one excuse: complications when trying to have multiple processes render content on a single window in Mac OS X [mozilla.com] (mentioned near the end of the tab process isolation section).

It's not clear to me if this is impossible or really difficult to achieve, but I think it'll be interesting to see what Chrome does for Mac OS X.

Re:lite

[im_thatoneguy (819432)]

Why? Is it really that big of a deal? Don't open a tab that's going to lock up your browser.

Oh that's why all those links were labeled "will crash your browser if clicked"! It makes so much more sense now. I kept expecting my browser to fail gracefully and continue operating and didn't realize I just wasn't supposed to click all those links listed as such.

In other news I would like everybody to stop running executables which crash. The OS shouldn't need to keep them isolated since you shouldn't be running applications which crash in the first place. /sarcasm

You must be a gymnast because you really had to bend over backwards pretty far to justify yourself.

Re:lite

[Sentry21 (8183)]

"Lack of threaded tabs is shameful" - Why? Is it really that big of a deal? Don't open a tab that's going to lock up your browser.

Other good advice: don't get on a plane that's going to crash. Don't get on a boat that's going to sink. Don't work for a company that's going to go bankrupt.

"IE developing it" - Oh noes! We need this now, if IE has it then FF needs it! Guess we should go ahead and make FF IE5 complient then, since IE is as well. Forget that standards nonsense, IE has it so we need it.

When Internet Explorer, of all things, has new, useful, and (dare I say) innovative features that make people's lives easier and more productive, far ahead of Firefox, then either it's time for FF to stop resting on its laurels, or it's time to start giving the IE team some well-deserved kudos. Either way, attention must be paid.

If you're encountering enough lock-ups to cause you to need to be able to end a single tab's process regularly (which is pretty hard to do in Chrome with all the tabs having the same process name mind you) then have fun with your threaded tabs. Me, I'm just not going to open sites that are likely to lock up my browser. There aren't many out there, I haven't seen a single one in a couple of months.

Good thing Chrome itself includes a process manager that will let you end a specific process based on what the name of the tab is, how much memory it's using, how much bandwidth it's using, and so on. Pretty keen.

Your post reads like so much 'LA LA LA I CAN'T HEAR YOU!' that I'm forced to wonder why your emotional attachment to Firefox is so deep. Seriously, it's just a browser, lighten up.

Re:lite

[lysergic.acid (845423)]

that's not an argument for having a memory-hogging web browser.

yes, CPU clock speeds are going up, and memory prices are going down, but a web browser should still be a relatively lightweight application by itself.

there are much better uses for the increase in standard memory size in desktop computers. with computers as advanced as they are today, i should be able to have a web browser running in the background while i'm working in Photoshop, Illustrator, or other memory-intensive applications. even if you're not multi-tasking, the extra memory should go towards opening more tabs, running java applets, rendering flash applications, or streaming media.

there seems to be a negative trend of basic office applications becoming increasingly resource-intensive at a pace that negates simultaneous increases in computer processing power. that's not technological progress, that's just inefficient software development.

there's no reason that an office secretary should require a dual-core CPU and 2 GB of RAM when all she really needs to use her computer for is checking e-mail, word processing, web browsing, and possibly edit spreadsheets or run slide show presentations like PowerPoint.

i mean, what good is increased CPU efficiency and cheaper memory when all of that is offset by increased hardware requirements for basic software applications? with the current energy-crisis, we ought to consider whether or not the average person should need to keep pace with Moore's law for simple computing tasks like web surfing or word processing. given the huge strides made in CPU efficiency, a modern web browser should be lean enough in its most basic configuration to be capable of running on a modern low-power PC.

it doesn't make sense to constantly upgrade one's computer just so all applications run just as slow as they did before.

Re:lite

[Moridineas (213502)]

yes, CPU clock speeds are going up, and memory prices are going down, but a web browser should still be a relatively lightweight application by itself.

Why? I spend more time in the web browser--by far--than any other application. Email? 10 years ago I used a standalone email app, now I mostly use webmail. 5 years ago I used AIM. Now I use web chat. Picasa? Google documents? Between javascript advances, DOM, rich media, plugins, TABS, etc etc etc, today's browser does things not even imaged in 10 years ago.

Chrome's very purpose is to make the browser a more generalized application development platform. Heck, WEBKIT is used in the same way (and XUL, etc for Firefox). The web browser ain't just for HTML circa '97 anymore. The web browser is probably the single most important application for most users.

there seems to be a negative trend of basic office applications becoming increasingly resource-intensive at a pace that negates simultaneous increases in computer processing power. that's not technological progress, that's just inefficient software development.

Exactly right. MS Office is a great example of this. The average user utilizes a very small percent of the functionality of Office, and yet everyone suffers the bloat. Can you honestly say that most people don't get anything out of a more rich browsing experience?

Heterogeny

[Just Some Guy (3352)]

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!

Re:Heterogeny

[mollymoo (202721)]

You do know the standards allow you to render things in slightly different ways, don't you? It's one of the principles behind HTML. If you need pixel-perfect rendering, the web isn't the right medium. It's not designed for that.

Re:Heterogeny

[mollymoo (202721)]

Why do we need it now? Because many so many designers are control freaks stuck in the days of print and can't adjust their mindset? Resolution independence is coming to every major OS in the next few years. The web is viewable on everything from mobile phones to conference projection screens. Pixel-perfect rendering for a medium designed to reach those devices and everything in between is an utterly, utterly stupid idea.

Re:Heterogeny

[mollymoo (202721)]

Your post is a perfect example of why designers constantly need to be kept in check. Looking really good is an admirable aim but is not an "excellent reason" to harm functionality. A designer's role is secondary to function. Making something which just looks good is an artist's job, not a designer's job. Designers have to make things which look good and work well. Failing at either one is a total failure. Many designers are frustrated artists and would love to be able to just make something pretty, which would be so much easier if the damn thing didn't have to work too.

Car designers hate having to have boots (trunks) which can hold a set of golf clubs, because it means cars have to have high, fat arses. They hate having to cater for tall people in the back seats because it ruins the roof line. They hate laws about how high your bumpers (fenders) need to be, the fact that an airbag makes the steering wheel fat and the need for fat pillars so the occupants don't get crushed to death in a rollover. The car industry is more mature than the web design industry and there's a lot more money at stake, so the wannabe-artists get weeded out, re-educated or (only they're phenomenally talented artists) set to work on concepts which don't really need to work properly. We need to get rid of the wannabe-artists from the world of web design too.

Sorry if designing for the web is a hard job, but the notion that the web should get harder for everyone to use so it's easier for a few wannabe-artists to design for is only appealing to wannabe-artists.

Re:Heterogeny

[fabs64 (657132)]

If your website renders exactly the same on my 2.5" mobile phone screen as on my 22" widescreen desktop monitor we have a serious problem.

Re:Heterogeny

[tomhudson (43916)]

Yeah, except requiring things to be rendered the same way all the time isn't "harming functionality", it's common sense. In fact, where exactly does one get off saying that you have a "standard" if there's any room for interpretation at all?

It's not common sense. The HTML standard doesn't say, for example, how form controls are supposed to be rendered visually - that's the job for either the browser or the underlying platform.

Ditto with fonts. A 12pt font can be one size on your device/platform, and different on someone else's.

Ditto with web pages themselves - the visual rendering is specified IN THE STANDARDS as being implementation-dependent. For example, a screen reader is free to render web pages as audio instead of glyphs and images.

Read the standards. They're posted at w3c.

Then learn proper design. A good workman doesn't complain about his or her tools.

Re:Heterogeny

[mollymoo (202721)]

You've got it backwards. The "large fonts" option solves problems. Specifically, it solves some of the problems faced by visually impaired users and users with high-resolution displays. These are real problems faced by real people who pay real money for software. The problems lie not with the "large fonts" option or HTML's flexible layout, but with the varying needs of users. Catering for these varying needs does cause problems, but don't blame the problems on the tools provided to solve them.

Re:Heterogeny

[ceoyoyo (59147)]

Actually, I think a design that hangs off the edge of my browser window because I've got the window set narrower than 800 pixels is pretty ugly. I also think text too small to read is ugly, and gets really ugly when I force it to increase size.

Yet a web page (even Slashdot does it) that lays itself out to fit MY choices is beautiful.

The standards allow a little bit of wiggle room, but the user being in control of the "page" you're drawing on and to a certain extent the printer as well, adds a LOT more variation. If you take the control freak approach you will have ugliness. Possibly with the exception of people who use Windows and are used to their browser expanding to fill the whole screen.

Re:Heterogeny

[Just Some Guy (3352)]

As a current web developer, I develop with KHTML. When I like it, I verify that it looks the same under Gecko (and it always does). If it's a major change, I'll check it under MSIE and screw around with the CSS until IE manages to display it without barfing. I don't bother testing with Opera anymore because I've never once seen it fail on a valid page that renders under KHTML - it's just kind of assumed that it will work.

So with all the HTML engines out there, you only have to test two camps: MSIE and everything else. Adding another standards-compliant engine wouldn't increase my workload one iota.

first appropriate use!

[d34thm0nk3y (653414)]

Holy begging the question Batman!

Yes, I did check Wikipedia to make sure a million angry slashdotters weren't going to kill me for its usage.

Because...

[not already in use (972294)]

It's required for the XUL based interface?

Woah...

[JustinOpinion (1246824)]

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.

Re:Woah...

[by Anonymous Coward]

You've begged the question, there

GOD DAMNIT! No, Begging the question is a logi... wait, you used it RIGHT?

*reads it again*

Okay... WHO ARE YOU AND WHAT HAVE YOU DONE WITH SLASHDOT!?

Re:Woah...

[Kesch (943326)]

You must be old here.

Re:Woah...

[QuantumG (50515)]

Ya know what I'd like to see? Standards revision. It's great to tote out "standards compliance" as the holy grail, but the problem is that there are plenty of things that the standard just does not define.. and those things get discovered by web developers who work around the issues and it never gets back to the standards drafters. For example, how do you prefetch images? For a long time there was no standard way. Now there's the link tag but it's optional.. yeah, that's right, the standard says that a browser can optionally implement the tag.. what kind of standard is that anyway? So no-one used it. Instead, they use the img tag and set the width and height of the image to 0.. unfortunately, the standard never said "if the width of the image is zero, thou shalt not render anything." Yeah, yeah, I know, should be implied, by some browsers render a white pixel and figure that's good enough.. the fact that this isn't good enough should be fed back to the standard and made explicit.

Thankfully the interest in Acid tests has taken on this role. Unfortunately even a lot of stuff that is in the acid test never makes it back to the standard, so browser developers have to reverse engineer the Acid test!

Re:Woah...

[CastrTroy (595695)]

You're never going to get the same results out of 2 different computers, even if they are using the same rendering engine, or even the exact browser and OS. Monitor DPI can greatly affect the way things are displayed. Font sizes change completely especially when they are specified as points. Some users turn up the minimum font size because they can't see tiny fonts. Some monitors, especially 6 bit LCDs have really poor color rendering, and have problems with colors without much contrast. On my work monitor at work, #E7E7E7 looks exactly the same as white. There's tons of other things that the user can adjust that determine how your HTML+CSS will be displayed. If you think all the users of your site are seeing the same thing, you are quite naive. I think having different browsers is a good thing. Because it means developers at least look at the page until a few different environments. If there was only one browser, they would only check in their own browser, and assume it would look fine for everyone else. Which is definitely not the case.

Re:Woah...

[mixmatch (957776)]

You're insane for comparing WebKit with IE. IE is not open for development, which is why it stagnated.

Gecko, Mozilla and XPCOM

[daceaser (239083)]

The whole of the Mozilla code tree is tied into a framework called XPCOM. It is a Cross-Platform reimplementation of Microsoft's COM. The XPCOM influence is extremely pervasive throughout the whole of the Mozilla/Firefox/Thunderbid/Sunbird/Gecko code trees.

WebKit would not fit in very well with the existing ecosystem because it does not tie into the XPCOM framework which is used to tie all of the Mozilla group's projects together. A lot of the potential performance benefits of moving to WebKit would be lost because of all the bridging between WebKit and XPCOM that would be required.

Wheeeeeee!

[maxume (22995)]

https://wiki.mozilla.org/Gecko:DeCOMtamination [mozilla.org]

Not really a serious question.

[fuzzyfuzzyfungus (1223518)]

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.

Wait wait...

[xouumalperxe (815707)]

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.

Re:The real question is ignored here...

[bigstrat2003 (1058574)]

Did you RTFA, or just TFS? Because I RTFA'd, and the article specifically says that there's no reason for Firefox to switch engines. TFS is full of it, basically, so I could understand if you got the wrong idea from that.

Re:The real question is ignored here...

[PunkOfLinux (870955)]

I think it's more that WebKit is the new buzzword in browser dev. Plus, Apple uses it, so it's *obviously* the holy grail. I think Gecko is fine; if it's the bloat, maybe the competition from WebKit will whip it into shape.

Re:Gecko is not outdated or bloated.

[Dracos (107777)]

IE has had the same rendering engine, Trident [wikipedia.org], 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 [webdevout.net], 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.

Re:Mozilla IS Gecko

[fabs64 (657132)]

You don't seriously think FF3's running on anything remotely similar to Netscape 1.0's rendering engine, do you?