×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Why Mozilla Is Committed To Using Gecko

Soulskill posted more than 5 years ago | from the gecko,-not-geico dept.

Mozilla 632

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?

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

632 comments

Why use Gecko? (5, Funny)

suck_burners_rice (1258684) | more than 5 years ago | (#24939887)

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

Re:Why use Gecko? (2, Funny)

sexconker (1179573) | more than 5 years ago | (#24939937)

Really? I thought it was so we could render GameCube games. (And Wii games if you have some duct tape and a dual core CPU?)

I am committed to first posting (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#24939899)

Is this a firsty?

You bet your ass butter filled hairy ass crack!

Re:I am committed to first posting (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#24940469)

You lost the bet. Now where's my ass?

hello? (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#24939905)

first!!! LOL

Re:hello? (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#24940373)

nope. LAST! ROFL

lite (5, Insightful)

TheSHAD0W (258774) | more than 5 years ago | (#24939921)

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 (0, Troll)

bigstrat2003 (1058574) | more than 5 years ago | (#24939961)

I don't know about you, but I'll take stable over lightweight any day. The only word that suffices to describe Firefox's lack of threaded tabs is "shameful". 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.

Re:lite (4, Insightful)

kestasjk (933987) | more than 5 years ago | (#24940267)

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 (2, Informative)

bigstrat2003 (1058574) | more than 5 years ago | (#24940313)

IE 8 has threaded tabs. Now, granted, that's in beta, but that means that the biggest browser has picked up this feature. Chrome also has it, albeit with processes instead of threads. Note I'm not picky about the technical details of threads vs processes, I just want the browser to not completely hang (or worse, crash) based on one tab's misbehavior.

Like I said, given that IE 8 is implementing threaded tabs, there's no excuse for Firefox not to have it. It just brings too much to the table in terms of reliability to not have.

Re:lite (2, Insightful)

multipartmixed (163409) | more than 5 years ago | (#24940519)

Really? You think threaded tabs bring stability to the browser. WHAT? How the HELL do you figure that?

Re:lite (1, Informative)

bigstrat2003 (1058574) | more than 5 years ago | (#24940607)

...it's trivial to figure that out. Let me explain it to you: you have tab A, and tab B. If tab A and B share the same thread, they will hang each other if one of them hangs. By putting them in separate threads, tab A and B can hang, but not affect each other.

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

Re:lite (0)

Anonymous Coward | more than 5 years ago | (#24940577)

The thing about it is, threads still depend on one another. If one thread hangs, and another is waiting on it (which happens a lot in concurrency), everything will fail.

Separate processes, each with their own rendering engine is considerably more process intensive, but far more stable.

Re:lite (5, Informative)

jorgevillalobos (1044924) | more than 5 years ago | (#24940435)

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 (4, Informative)

Just Some Guy (3352) | more than 5 years ago | (#24939997)

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 (5, Informative)

Anonymous Coward | more than 5 years ago | (#24940019)

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? (5, Insightful)

Estanislao Martnez (203477) | more than 5 years ago | (#24940185)

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 (5, Insightful)

Estanislao Martnez (203477) | more than 5 years ago | (#24940283)

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 (1, Insightful)

stephanruby (542433) | more than 5 years ago | (#24940431)

Why is Gecko worth keeping if it is outdated and bloated?

Because Gecko is actually less outdated than Webkit. When Webkit can run extensions/plugins without crashing, then may be -- then Webkit could be a serious contender.

Re:lite (1)

Moridineas (213502) | more than 5 years ago | (#24940455)

Opening a new process per rendering window is a property of google chrome NOT webkit. Try Safari if you want to see what Webkits looks like in a more established browser.

Additionally, I don't know about you, but I haven't bought a computer in several years that hasn't had 2gb, and 1gb seems to be the absolute floor. Memory isn't doing any good if it's not being used!

Heterogeny (5, Insightful)

Just Some Guy (3352) | more than 5 years ago | (#24939929)

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 (0)

Ethanol-fueled (1125189) | more than 5 years ago | (#24940057)

From TFS:

Why is Gecko worth keeping if it is outdated and bloated?

Safari uses webkit and it's buggier, slower, and more bloated-feeling in general than Firefox or Chrome(at least on a windows box).

I'm only a layman but I'd suggest that other factors like feature creep and the general design mentality of the team come into play(DUH). Yes, Chrome is fast and it kicks ass but will it stay that way in the long run? Don't forget that Google's offering is the youngest -- Google has had much more to time learn from others' mistakes.

Re:Heterogeny (0, Flamebait)

mrchaotica (681592) | more than 5 years ago | (#24940387)

Safari uses webkit and it's buggier, slower, and more bloated-feeling in general than Firefox or Chrome(at least on a windows box).

I'd wager that's due more to Cocoa than anything else.

Re:Heterogeny (1)

mikael_j (106439) | more than 5 years ago | (#24940419)

Safari uses webkit and it's buggier, slower, and more bloated-feeling in general than Firefox or Chrome(at least on a windows box).

On OS X my experience is that Safari/WebKit is a lot snappier than Firefox although I will admit that I rarely use Firefox for extended periods of time so I can't really tell how well it handles running for days on end with lots of tabs open on OS X, but I know the Windows and Linux versions tend to start using a lot of RAM after a few days.

/Mikael

Re:Heterogeny (1)

ya really (1257084) | more than 5 years ago | (#24940433)

Safari uses webkit and it's buggier, slower, and more bloated-feeling in general than Firefox or Chrome(at least on a windows box).

You do know that chrome uses webkit as well, right?

Re:Heterogeny (1)

mcsqueak (1043736) | more than 5 years ago | (#24940105)

Variety is the spice of life. If every browser used the same engine, there'd be no competitive spirit to improve it.

Yes, and god forbid a web designer only has to design for ONE engine, and not several, each rendering what should be STANDARDS in slightly different ways, ugh. I don't understand why some design groups feel they can throw some of these things out the window when designing their browsers. "Well, we COULD follow the all the standards set for CSS, but hey... lets just follow SOME of them!" Bleh.

Re:Heterogeny (2, Informative)

Darkness404 (1287218) | more than 5 years ago | (#24940199)

Ummm... If you develop for Gecko, webkit and presto based browsers will usually render the page correctly. You usually only need to make more than one version of the page to work with IE.

Re:Heterogeny (5, Insightful)

mollymoo (202721) | more than 5 years ago | (#24940317)

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 (1, Insightful)

bigstrat2003 (1058574) | more than 5 years ago | (#24940369)

You do know the standards allow you to render things in slightly different ways, don't you?

What you say is true, but more or less meaningless. The fact that the standards allow this mean that the standards suck, not that the behavior is ok.

If you need pixel-perfect rendering, the web isn't the right medium. It's not designed for that.

Maybe it wasn't designed for that at the beginning, but it needs that now, and we should adjust how we address it accordingly.

Re:Heterogeny (4, Insightful)

mollymoo (202721) | more than 5 years ago | (#24940497)

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 (2, Interesting)

Alien Being (18488) | more than 5 years ago | (#24940181)

You already said it, so I'll just second the thought. When there's only one way to look at the web, the web is dead.

I use Firefox primarily because of a few plugins I use a lot. Konqueror seems to be a better renderer and its UI blows everything else out of the water.

I keep hearing about something called Internet Explorer, but it seems to be less of a browser than a vector for malware.

Pointy-haired-bosses used to say that the browser wars are over and MS won. They have no idea how wrong they were.

Re:Heterogeny (2, Insightful)

Enderandrew (866215) | more than 5 years ago | (#24940447)

Gecko just had a major two-year-plus makeover, and it still isn't as good as Webkit. One could argue that Webkit of two years ago stacks up reasonably well with Gecko of today.

Mozilla spent so much time on rendering engine refactoring, and they want to focus on stabilizing 3, and then moving to Firefox 4.

Moving to a new rendering engine might seem daunting. I don't see Mozilla approaching the project themselves.

There is a new QT branch of Firefox, but even that isn't a proper QT branch. It uses QT widgets, but QT is integrated with Webkit, provides its own JS implementation, etc. I'd love to see an outside team fully develop a QT/Webkit/Xulrunner fork of Firefox that allows me to use Firefox extensions on top of a Webkit rendering engine.

Re:Heterogeny (0)

Anonymous Coward | more than 5 years ago | (#24940481)

You keep using this word. I do not think it means what you think it means.

The specification is too incomplete to be called a "standard." For that matter, I doubt many of the people here have read or would understand the specification for, e.g., XHTML 1.1 or whatever.

Equating the spec with the idea of a consistent standard is like abortion-debate-politicizers who conflate Roe v. Wade with abortion rights, even though most of them haven't read it and wouldn't understand it if they did.

Anyway, the fact that the specs are written in arcane meta-language is why the Acid tests are important -- they fill a void where something to test browsers against should be. A reference drawing isn't quite as good as a reference implementation, but it's a good start.

Re:Heterogeny (2, Interesting)

localman (111171) | more than 5 years ago | (#24940563)

As a has-been web developer and regular web user, I'm going to suggest that the advantages of having many browsers (or more specifically, rendering engines) is largely overstated.

I don't see that browsers have made any wondrous leaps of progress due to competition. In fact it seems that competition has stymied progress at times, as browsers had to attempt supporting incompatible features that grew out of attempts to one-up the competition. Companies that develop websites have to waste a lot of resources on testing, which would benefit the user more if spent on UI or other types of development. Either that or they _don't_ spend the resources on testing so customers are variously frustrated as no one browser handles all sites correctly.

Flash is an example of something that seemingly progressed well, perhaps faster than browsers, while having essentially no competition.

So yeah, I understand that in some cases competition is a benefit, but not always. I think interoperability needs can sometimes trump the advantages of competition. I'm not sure I believe competition benefitted browsers or the web.

Of course I've been saying for a while that MS should pick up either Gecko or WebKit and not create another rendering platform. But nobody seems to agree with me except for Google :)

Cheers

first appropriate use! (3, Interesting)

d34thm0nk3y (653414) | more than 5 years ago | (#24939931)

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.

Re:first appropriate use! (0)

Anonymous Coward | more than 5 years ago | (#24939963)

Holy begging the question Batman!

I'm Batman.

You Insensitive Clod.

The real question is ignored here... (3, Insightful)

creature124 (1148937) | more than 5 years ago | (#24939935)

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.

Re:The real question is ignored here... (0, Flamebait)

p0 (740290) | more than 5 years ago | (#24939967)

Exactly. Once they rewrite Gecko with cool new features, Webkit will be 'outdated' and 'bloated'.

Re:The real question is ignored here... (4, Insightful)

bigstrat2003 (1058574) | more than 5 years ago | (#24939983)

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... (4, Interesting)

PunkOfLinux (870955) | more than 5 years ago | (#24940027)

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:The real question is ignored here... (1)

Enderandrew (866215) | more than 5 years ago | (#24940485)

Anyone who has looked at Webkit seems to fall in love with it. QT ships with it. KDE now includes a Webkit-part despite the bad Webkit/KHTML-feelings, Android uses it, Arora uses, Safari uses it, and Chrome uses it.

The amazing thing is that I keep hearing how huge browsers must be, and how complex browser code must be. Then arora comes along, and Chrome, and the basic QT-web-browser. I see these mini-browers based on Webkit that are amazingly light-weight and feature rich at the same time.

It is hard to just "trim bloat" when you're talking legacy code from 10+ years in an app that has changed so drastically in both form and function.

Re:The real question is ignored here... (1)

techno-vampire (666512) | more than 5 years ago | (#24940343)

There are some people who thing that change is always good, and that the latest must be the greatest. They're the people who are always using the latest beta version of everything simply because it's new. Then, when the new version is out, they adopt it on the first day so that they can brag that they have the newest version. Yes, they suffer through the teething problems any new version has to go through, but they don't care, as long as it's new.

Woah... (5, Insightful)

JustinOpinion (1246824) | more than 5 years ago | (#24939953)

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... (5, Funny)

Anonymous Coward | more than 5 years ago | (#24940103)

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... (4, Interesting)

QuantumG (50515) | more than 5 years ago | (#24940119)

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

QuoteMstr (55051) | more than 5 years ago | (#24940189)

What's wrong with visibility: hidden? Or using position: absolute to keep unused images out of the client area (and without affecting layout)?

Re:Woah... (1)

QuantumG (50515) | more than 5 years ago | (#24940275)

Yes, that's a suitable workaround.. but you should be able to assume that the browser will do what you tell it.

Re:Woah... (1)

QuoteMstr (55051) | more than 5 years ago | (#24940381)

there are plenty of things that the standard just does not define

The standard defines a mechanism to do what you want. The standard can't define everything. That's the case in any complex system. Consider C: i = ++i + ++i results in undefined behavior.

This is a "It hurts when I do this! Well, then don't do that!" situation.

Welcome to "Standards" (2, Interesting)

statemachine (840641) | more than 5 years ago | (#24940401)

Please do not take this negatively:

Ya know what I'd like to see? Standards revision.

And yet, they do revise them by working on and ratifying a new version.

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.

That sounds nice, but you're advocating a moving target. Standards or recommendations would never be finished.

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

Just because *you* want it, doesn't mean others do.

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!

I'm guessing you're a web developer. Therefore, you or your company have a demonstrated interest in the recommendations, which means you can sign up and be a member of the committees and advocate your changes and proposals for the next version of the recommendation.

I hope this helps a bit to further your understanding of the process.

Re:Woah... (0)

coolgeek (140561) | more than 5 years ago | (#24940125)

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.

Obviously, you don't write much HTML. Web authors would prefer a monolithic rendering system, rather than the hodgepodge of nearly-standards-compliance we have now. Face it, you're never going to get the same results out of multiple rendering engines, without resorting to the black art of navigating bugs in different browsers.

WebKit has shown it's chops in fast rendering, small size, portability, etc. Everyone should just adopt it. Let it be the standard. Let the specs evolve and implement the new specs in WebKit, then relink your code, and voila, every browser now has the updated standard.

Re:Woah... (2, Insightful)

McDutchie (151611) | more than 5 years ago | (#24940219)

WebKit has shown it's chops in fast rendering, small size, portability, etc. Everyone should just adopt it. Let it be the standard.

Remember when IE was the de facto standard? Remember how it stagnated and we were stuck with IE6 brokenness for years until Firefox came along and kicked their ass in gear? That's why we need competition. Having one single dominating platform will result in stagnation.

Re:Woah... (4, Insightful)

mixmatch (957776) | more than 5 years ago | (#24940357)

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

Re:Woah... (1)

ya really (1257084) | more than 5 years ago | (#24940453)

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

Rather silly to compare rendering engines (webkit) to browsers (IE) to begin with. Sort of like comparing apples to oranges

Re:Woah... (1)

mikael_j (106439) | more than 5 years ago | (#24940395)

I partially agree with you, there needs to be more than one rendering engine for (X)HTML out there. But WebKit would probably be good as the "reference" engine, unlike IE development isn't controlled entirely by a single company that's more concerned about squashing competition at all costs.

Also, a big problem with IE when it became the "standard" was that both MS and Netscape had been pretty much making up their own standards for a long time, remember all those "this site viewed best with Internet Explorer/Netscape Navigator" warnings?

I think WebKit should be coded to conform as closely to the W3C standards as possible and perhaps even be treated as a "semi-official" reference rendering engine.

/Mikael

Re:Woah... (3, Insightful)

CastrTroy (595695) | more than 5 years ago | (#24940423)

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

Anonymous Coward | more than 5 years ago | (#24940191)

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.

you know, opera and webkit actually started pretty good and didn't have to go through tons of work to get to something that's almost OK.

Re:Woah... (1)

JTek (5392) | more than 5 years ago | (#24940323)

That is the first time I've EVER seen "begged the question" used properly on Slashdot. You get a gold star for the day!

Re:Woah... (1)

zobier (585066) | more than 5 years ago | (#24940451)

I can't quite put my finger on it but Gecko renderings feel better to me than the competition. Maybe that's just because of familiarity.

Anyway competition is good, If everyone adopted WebKit we would end up back where we were with the IE monoculture before.

Also, I don't get what the obsession other web developers have with "consistent" results. It's the web, documents aren't meant to be pixel identical in different user agents, that's kind of the whole idea: I should be able to access the same information from a vt100, a PC with a high-res monitor, a screen reader or my phone. Obviously the experience is going to be different depending on which device I use.

I really wish more developers would learn about the concept of progressive enhancement. I know it's often due to ignorant marketeers and designers, however better than being shiny on one browser+platform is if it "works anyhow".

Anyone feel like starting a "works anyhow" button campaign?

Re:Woah... (1)

Trojan35 (910785) | more than 5 years ago | (#24940507)

"History has taught us it will lead to stagnation and quirky (rather than standards-compliant) rendering."

While I agree with your overall point, I need to nitpick. Standards-compliance isn't important if everyone uses the same browser. The browser IS the standard.

Re:Woah... (1)

QuoteMstr (55051) | more than 5 years ago | (#24940529)

The browser IS the standard.

And that makes it impossible to develop new browsers, leading to stagnation.

I'll tell you why...http://tech.slashdot.org/login (1, Interesting)

Anonymous Coward | more than 5 years ago | (#24939957)

"Why is Gecko worth keeping if it is outdated and bloated?"

may be the same as saying...

"Commitment... instead of using Windows.... Why is UNIX worth keeping if it is outdated and bloated?"

Maybe it isn't outdated and bloated... we are not talking about the netscape code here.

Gecko, Mozilla and XPCOM (5, Interesting)

daceaser (239083) | more than 5 years ago | (#24939969)

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.

Gecko is not outdated or bloated. (-1, Troll)

actionbastard (1206160) | more than 5 years ago | (#24940015)

This is. [microsoft.com].

Re:Gecko is not outdated or bloated. (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#24940195)

duh. duh. i'm a dumb open source fag who's too afraid to look at my own shit and have to endlessly point the finger elsewhere. i can't accept open source being scrutinized because it would reveal that open source has the same problems as closed source. duh duh.

fucking bitch. open source sucks a hard cock. go jam it up your ass.

Re:Gecko is not outdated or bloated. (1)

bigstrat2003 (1058574) | more than 5 years ago | (#24940213)

IE 8 is not outdated by any stretch of the imagination. I'd give you bloated, except you said that Gecko isn't bloated, and IE isn't what we'd call that far off from Firefox in terms of bloat. They're both weighty browsers, it's not like comparing a midget to a cow.

Re:Gecko is not outdated or bloated. (1)

Enderandrew (866215) | more than 5 years ago | (#24940513)

Firefox 3 on my system uses around 200 megs of memory. IE8 pushes 400 megs. Firefox is snappy. IE8 makes IE7 look snappy in comparison.

Re:Gecko is not outdated or bloated. (1)

actionbastard (1206160) | more than 5 years ago | (#24940531)

"...it's not like comparing a midget to a cow."
How about a midget cow?
Sorry. I should have added the sarcasm notifier (~) after the end of the sentence in the original post. My bad.

Re:Gecko is not outdated or bloated. (0, Troll)

FishWithAHammer (957772) | more than 5 years ago | (#24940601)

And with threaded tabs, it kicks Firefox's ass up and down the street.

At the moment, Firefox and Safari are competing for "suckiest browser." Chrome and IE8 are hanging out at the cool kids' table.

No chrome until adblock and flashblock (2, Insightful)

Anonymous Coward | more than 5 years ago | (#24940033)

Sorry, chrome is cute, but until someone implements adblock and flashblock plugins for it, it stays idle.

Re:No chrome until adblock and flashblock (1)

bigstrat2003 (1058574) | more than 5 years ago | (#24940233)

So port them? I doubt it'd be super hard for a motivated user to port them, unlike developing them from scratch. If you pin your use of Chrome to "until someone implements"... you could be potentially denying yourself use of a far superior browser based on the whims of others, which isn't ideal.

Re:No chrome until adblock and flashblock (2, Informative)

stephanruby (542433) | more than 5 years ago | (#24940499)

So port them? I doubt it'd be super hard for a motivated user to port them...

You're wrong. Some plugins and extensions have been ported to Webkit, but the thing keeps on crashing. I'm sure this will change, but Webkit is just not a stable platform to extend right now.

Re:No chrome until adblock and flashblock (1)

Enderandrew (866215) | more than 5 years ago | (#24940527)

I heard a rumor that Google will implement their own version of ad block, which won't fully stop the ads from loading, but rather will hide them in the rendering process. Advertisers still see an ad generate, and users don't see the ad.

It's NIH (2, Insightful)

coolgeek (140561) | more than 5 years ago | (#24940039)

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.

Re:It's NIH (1)

Darkness404 (1287218) | more than 5 years ago | (#24940327)

Or... You know the fact that a lot of AJAX apps will force you to either spoof the browser or use Firefox to access them. Heck, I had to spoof the Firefox 3.1 Alpha's browser ID because some AJAX apps wouldn't work with "Shiretoko" (even though once spoofed they worked fine)

Re:It's NIH (1)

adpowers (153922) | more than 5 years ago | (#24940553)

Funny, I haven't had issues accessing any AJAXy websites from Safari in years. Google Maps and Docs didn't support Safari when they first launched, but they do now. I can't think of any webapps that don't work in Safari these days.

Re:It's NIH (3, Insightful)

Whiney Mac Fanboy (963289) | more than 5 years ago | (#24940603)

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.

What is the writer talking about? (2, Insightful)

ya really (1257084) | more than 5 years ago | (#24940063)

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.

Re:What is the writer talking about? (1)

interiot (50685) | more than 5 years ago | (#24940201)

Chrome wasn't the only browser mentioned; the piece also mentions KHTML, Safari, iCab, Omniweb, Shiira, and Epiphany. The point is to demonstrate just how popular WebKit is, not to focus on any one browser.

Makes me wonder, too (2, Insightful)

melted (227442) | more than 5 years ago | (#24940065)

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.

Re:Makes me wonder, too (0)

Anonymous Coward | more than 5 years ago | (#24940161)

Did it occur to you to check your memory with BadRAM?

Re:Makes me wonder, too (0)

Anonymous Coward | more than 5 years ago | (#24940555)

I saw that just the other day for the first time myself with the latest Firefox 2.x. Now, I use FF all the time and I've not seen that before. However, I knew something was hosed when it wouldn't load new images and when dialogs popped up with empty button labels.

XPCOMGC? (0)

gbjbaanb (229885) | more than 5 years ago | (#24940075)

Why does everyone and his little dog think that replacing with a garbage collector is the way to make better code?

I don't think GC is a bad idea, but as a first and only method of object lifetime management I think its a solution looking for a problem - ie there are better means of making your code more reliable (RAII for example).

In TFA they refer to XPCOM's reference counting as needing replacement. I can't help thinking they'd just be replacing it with something else equally complex (for the entire application, obviously), and the last thing I want from Firefox 4 is increased memory usage!

Not really a serious question. (5, Insightful)

fuzzyfuzzyfungus (1223518) | more than 5 years ago | (#24940095)

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.

Why did Google Choose webkit! (1)

iatarget (1095137) | more than 5 years ago | (#24940171)

What no one has noticed is that Google is after the people that spend money. Right now those people are all after the iPhone. Guess which render engine works on iPhone. Guess which one would allow them to get chrome on the iPhone ASAP.

Web Kit also has the benefit of Apple techs making sure that it runs smooth on the iPhone.

Also notice they released it for the most popular desktop OS as well first.

Running web feature rich apps on the iPhone allowing mobile users to buy on eBay, check mail, look at the map of how to get to fancy restaurant X is what google wants you to be doing. It's fits there business model.

They have some fairly obvious business goals here. They give the user something they want that also fits into how the generate money. It's honest it's straight forward.

Re:Why did Google Choose webkit! (1)

iatarget (1095137) | more than 5 years ago | (#24940295)

I should add. This choice of engine had less to do with technology than it did with time to market for the key platforms. Chrome had to beat ie8 out the door. With ie8 in Alpha-Beta release and the press beating it up it was perfect timing to come out with a browser that one performed way better than ie and two ran on the iPhone.

Re:Why did Google Choose webkit! (0)

Anonymous Coward | more than 5 years ago | (#24940445)

there != their != they're

Re:Why did Google Choose webkit! (2, Insightful)

Enderandrew (866215) | more than 5 years ago | (#24940545)

Google has Android. Apple isn't putting Chrome on the iPhone. End of discussion.

Uh-oh. (0)

Anonymous Coward | more than 5 years ago | (#24940397)

I accidentally the Gecko.

The WHOLE thing!

whilst we fret about money etc... (0)

Anonymous Coward | more than 5 years ago | (#24940437)

The current rate of extinction is around 10 to 100 times the usual background level,[36] and has been elevated above the background level since the Pleistocene. The current extinction rate is more rapid than in any other extinction event in earth history,[37] and 50% of species could be extinct by the end of this century.[38] While the role of humans is unclear in the longer-term extinction pattern, it is clear that factors such as deforestation, habitat destruction, hunting, the introduction of non-native species, pollution and climate change have reduced biodiversity profoundly.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...