Why Mozilla Is Committed To Using Gecko 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?
first appropriate use! (Score:4, Interesting)
Yes, I did check Wikipedia to make sure a million angry slashdotters weren't going to kill me for its usage.
I'll tell you why...http://tech.slashdot.org/login (Score:1, Interesting)
"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 (Score:5, Interesting)
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.
Re:The real question is ignored here... (Score:5, Interesting)
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:Woah... (Score:5, Interesting)
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:Heterogeny (Score:2, Interesting)
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.
Welcome to "Standards" (Score:3, Interesting)
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.
Wheeeeeee! (Score:4, Interesting)
https://wiki.mozilla.org/Gecko:DeCOMtamination [mozilla.org]
Re:Heterogeny (Score:3, Interesting)
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
Re:lite (Score:1, Interesting)
Lol. You have a grossly inflated view of process-specific tabs IMHO.
To take your points one by one,
"Stable over Lightweight" - Firefox 3 has never crashed on me. Not once in the time I've been using it, which has been over a month now. And I use it daily, for at least an hour a day, with flash games being a near daily diversion. Chrome, on the other hand, is far lighter weight (at least ram wise, CPU wise it's too much of a hog for me) but has crashed twice, and I've used it for, perhaps, 3 hours. Ergo, by your logic, FF3 is the better browser for me.
"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.
"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.
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.
Re:Heterogeny (Score:5, Interesting)
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 (Score:2, Interesting)
Ok, time for an education.
Comparing the capabilities of the different rendering engines with the INTENT of the content designer is, to use your words, utterly stupid.
DESIGNERS build pages to look ONE way, not "oh I want it to look like this on Firefox, and this on IE, oh oh and this on Chrome!" That's not how it works. Speak to a designer and you'll see.
So, the fact is, in an ideal world rendering engines will ALL do it right, which is to say the SAME and according to the STANDARDS which if are bad get CHANGED to render properly.
That is how it works and how it should work. The fact that it doesn't IS a problem and needs corrected, and it's improving all the time because developers don't think like you do... that this is some kind of "my way or the highway" kind of thing.
Re:Heterogeny (Score:3, Interesting)
As a web USER, I couldn't disagree with you more.
Fair enough, but be aware I am speaking from my perspective as a user, not from a developer's perspective (I haven't done any web development since I toyed around making web sites back in the IE4/Netscape 4 days). When I go to a site, I want it to look the same on any reasonable combination of browsers and platforms. It's understandable if the mobile phone version isn't the same as the regular version, but the regular version had better damned well look the same whether I'm on a computer that uses Firefox, IE, Safari, Chrome, Konqueror, whatever. Anything less is unacceptable to me, as a user. I highly value consistency.
Re:lite (Score:4, Interesting)
Building anything that is multi-threaded, even if un-intentional can cause issues... in this case, making the Class A's instance inside the method was the solution... in other cases locking is. Just depends.. it's just amazing how many people don't understand, or realize how these issues pop up.
Re:lite (Score:1, Interesting)
Sir, you've hit the nail with thumb intact.
I often wonder how software (particularly office or basic internet applications) can somehow manage to demand the same proportion of computing power today as they did fifteen years ago, almost rendering the increase in computational power worthless for so many "simple" tasks. My current computer is about 850 times faster than one I had in the early '90s (on paper, anyway), and yet it takes about the same about of time to load Windows, open Word, write a short document, save it, and then shut down.
I know it's because the current version of Word offers a vast array of features that I could only dream about through most of the last decade, but most of the time, I'm not going to use it. I don't even want it to load into memory until I specifically tell the application that I'm about to do some graphing, or translating, or whatever. Can't these apps open in a kind of "thin mode", and stand ready to load additional features as I express desire to use them?
As fast as breakthroughs are made in hardware, software is always able to keep pace, demanding more and more of it. This is fine for games, or other applications that offer a better experience with the additional resources (and which are not designed to be run alongside other apps), but for basic office work or internet browsing? Those applications should be lightning fast by now.
Re:Security? (Score:4, Interesting)
Reading those it is not apparent to me that they are due to WebKit issues. Are they?
Design really matters (Score:4, Interesting)
However the browser you write won't just be running your own code. It will be running code written by Adobe, Facebook 3rd party apps, and so on.
Given that, it's wiser to design your browser to use processes, so if you or somebody else screws up, the offending tab can be killed without affecting the other tabs, and also the memory used gets freed up (this is quite important given the large amounts of memory a tab can use nowadays).
You could in theory have your browser threaded, but use processes for the plugins, javascript and future junk^H^H^H^Hfeatures the W3C comes up with, but at that point how much do you really gain?
Why do you think Microsoft sees Google as the enemy? They are right. Google have just launched a new "operating system".
It's wise for Google's "operating system" aka browser to have process isolation, so that it is harder for one misbehaving instance to take down the rest.
Cooperative multitasking is so 1980s.
Re:Are processes really that much heavier? (Score:3, Interesting)
its more OS overhead - a thread has its own stack BTW, so it can use a lot more than 100k.
But, what a thread doesn't have to deal with is the interaction with the OS - security permissions, allocating the heap, shared dll loading etc. Multiple threads in a process get to reuse these resources that the process had to create or deal with.
This is why Windows is traditionally worse at multi-process systems and unit is better: the cost of starting a process on Windows is high, whereas the cost of the same on unix is lower. In both systems, the cost of starting a thread inside a process is quite low however. (but not so low that you can create them all over the place: best to stick to pooling designs).
Once started, the OS only executes threads - all processes can be thought of as 'process overhead' + 1 thread.
The big problem with running threads is that you have to handle synchronisation yourself, with processes the OS does it for you, so a poor thread design can be worse performer than a multiple process model.