Slashdot Log In
Mozilla Project Hurt by Apple's Decision to use KH
Posted by
Hemos
on Tue Jan 14, 2003 01:43 PM
from the the-battle-rages-on dept.
from the the-battle-rages-on dept.
Anonymous Coward writes "I Read this article from ZDNet claiming how some of the Mozilla developers were hurt by Apple's decision to use KHTML over Gecko. I can see both their points. Mozilla was made for cross-platform compatibility, and this probably adds to the bloat, however that's not what they were looking for. They wanted small and fast."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Pride of Authorship (Score:5, Insightful)
I'll continue to use Mozilla, if it makes the developers happy!
Strategic Decision (Score:5, Insightful)
For the longest time, Netscape owned the browser market, and set the standards. That was OK for Apple, except that the Mac version of Navigator lagged behind the Windows version, particularly with Java implementation. Then MS came along, and there was a "standards battle" between IE and Navigator; MS was so determined to win that they even wrote a better version of IE for Mac than for Windows. IE has emerged on top and, true to form, MS is now trying to move the standards to favor IE on Windows with things like ActiveX controls. Netscape/Mozilla has been and continues to be holding their own, without assistance from Apple. Apple's support of KHTML instantly puts a new rendering engine on millions of computers and lessens MS's grip on the web (albeit slightly), because IE for Mac will not be the default browser anymore on Macs (I'm assuming).
The best thing that could happen right now in the browser wars is not for Apple to jump into the IE/Mozilla fray, but to stir a rivalry between two open source browsers, KHTML and Mozilla. Get these to browsers to compete on features, and put MS back into the position of being a follower rather than a leader.
Parent
competition (Score:5, Insightful)
I agree, but I think we can extend that to say "multiple Open Source browsers on the market." I think Apple adopting and improving on KHTML helps the KHTML guys, which makes them a better competitor to Mozilla. The same way a M$ monopoly is harmful to the industry, a monopoly by one Open Source browser, IMHO, is also not a good thing. So at the end, I think this will help everybody, not just Apple.
Parent
Safari is only half finished... it will bloat (Score:4, Insightful)
At the end of the day though, who cares if they use Mozilla or not?
What's important is that they're dumping IE, thus freeing themselves from a dependence on Microsoft.
PS: "Bloated" or not, Mozilla runs just fine on my PC.
even if it's "half finished".... (Score:5, Insightful)
Safari has a ton of room to grow before it achieves Mozilla's mammoth size.
Regardless of this, Safari is far more than halfway done.
Parent
Re:even if it's "half finished".... (Score:4, Insightful)
Parent
Bloat (Score:5, Insightful)
21.4 MB (21,743,324 bytes) Dec 20,2002.
Safari
7.2 MB (6,928,478 bytes) Jan 11, 2003
Chimera is ONLY the browser and bug feedback.
Parent
Re:even if it's "half finished".... (Score:5, Funny)
Safari is closer to 90% done.
Of course, that just leaves the other 90% to do...
Parent
Re:even if it's "half finished".... (Score:5, Insightful)
Oh please. That's such a pile of crap.
Developers always start off thinking they can do what the competition does, except faster and smaller. The Mozilla project themselves started off that way. I remember in the early days them proudly announcing their rendering engine would fit on a floppy disk.
Then they started making it actually work and be useful on the web. They added support for the latest technologies, they made it cross platform (which itself has quite a bit of overhead) and so on.
Getting to about 80% of the features of your nearest competitor while staying small and fast (relatively) isn't hard, but what you always find is that after you've done the last 20% and you have enough compatability to be useful in the real world, and your software has all the hairs necessary to make it work on grans bizarro ancient setup, and then you find you made a mistake in the design that wasn't obvious at the time so you hack around it and so on ... by the time you've done all of that you're just as big and "bloated" as the competition.
The idea that somehow the KHTML have magically produced something better than Gecko is fallacy. Don't get me wrong, KHTML is a fine piece of work, but to pretend it'll remain fast and light when it has to deal with enough web pages to be useful and support all the new tech (XSLT, XForms, SVG etc, XPath, SOAP) that's beginning to filter down into the general purpose web is insane.
Joel Spolski wrote a good article on rewriting software in this way, and despite the fact that KHTML was already there, it fits into his theories quite well. Sometimes you don't have much choice, the old Netscape codebase was SO bad it could never have gone further, but it's something that's done in dire straits only.
Oh and finally, considering Phoenix is smaller than that, but does more, I'm not particularly impressed anyway.
Parent
Re:even if it's "half finished".... (Score:5, Interesting)
I've attempted to get involved in the Mozilla project multiple times, and I still don't understand how pretty much anything in their browser works.
I've been interested in KHTML for a week, and I have a very solid understanding of the renderer and the basic flow of information. I already see how the "final 20%" will be implemented without becoming hackish like Gecko feels.
I think KHTML has Gecko beat for engineering simplicity by about a mile, I do hope Gecko continues to improve, but it's no where near what KHTML is like now. I think one of the Mozilla engineers said it best (this is misquoted since google can't find the quote I'm looking for) "There are a handful of people who understand Gecko in the world", KHTML on the other hand just has that "clean code" feel to it, all the way through.
Parent
Actually (Score:4, Informative)
Parent
Re:Safari is only half finished... it will bloat (Score:5, Insightful)
Chimera is 20.6MB while Safari is 7.2MB and neither of them provide alternate localizations, afaik. So you're saying it takes 13.4MB of code to properly handle CSS? Believe it or not, but Gecko re-invents the wheel many times over under the hood for the sake of being cross-platform, and pays for it.
Parent
Oh boo hoo... (Score:5, Insightful)
Re:Oh boo hoo... - AtheOS (Score:5, Insightful)
The crude abstract of this article implies KHTML is not cross platform. History says otherwise.
<soapbox> - you do not need to agree
Personally, I think Mozilla has set free software back about two years. Alternative browser development came to a standstill when netscape released the code. After all, we were all going to have a fast, lean, free, standards compliant browser as soon as they got it compiled. Then came the slips, the rewrites, the bloat, and the delusions of grandeur.
Parent
Re:Oh boo hoo... - AtheOS (Score:5, Interesting)
Years from now, when documentaries are written and case studies developed I think we will see many eyes looking at that moment. It didn't come to a standstill, it took off very quickly and then something wierd happened. I remember it well...
Netscape opens the code, and in the Gtk v KDE flame wars two teams take to porting the code to their framework. the problem? It was built off of Motif, a non-free gui toolkit.
With the swiftness of the Open Source community, all of a sudden we had three "almost there" choices for a completely free Netscape. Seemingly just as quickly all were abandoned by the freedom offered by this software movement.
QT-Mozilla and the subsequent KMozilla (if I remember right) was finished in a month by porting it to the QT toolkit of the day. Not to be outdone GTK-Mozilla announced that whatever they could do, we could do better and a sole programmer began the effort, with a few joining later.
Back at the ranch, JWZ felt that it would have be far easier to pound out the last few details in "Lesstif" and link off of that. The Lesstif people were very close to binary compatibility with version 1 of Motif.
Then for all the work going on it then it seems to have run out of steam. As far as I know (someone please correct me if I'm wrong), lesstif still can't dynamically link to netscape, GTK was abandoned, and the KDE people abandoned Netscape code entirely.
So why it those three easiest paths were abandoned so quickly is the stuff that PBS is made of, and I'll probably never know until someone takes it up.
Parent
Mod parent up!!! khtml is crossplatform. (Score:5, Informative)
It can be used without X (kde no X = kdenox, in CVS), without unix even, as Atheos shows.
Nobody remember Konqembedded?
http://www.konqueror.org/embedded.
Also the only slight dependency is qt, which is crossplatform (Windows, Unix, OS X, embedded). As Apple [and Atheos] shows, it is easy to write wrapper to get rid of even that dependency.
Parent
Best tool for the job (Score:5, Interesting)
KHTML can't be _that_ bad w/r/t cross-platform ... (Score:5, Interesting)
Let's call it like it is -- Gecko, while a noble effort, is really a failure. It was YEARS late, and completely missed its goal (a lightweight, fast. cross-platform rendering engine). One bit of that (cross-platform) does not a success make.
I have to say, I'm absolutely impressed with Apple's Safari. It's FAST as all getout, and it's the first browser that really makes me think twice about having paid for OmniWeb. I've been using Safari daily since release and while, yes, it has some bugs, it's still better than Chimera, OW, & Mozilla combined. IE also has its rendering issues, and I detest lots of other things about it.
Safari's what a browser should be -- small, lightweight, and out of my face. The interface is slim & sleek, and, like the rest of Apple's software, lets me focus on the CONTENT rather than the delivery.
I really think that's why OSX is so wonderful -- it just stays out of my way and lets me do what I gotta do. And I have to admit, running a DVD authoring program alongside several terminal windows on a Mac (!) is still impressive to me.
Apple didn't buy NeXT. NeXT swallowed Apple whole.'
--NBVB
Re:KHTML can't be _that_ bad w/r/t cross-platform (Score:5, Interesting)
Exactly. Everybody here seems to be using the excuse that mozilla is cross-platform, and can expect to be bloated. Well khtml works across unix/x, linux/framebuffer, and now osx as well. it's based on qt, which works on windows just fine. The Safari developers even noted how easy it was to port (all they basically did was sit it on top of a small framework that was a substitute for the kde-specific bits).
The QT toolkit is one of the reasons this can be done in an efficient, easily understandable way. It's a great toolkit, and it's a shame the mozilla project decided to ignore it in favour of gtk/xul/javascript/etc.
I wouldn't go that far. It's a very useful, very standards-compliant, cross-platform rendering engine. The fact that somewhere along the line the project fell prey to creeping featuritis doesn't change this.
On the other hand, this usenet post [google.com] sums up how I feel about the whole thing.
Parent
Re:KHTML can't be _that_ bad w/r/t cross-platform (Score:4, Insightful)
Safari does not use QT for MacOS X.
Parent
KHTML developers (Score:5, Insightful)
And this is a Surprise, Why? (Score:4, Interesting)
1) Use this extremely bloated, unoptimized browser or
2) Use this smaller engine that can be optimized with little effort to run like a top on our operating system.
I'm sorry but Apple is doing what any good business would do, its looking out for its own interests. But I fail to see how this hurts Mozilla. So what mac users can use another browser. COMPETITION IS GOOD. maybe this will get those Mozilla monks in gear and start making their browser SMALLER instead of adding X more features that I don't need.
Now if all the browsers would just use the same plugin models....
Oh, no! Horror of Horrors! (Score:5, Insightful)
Good to see KHTML in the commercial spotlight, and not just Mozilla. I'm typing this in Mozilla, which I sear by and tell all my friends about, but KHTML is good, too.
No... (Score:4, Insightful)
In the end this is a bit of a win for Mozilla and all open source software.
1. It is a high profile (if low distribution) browser based on an open source core. This is a good thing for open source projects in general.
2. Competition in the open source browser arena is not a bad thing. I predict that both browsers will get better as a result or some good natured competition.
3. Apple is not anti-Mozilla, they just decided to use a different rending engine for Safari.
4. Chimera (Mozilla based) is still a better browser than Safari on MacOS X.
Chimera, yes (Score:5, Insightful)
I've been using Chimera [mozilla.org] nearly exclusively for months. The Dec. 20 release (vers. 0.6 + a few features) is the nicest so far. What a development curve in the past year compared to the much older Opera and iCab!
I think it's interesting that Chimera is related to NS and Mozilla (Gecko) yet is soooo much cleaner and faster. Unfortunately it gets tarred with the same brush by people who haven't used it much.
Chimera's a lot more Aqua than Safari, too! I think Safari is stunningly ugly for an Apple product.
I agree and don't see why both open source projects can't continue. Competition is not just healthier than bloated monopoly, it's essential when we don't even know precisely what we're after. And our shared mission must be to kill IE, or at least beat it back....
Parent
ZDNet took statements out of context (Score:5, Informative)
Why hate KHTML? (Score:5, Insightful)
Apple made a perfectly valid choice, and contributed their changes back to the free software community. Yet another great free software project now benefits from Apple, at IE/Microsoft's expense of market share on Mac desktops.
Don't draw any conclusions you don't have to. I love Mozilla, too, but Apple made a decision, and one which even most Mozilla developers feel was a valid technical choice, even if it wasn't the one they themselves would have made.
What exactly did Apple do wrong again?
Portability not an issue (Score:5, Insightful)
Mozilla hurt by Mozilla, not by Apple. (Score:4, Interesting)
The Beauty of Choice .. (Score:5, Insightful)
Hey guys... (Score:5, Insightful)
"ZDNet trolls for more page hits yet again - film at 11."
The article doesn't say that! (Score:5, Informative)
Apple hurt Mozilla? The only thing that hurt Mozilla was Mozilla. And for the most part, the Mozilla developers know that already.
"Editors," indeed.
Competition is good (Score:5, Insightful)
However, seems like the KDE folks have done a great job here, so congrats to them. The Mozilla folks shouldn't feel "hurt", this should motivate them to improve what is already a really good browser.
The competition is not only IE, but more stuff is showing up all the time. That's great, competition in the browser arena is back. For a moment I tought we'd be stuck with IE forever!
another good (and related) read. (Score:5, Informative)
I think it's great! (Score:5, Insightful)
Fp! (Score:5, Funny)
Good for Apple (Score:5, Insightful)
David Hyatt on KHTML vs Gecko (long) (Score:5, Informative)
Quoted from the original mail to the KDE folks:
Mike Shaver writes in his blog:
David Baron writes:
Here are the two function protoypes that David Baron linked to. I think they pretty much illustrate the point perfectly.
KHTML: virtual void layout(); Gecko: NS_IMETHOD Reflow(nsIPresContext* aPresContext, nsHTMLReflowMetrics& aMetrics, const nsHTMLReflowState& aReflowState, nsReflowStatus& aStatus);
This is a wonderful example. Let's go over it in detail. First notice the NS_IMETHOD on the prototype. Basically this means the base class of all render objects in Gecko is an XPCOM interface. Rather than develop a clean tearoff model so that you could create heavyweight objects for external use while keeping the internal objects lightweight, most of the layout structures in Gecko *are* heavyweight and rely on communication through COM interfaces and virtual function calls. Many of those objects are refcounted, but adding insult to injury, some are simply pseudo-COM and their refcounting functions (addref/release) do nothing. Complete confusion can ensue if you aren't aware of which objects are special and which aren't.
Next, let's take the first argument to Reflow. The nsIPresContext is passed as an argument to virtually every layout function for one deeply flawed reason, namely the ridiculous idea that one document should support multiple presentations simultaneously. This is simply not needed in a desktop browser. This separation results in multiple nsIPresContexts and nsIPresShells being supported for a given document, and even getting to the right shell is a pain. (document->GetNumberOfShells; document->GetShellAt(0); etc)
Next we have nsHTMLReflowMetrics and nsHTMLReflowState. Rather than compute size information (like min and max width) up front in a separate pass and just caching it on the objects, we have this object passed down along the reflow chain. There is still other information that could be cached on the objects themselves, like maximal positive and negative margins for correct margin collapsing of vertically adjacent blocks. KHTML does this. The Gecko way, although it makes for smaller rendering objects, has the drawback of making incremental reflow problematic. For example, if you tweak one margin on some block deep in your document, you'd like to only recompute margin information for that single block. If you don't cache margin information anywhere, however, you'll have to crawl around again in order to figure out the correct placement for the block. I'm not sure if Gecko does this or not, but my guess is it just gets margins wrong in many incremental reflow cases.
I don't even know what nsReflowStatus's point really is. Seems like it could just be the return value from Reflow if you really needed to keep it around.
Finally, the name of the function. Gecko chooses strange English words for various processes and objects within layout. Instead of just using layout we get reflow. Instead of RenderObject we get nsIFrame. In some cases KHTML is no better, but where it counts, I think most of the names are more readable.
Now compare directory structure. KHTML has a simple obvious directory structure. Before I knew anything about the code, I was able to guess the right directories for various implementations. Gecko has the opposite problem. There are way too many interfaces first of all, entire objects that have no reason for existence. These mingle with the useful files making it harder to find what you're looking for. Combined with a byzantine directory structure, (e.g., portions of the CSS back and front ends are scattered between two separate libraries and multiple directories within those libraries.), Gecko becomes extremely difficult to wrap your head around.
The upshot, and this cannot be stated clearly enough, is that there are only a handful of people who are even capable of modifying Gecko, because the code is so unreadable and so complex.
Now imagine that your number one priority for a browser is speed. You want a browser that launches almost instantly. You want a browser whose page load peformance can be improved dramatically. This is your number one goal, because you want to address what has been a fundamental problem on your platform (OS X) ever since it was launched: that no browser has accomplished the goal of fast startup and fast page load. Your job is to find an existing open source engine and improve it to the point where it does have fast startup and phenomenal page load times.
The problem is, how do you make Gecko have a fast startup time on the Mac? Comparing Chimera's slow cold launch with its zippy warm launch, it's readily apparent that much of Gecko's startup time problem on the Mac is due to the enormous code footprint. So, in order to use Gecko, your first task would be to shrink this code footprint. So how do you do it? Well, you'd have to deCOMtaminate a lot of the core code, eliminate redundant interfaces, and in some cases re-architect dramatically a lot of components so that they didn't need to exist. For example, Gecko has its own image loading library, which you would want to eliminate in favor of simply using the operating system's image capabilities. Ditto for networking.
Now look at KHTML, which dropped in as is (with QT implemented) gives you a fast startup time right off the bat, because the code is so small and well-designed that you don't even have to worry about startup. A whole huge set of tasks eliminated simply by picking KHTML over Gecko.
Next consider the problem of native widgets. KHTML has a clean separation of the form controls as native components (using QWidget and QInterfaces to communicate), so all you have to do is back those QInterfaces with Cocoa implementations and bang, you have native form controls.
The same problem in Gecko is months of work. You have to develop these interfaces for each widget (they don't exist), and then slowly but surely get native widgets working again. You'd have to completely rearchitect all the form control render objects in Gecko to talk to native widget interfaces. Then you get to have fun fighting all of the bugs from a brand new forms implementation and again would probably have to modify other parts of Gecko to support these new form controls.
So to summarize: with KHTML what you have is a tiny engine with reasonable standards compliance and native widgets that would need to become a tiny engine with native widgets and outstanding standards compliance. WIth Gecko, you have an enormous engine with outstanding standards compliance and non-native widgets, that would need to become a small engine with native widgets while still retaining outstanding standards compliance.
Which task is going to be easier? There's no question that both involve heavy modification of the layout engine, and both involve a lot of work, so then the question becomes, Which one is easier to modify? In my opinion (speaking only for myself), the answer is KHTML. I won't pretend that the choice of KHTML over Gecko is a no-brainer (it's not), but for those of you who think standards compliance is the only consideration when developing an outstanding browser engine, well, hopefully this will give you some food for thought.
Talk about euphemisms (Score:4, Interesting)
-jfedor
Well, they have a point (Score:5, Interesting)
Well, no offense, but is Melton wrong?
I mean, download the source for both and look at the difference. The sheer volume of Mozilla is overwhelming even for the experienced programmers.
There has been an enormous effort gone into Mozilla and it shows, but I think it still has a way to go.
And I love this quote:
"Gecko is already embedded and distributed in real-world applications from Red Hat, IBM, OEone, Netscape and CompuServe, and we look forward to the upcoming releases of Gecko-based products that are currently in development."
Yes, and of course KHTML is not used in the "real" world.
Good for Standards (Score:5, Insightful)
The payoff for pushing for standards is that *everyone* benefits as long as they stick to said standards, and Mozilla's efforts seem to be working in that regard.
Good for Chimera, Good for Mac users (Score:4, Interesting)
My honest opinion is that Chimera is better than the other Mac browsers - but will have stiff competition from Safari.
There are things that I like from Safari that I would like to see in Chimera. Like some of the interface elements - like the progress bar or snap back... And there are things from Chimera that I would like to see in Safari - like tabs and better cookie management and popup management. I would like both to offer flash filtering the same as chimera/mozilla do image filtering.
All in all I think the other browsers can learn from Safari - and Apple can learn from the success of the open source Chimera. Currently - I still prefer Chimera, the latest builds have so far been extremely stable, fast, and usable. Thank you Chimera Dev....
architecture questions (Score:5, Interesting)
Why are we using xpcom considering the huge bloat/threading issues on non-win32?
Why do the signatures on our api make almost no sense to outsiders?
Why do we compare our performance almost exclusively to IE?
If Apple wont use our code because it's too big, do we have any real chance of being used on small devices?
Why are we still using xul now that we ifdef [hixie.ch] out platform-specific ui code?
I'm sure there are more questions that someone more knowledgable than I am can come up with, but these are questions that haven't been taken very seriously up to now, because there has not been a high-profile alternative to gecko.
I've been using mozilla/phoenix for several years (I've even submitted a few patches), and I think it's an absolutely amazing peice of software, but it *is* huge and hard to understand. It is hard to recognize the size and complexity for what it is without a highly visible comparison like khtml.
Build a Gecko WebCore!!! (Score:5, Interesting)
So... make a Gecko based webcore replacement. Apple has given us a slick framework to implement in order to drive Safari's backend. We can already patch and update our KHTML based webcore... if Gecko would be better, use it. You still get the slick Apple GUI. Right?
I think (WARNING: dumbass user demanding major architectural changes) Chimera should make their Gecko variety use the WebCore framework design, so that their backend would be pluggable with Apple's. Then we could end this argument. There'd be no argument.
Re:Nothing new here (Score:5, Informative)
Parent
Re:Nothing new here (Score:4, Insightful)
<sarcasm>Yep, that sure does "smack of proprietary lock-in".</sarcasm>
Parent
Re:Nothing new here (Score:5, Informative)
Apple has never valued cross-platform compatibility except at great urging.
never is a strong word in my books-- what do you call bluetooth, 802.11, firwire, opengl, xml, and usb? refusal to embrace and push for open standards? if anything, apple is the measure of computer industry these days.
From the days of proprietary Apple-only hardware and the squelching of would-be competitors, to the modern day with the refusal to port Aqua and launching the iPod for Macs only.
computers are what apple sells and they stay in business by selling their machines, not other peoples'. the licencing of apple hardware was flawed from the beginning and handcuffed apple into killing the program because of abuse. porting aqua to other platforms would be the end of apple-- remember, they are a hardware complany, not a software company. aqua sells macs, not the other way around. so do ipods. apple builds incentive to buy their hardware, why give those incentives to other platform users?
the integration of an X server in the latest release is definitely the exception to the rule.
pal, you have so missed the boat in your post that i think you should take a step back from this fud. x server is merely the tip of the iceberg of what has been the "exception to the rule". os x is on the cutting edge of the open source / corporate relationship, existing on open standard freebsd and countless other non-proprietary formats. if the other favourite popular target of slashdot could be mentioned this favourably, we wouldn't be here.
just my two cents.
Parent
Time Warp Baggage (Score:4, Insightful)
I'm using Mozilla to post this and I find it a wonderful standards compliant browser.
However, I've tried on occasion to download the source distribution and frankly I find it far too heavy (abstract, complex) for casual development. Guerilla development won't work for Mozilla; it has degenerated into long term trench warfare for anyone with the stamina for it. I applaud you Mozilla developers, but am not made of the same stuff.
I remember once coming across some C++ portability standards made up by the Mozilla team about 5 years ago. They were relevant to portability back then, but I think things have progressed some over the years. Many of those problems with different platforms have disappeared with release of the ANSI/ISO C++ standard and the work that's gone into modern compilers.
Personally, I think the Mozilla team ought to be unleased to begin Mozilla 2.0 from scratch, based on everything they know so far, and not be shackled to weird platforms from the early 1990s. Let the Moz 1.* tree address the needs of those using old platforms - the standards compliance should keep them humming for years to come.
The Moz 1.* development has progressed admirably, especially if, like me, you've worked in baroque plumbing factories of code, then you can doubly appreciate the accomplishments of the Moz developers.
But it's high time for them to start from a clean slate, just as the Safari folks have.
Parent
Re:abandon ship (Score:5, Insightful)
Parent
Re:mozilla (Score:4, Insightful)
Good point.... I'd wager that Apple moving away from IE will help push the alternative browsers along. Less people will think "I *have* to use IE to view the web sites I visit" and there will be more people investigating Netscape again, as well as Mozilla, Opera, etc.
Parent