Forgot your password?
typodupeerror
Mozilla The Internet

Mozilla Project Hurt by Apple's Decision to use KH 647

Posted by Hemos
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.

Mozilla Project Hurt by Apple's Decision to use KH

Comments Filter:
  • by tealover (187148) on Tuesday January 14, 2003 @02:48PM (#5082338)
    I don't think the Mozilla guys should take Apple's decision as anything more than Apple trying to do what's best for Apple. We users may have the luxury of using political motives in determing which software to use, but corporations have to answer to shareholders. If Apple sincerely believes they made the best choice for them, then I hope it works out well for them.

    I'll continue to use Mozilla, if it makes the developers happy!

    • Strategic Decision (Score:5, Insightful)

      by artemis67 (93453) on Tuesday January 14, 2003 @03:17PM (#5082553)
      Look at it another way... Apple may benefit simply by virtue of having multiple browsers on the market.

      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.
      • competition (Score:5, Insightful)

        by ryochiji (453715) on Tuesday January 14, 2003 @04:03PM (#5082669) Homepage
        >Apple may benefit simply by virtue of having multiple browsers on the market.

        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.

      • by autopr0n (534291) on Tuesday January 14, 2003 @04:40PM (#5083012) Homepage Journal
        Your post becomes even more relevant when you consider the fact that so many web-developers, particularly the 'artistic' kind use Macs. Not that I'm a Mac zealot, far from it, but I'm just stating facts. So many web designers switching to $NOT_IE will really help kill IEs total dominance. If not in numbers, in the hearts and minds of developers.
      • by catwh0re (540371)
        this is an excellent point. apple are pretty tired of being forced directions because of software makers.

        So think of it all this way, now we have two mature open source browser projects, instead of one really advanced one, and a bunch of others with no chance of catching up.

  • by Anonymous Coward on Tuesday January 14, 2003 @02:48PM (#5082339)
    Mozilla supports many more standards/protocols than Safari As Safari reaches this level of functionality it will get bigger and bigger.

    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.
    • by SweetAndSourJesus (555410) <JesusAndTheRobot&yahoo,com> on Tuesday January 14, 2003 @02:53PM (#5082399)
      Safari weighs in at 7.2 megs, Mozilla is 38.3 megs.

      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.
      • by sporty (27564) on Tuesday January 14, 2003 @02:58PM (#5082439) Homepage
        Mozilla is a suite. Safari is a browser. I'd hope that with today's resources, mozilla as a browser only, w/o XUL, chatzilla, composer and all the other goodies, would be ~7.2 megs.
        • Bloat (Score:5, Insightful)

          by Wyatt Earp (1029) on Tuesday January 14, 2003 @04:08PM (#5082713)
          Chimera 0.6 (Navigator)

          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.

          • Re:Bloat (Score:3, Informative)

            by jonadab (583620)
            Yeah, Gecko is big. It has to be, to get all the layouts correct.
            Understand, it's designed to lay out and render, correctly, anything
            from non-wellformed pre-W3C HTML on the one end of the scale up
            through XSLT at the other end, plus XUL. That's a tall order.
            Konqueror doesn't handle quite as wide a spectrum.

            That said, KHTML handles more of MSIE's proprietary non-W3C extensions
            to the DOM than Gecko does, which _may_ be part of why Apple chose it.
            • Re:Bloat (Score:4, Interesting)

              by bunratty (545641) on Tuesday January 14, 2003 @11:27PM (#5085417)
              Yeah, Gecko is big. It has to be, to get all the layouts correct.
              Opera 7 is about as standards-compliant as Mozilla, and contains e-mail and newsgroup clients like Mozilla. Yet the Opera 7 download is only 3.3 MB as opposed to nearly 11 MB for Mozilla. Highly standards-compliant browsers need not be big. I doubt that Safari will grow much bigger as a result of making it as compliant as Mozilla.
      • Safari weighs in at 7.2 megs, Mozilla is 38.3 megs.

        In all fairness, Mozilla has a full-blown email client, news reader, etc., included in that size.

        A fairer comparison would be to Mozilla Phoenix [mozilla.org], which is a browser only. Still considerably bigger than Safari but nowhere near the size of the fullblown Mozilla.
        • Actually (Score:4, Informative)

          by commodoresloat (172735) on Tuesday January 14, 2003 @04:16PM (#5082809)
          We should be comparing to Chimera [mozilla.org], which is the OS X version of the trimmed-down Mozilla-based browser. My copy is about 21M.
          • Is there something about OS X executables that makes them much larger than Windows or Linux?

            Looking at the full mozilla download, I see Windows - 11 MB, Linux - 13.5 MB, OS X 18 MB. (38 MB must be the uncompressed version).
            • Re:Actually (Score:3, Informative)

              by alannon (54117)
              Actually, yes. PPC object code tends to be about 2/3 larger than X86 object code. Sometimes larger, actually, depending on the compiler.
      • by ChaosDiscord (4913) on Tuesday January 14, 2003 @04:26PM (#5082896) Homepage Journal
        Regardless of this, Safari is far more than halfway done.

        Safari is closer to 90% done.

        Of course, that just leaves the other 90% to do...

      • by IamTheRealMike (537420) <mike@plan99.net> on Tuesday January 14, 2003 @04:52PM (#5083110) Homepage
        Safari has a ton of room to grow before it achieves Mozilla's mammoth size.

        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.

        • by ealar dlanvuli (523604) <froggie6@mchsi.com> on Tuesday January 14, 2003 @08:24PM (#5084551) Homepage
          I normally agree with what you post, but I'm going to have to disagree here.

          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.
      • Safari weighs in at 7.2 megs, Mozilla is 38.3 megs.

        How in the hell did this get modded insightful? Seeing past that none of these figures are correct, i.e. Safari is NOT 7.2MB but closer to 3MB and Mozilla is nowhere near 38.3MB, it actually compares two completely different applications. This guy might as well have compared both of these figures to OpenOffice or Microsoft Office.

        Besides all the replies that have mentioned that obviously Mozilla not only contains the Gecko engine, provides an e-mail client, newsreader, chat client, addressbook, authoring tool, numerous debuggers, its own full graphical user interface, feedback agent, it should also be mentioned that it provides a platform for application development that can be used not only for above tasks but for virtually anything else. Take all of these applications, put them in one package, and you are guaranteed to have an 11-15MB install at least (which is Mozilla's actual size).

        A more fair comparison would have been one between Gecko and KHTML (just like Apple did). But even then it doesn't do complete justice. Why? Because it depends on the use. KHTML is designed for and is good at rendering (X)HTML, CSS and Javascript. Beyond and above this, Gecko does client-side XML/XSLT rendering, XUL rendering, and so much more. And, does all of the above in a more standards-compliant way than KHTML.

        I don't mean to bash KHTML but I don't believe there's any reason to take shots at Mozilla or Gecko, like many posts already did. Apple didn't mean it that way in their e-mail [kde.org]. If you read it (rather than the ZDcrap article) you will see that they meant to praise KHTML and describe how well suited it was to their specific needs.
    • by Daleks (226923) on Tuesday January 14, 2003 @03:53PM (#5082597)
      Mozilla supports many more standards/protocols than Safari As Safari reaches this level of functionality it will get bigger and bigger.

      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.
  • chimera! (Score:3, Insightful)

    by simpl3x (238301) on Tuesday January 14, 2003 @02:48PM (#5082342)
    at least they didn't compete and crush the competition! chimera is still rather nice! multiple platforms--gecko--mmake for better competition!
  • Mozilla Lite? (Score:3, Informative)

    by Gunfighter (1944) on Tuesday January 14, 2003 @02:48PM (#5082346) Homepage
    Why not use phoenix or some similar project w/out the bloat of the full-blown Mozilla?

    -- Gun

    P.S. First post
    • Re:Mozilla Lite? (Score:4, Insightful)

      by bhsx (458600) on Tuesday January 14, 2003 @04:25PM (#5082886)
      Because it wasn't Mozilla or Konqueror we're talking about. It's Gecko vs. KHTML, the rendering engines that each project uses, respectively. Phoenix uses Gecko, and it was Gecko they rejected for KHTML. A better question might be...
      "Why haven't the Gecko-based projects, such as Phoenix, looked at KHTML?"
      The answer there may be that it's not as cross-platform-ready as Gecko is; but most likely the answer is more along the lines of "What's KHTML?" due to Mozilla's high exposure.
  • Oh boo hoo... (Score:5, Insightful)

    by npietraniec (519210) <(npietran) (at) (resistive.net)> on Tuesday January 14, 2003 @02:48PM (#5082347) Homepage
    Would the khtml people be "hurt" if apple had used Gecho? Maybe if the Mozilla people are so injured they should look at why KHTML was chosen over Gecho and take steps to improve. Such is the beauty of competition. Maybe the mozilla people aren't aiming for what the Safari people were looking for... Maybe portablility wasn't important as size and speed to the Safari people. Apple adopting an open source browser is ultimately a very good thing, whether it be Gecho, Khtml, or some other open sourch engine.
    • by victim (30647) on Tuesday January 14, 2003 @04:17PM (#5082825)
      Its worth noting that when Atheos (nifty OS, not a unix clone, dead now) needed a browser the author evaluated KHTML and Mozilla and decided KHTML was far easier to port, then proceeded to do it in a week or so.

      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.
      • by On Lawn (1073) on Tuesday January 14, 2003 @04:54PM (#5083129) Journal
        Alternative browser development came to a standstill when netscape released the code.

        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.
      • by Moritz Moeller - Her (3704) <mmh.gmx@net> on Tuesday January 14, 2003 @05:12PM (#5083232)
        Jesus H. Christ! How can anyone claim that khtml ist not crossplatform?

        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.h tml

        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.
      • That would of been Kurt. Anyway, the browser in question is ABrowse of which I'm now the maintainer and lead developer (found here [sourceforge.net]). We've evaluated gecko verse khtml and everyone wants gecko. It renders more pages correctly. However as a lazy, ;), developer I'm sticking with khtml for now. It just makes more sense for syllable/atheos [sourceforge.net] which is also c++. Our port of KHTML is rather crufty but still ingenious. Kurt remapped qt widgets to our native kit, set the appropriate browser callbacks and somehow got everything up and running. I took over about a month ago and have only gone through about 10% of the actual khtml code (although we do now have tabbed browsing :). I think the thing for Apple was the just the plain size of such a porting job to a non already ported platform. From my work on ABrowse I couldn't possibly imagine porting gecko, especially since we do not rely on an X, gtk or any of that stuff gecko wants to compile.
        Just thought I'd chime in...
        - Shawn

        ps - Atheos is not quite dead. If interested check out Syllable at the link above. Syllable is very much so alive and progress has speeded up over the atheos days.
      • by Arandir (19206)
        The crude abstract of this article implies KHTML is not cross platform. History says otherwise.

        I don't know why people keep saying KHTML isn't cross platform. It runs on 18 different platforms that I am aware of. Linux, FreeBSD, Solaris, AIX, OS/2, etc., and i386, m68, Sparc, Alpha, etc. And don't forget the embedded palmtops! It's underlying Qt library is the world's premier crossplatform GUI library.

        But frankly, Apple isn't in the business of supplying browsers for the Windows platform, so who cares?
  • by boinger (4618) <[boinger] [at] [fuck-you.org]> on Tuesday January 14, 2003 @02:49PM (#5082351) Homepage
    Apple's R&D people are some of the best and their research showed which path was 'best' based on some checklist spawned from some meetings somewhere in the depths of Apple. Would we have a similar story if the KHTML kids were hurt because Apple went the other way? No. Their project is seen as less-significant. Do they have their own icon on /.? Similarly, no. For the same reason.
  • by nbvb (32836) on Tuesday January 14, 2003 @02:52PM (#5082380) Journal
    I mean, if the Apple folks were able to port KHTML to OpenStep^WMac OS X from that whole Linux-QT-KDE mess, it can't be that bad, can it?

    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
    • by JimDabell (42870) on Tuesday January 14, 2003 @04:01PM (#5082641) Homepage
      I mean, if the Apple folks were able to port KHTML to OpenStep^WMac OS X from that whole Linux-QT-KDE mess, it can't be that bad, can it?

      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.

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

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

      Actually its goal was to be useful and powerful. The fact that they thought they could also be fast and light is a common mistake amongst coders, the two arne't necessarily mutually exclusive but often are in real life.

      Gecko is standards compliant, fast (no, really), supports many standards and is extremely powerful. So, it's larger than KHTML. Most importantly, it actually renders the vast majority of the web.

      Apple have a problem - their machines are slow. I compiled GNOME2.2 with Galeon today, and the speed blew me away. I have never used such a fast browser. Tabs opened and rendered near instantly (I was using the paint-delay trick) and I never found myself waiting for the browser, it was just there. I'm sure other people who've used Galeon2 can corroberate this. This is not a particlarly fast machine, an Athlon 1400 I think, and Gecko hasn't been optimized for Linux as much as it has for Windows (on which it's also very fast), so this Gecko is slow BS seems to be more a Mac problem than anyhting else.

      I mean, if the Galeon team can produce an insanely fast browser out of Gecko, what's stopping Apple?

      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.

      Oh boy, that's funny. So that's why it has a textured window (that cannot be themed to something less distracting), along with all the rest of the usual Apple eyecandy - but no tabs?

      Apple is all about presentation. See how all the talk here is of speed, not accuracy in actually rendering the contet? 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.

      Wake up mods, that's a -1 Offtopic comment.

      • This is not a particlarly fast machine, an Athlon 1400 I think,...

        *sigh*

        I must be getting old; until I read your comment, it didn't occur to me that my Pentium-III 550, a scant four years old (was not willing to spring for the 650) was anything less than blinding in its speed (hey, after a 486-66, it is!). So, just how often am I supposed to replace my machine to keep it reasonable?

  • KHTML developers (Score:5, Insightful)

    by chennes (263526) on Tuesday January 14, 2003 @02:52PM (#5082383) Homepage
    ...and if Apple had chosen Mozilla's engine, the KHTML developers would have been "hurt." KHTML is a compact code by comparison - far easier for Apple to take and modify. What happened to the idea that choice is good? Apple is helping to turn KHTML into a more viable choice (I used Mozilla exclusively before Safari was release- I had never touched KHTML). Now there are a whole bunch of viable browsers out there. Chris
  • by arakon (97351) on Tuesday January 14, 2003 @02:52PM (#5082384) Homepage
    I mean come on, look at Apple's choices,

    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....
  • by Garridan (597129) on Tuesday January 14, 2003 @02:52PM (#5082387)
    Competition in the Open Source world? Microsoft gripes about not owning 100% of the market, too, guys. Competing projects are good. They promote diversity, and since we're all Open Source people, and we all use the same open protocols, its all interoperable.

    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)

    by mkoz (323688) on Tuesday January 14, 2003 @02:53PM (#5082390)
    I understand that mozilla might have some hurt feelings, but lets focus. Apple had specific needs and they chose what they thought was the best solution. Mozilla is doing something a bit different (multiplatform).

    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)

      by MacAndrew (463832) on Tuesday January 14, 2003 @04:02PM (#5082650) Homepage
      4. Chimera (Mozilla based) is still a better browser than Safari on MacOS X.

      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....
      • Re:Chimera, yes (Score:3, Insightful)

        by ink (4325)
        Chimera's a lot more Aqua than Safari, too! I think Safari is stunningly ugly for an Apple product.

        Yeah, Safari looks like a bad gtk app after the themers first discovered pixmap skins. I've crashed it quite a few times, and seen many rendering errors with it (even on simple pages; Google was all rendered on the left side of the window once, instead of being properly centered). It is very fast on my iBook/500, though, and I'm sure it'll get better with time.

        But, for now, Chimera is my browser of choice for OSX. I don't want another ugly metal-brushed app, but if Apple works the bugs out and keeps it as fast as it is now, I'll "switch".

  • by feelafel (228034) on Tuesday January 14, 2003 @02:53PM (#5082391) Homepage
    It should be noted that Mike Shaver's (formerly of Netscape, still of Mozilla) comments [off.net] were, as he points out [0xdeadbeef.com], taken horribly out of context in the ZDNet article.
  • Why hate KHTML? (Score:5, Insightful)

    by dtype (98103) on Tuesday January 14, 2003 @02:53PM (#5082392) Homepage
    I question not so much the free software crowd's love of Mozilla, as the hate for KHTML. Why hate this _other_ free and excellent library for web rendering?

    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?
    • Re:Why hate KHTML? (Score:3, Interesting)

      by fucksl4shd0t (630000)

      I question not so much the free software crowd's love of Mozilla, as the hate for KHTML. Why hate this _other_ free and excellent library for web rendering?

      I don't hate KHTML, I should point out.

      I use KDE 3 on my box, and I use Mozilla as my browser, because Konqueror is a piece of shit. I would use IE before Konqueror, if technical capability was my first priority (it's not, so never fear, I'd use Konqueror). I DO use Konqeror from time to time. For example, when I read email in Kmail, I can either copy a link to the clipboard and paste it in mozilla or I can just click it and see the link in konqueror. I usually click it and see the link in Konqueror, becuase Konqueror loads a lot faster. After they start running, I find Konqueror "feels" slow, although I haven't exactly done any benchmarking.

      Suffice it to say, using both Mozilla and Konqueror side by side in KDE3, I find Mozilla to be a superior browser.

      If Apple can make Konqueror better, then I would prefer to use Konqueror over Mozilla, just because it's well-integrated into my desktop of choice. Obviously, as much as I dislike Konqueror, I like KDE.

      What exactly did Apple do wrong again?

      Maybe they should've called it GNU/Safari? Seriously, I don't think they've done anything wrong.

      I'd also like to point out as a Mozilla embedder that Mozilla hasn't exactly become cross-platform in the way that I'd define it. When you embed Mozilla on a UNIX platform, you have to link to GTK, because you have to pass a GTK widget to the rendering engine. This is not cross-platform, in my opinion. SUre, it works great on Windows, but you have to give it a HWND there, and there are other toolkits besides the winAPI. (Admittedly you should use the winAPI on Windows, the reason is self-evident) But how can I make a native Qt-based Mozilla if I have to link to GTK? Simple, I can't. With all the other cross-platform toolkits available for UNIX (and for Linux, of course) then it seems like Mozilla has ignored the others in favor of their own favorite widget set.

      IMHO, instead of taking a widget pointer, they should take a rectangle of some sort instead, and let the embedder embed it first into their library, and THEN into their application. They could still provide handlers for winAPI and for GTK if they prefer, but those of us who want to use different toolkits under UNIX could embed Mozilla into our preferred toolkit without having to link to GTK.

  • by michaelggreer (612022) on Tuesday January 14, 2003 @02:54PM (#5082400)
    They don't care about portability, since they are a single platform. Thus, Gecko's advantages there offered nothing. They explained their choice in terms of speed and the size and structure of the code. Probably part of the issue was whether they felt they could dive in and code away immediately. Mozilla, arguably, is a little large for that.
  • by tshak (173364) on Tuesday January 14, 2003 @02:54PM (#5082406) Homepage
    I'm sorry, but there's a reason why I personally stick with Opera and IE (IE for IE "only" pages, and for /. just for the irony) and why I'm willing to _pay_ for well made software. Mozilla hurt Mozilla by being too little (or too much when viewing the codebase!) too late. Mozilla based browsers have improved dramatically, but IMHO they are still sub-par. Although Safari has some missing features, for an initial release it looks very promising. From what I've seen, if I ever get a Mac I may be very tempted to use Safari over Opera. Of course, Opera should then sue Apple for levereging their monopoly on PowerPC desktops and pushing Opera out of their market :-).
  • by peatbakke (52079) <peat.peat@org> on Tuesday January 14, 2003 @02:54PM (#5082408) Homepage
    .. is that you get to choose which product best suits your needs. Unfortunately, that also means that someone doesn't get picked. Get over it, and make a better product. Maybe you'll get picked the next time around.
  • Hey guys... (Score:5, Insightful)

    by BJH (11355) on Tuesday January 14, 2003 @02:55PM (#5082412)
    ...you got the title wrong. It should read:

    "ZDNet trolls for more page hits yet again - film at 11."
  • by smagoun (546733) on Tuesday January 14, 2003 @02:55PM (#5082414) Homepage
    The article doesn't say the Mozilla developers were hurt! It says they either a) agree with Apple or b) don't care. For example:

    One Mozilla staff member called KHTML selection an understandable if not foregone conclusion, given Mozilla's technical problems.
    and
    "I guess I'm supposed to be mortally offended--or at least embarrassed--that they went with KHTML instead of our Gecko engine, but I'm having trouble working up the indignation," wrote Mike Shaver in a Web log posting. "We've all known forever that Gecko missed its 'small-and-lean' target by an area code, and we've been slogging back towards the goal, dragging our profilers and benchmarks behind us, for years."

    Apple hurt Mozilla? The only thing that hurt Mozilla was Mozilla. And for the most part, the Mozilla developers know that already.

    "Editors," indeed.

  • by Augusto (12068) on Tuesday January 14, 2003 @02:55PM (#5082416) Homepage
    I was a bit surprised Apple developed a browser, and with Open Source code, but when I read it wasn't using Gecko I was even more surprised.

    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!
  • by mkoz (323688) on Tuesday January 14, 2003 @02:56PM (#5082420)
    http://linuxjournal.com/article.php?sid=6565
  • Why KHTML? (Score:3, Insightful)

    by artemis67 (93453) on Tuesday January 14, 2003 @02:58PM (#5082435)
    Apple was probably enticed by the fact that it is a smaller codebase, and thus giving Apple more "ownership" (in the creative sense) of the project.

    Mozilla is a lot more mature, feature-wise, and Apple was probably looking for a clean slate. They just want a stripped-down rendering engine, and the interface is all theirs.
  • by FyRE666 (263011) on Tuesday January 14, 2003 @02:58PM (#5082442) Homepage
    Much as I admire the Mozilla project, the guys behind Konqueror deserve much more recognition than they seem to recieve (at least on /., where it's all Mozilla,Mozilla,Mozilla). They're a much smaller group of developers who have put together a great browser for KDE, so why the hell shouldn't they have a success story of their own?!
  • Fp! (Score:5, Funny)

    by ryanvm (247662) on Tuesday January 14, 2003 @03:00PM (#5082454)
    Damn, I would have had first post if I wasn't using Mozilla.
  • Good for Apple (Score:5, Insightful)

    by frovingslosh (582462) on Tuesday January 14, 2003 @03:01PM (#5082463)
    I doubt that I've ever had anything good to say about Apple before, but good for them for this move, and I think in the long run it will be the best thing for Mozilla too. By bringing another browser to the arena, and one that seriously challanges IE even more than Mozilla, it can only help Mozilla by reducing IE's monopoly hold. And giving Mozilla some performance targets to shoot for will not be a bad thing either.
  • Safari lacks tabs (Score:3, Insightful)

    by Toe, The (545098) on Tuesday January 14, 2003 @03:01PM (#5082469)
    Windows users are used to seeing all open windows in the startbar (or whatever you call it). Mac OS X users now have the lovely dock, but it shows running apps and minimized windows... not all windows.

    So Mac users are especially prone to want tabbed browsing, as Mozilla products offer.

    I started using Chimera a few days before Safari beta was released. I really like Safari, but in just those few days I was utterly hooked by the tabs of Chimera.

    Until Safari supports tabs, I'm sticking with Chimera. I doubt I'm alone.


    One thing to note, though... ALL Mac browsers now kick Microsoft's ass. Bye, bye IE-piece-of-crap. In any event, it is an awesome twist to see the Mac browser market so vitalized.

  • by Anonymous Coward on Tuesday January 14, 2003 @03:07PM (#5082502)
    This very informative rant was on David Hyatt (Safari developer)'s weblog [mozillazine.org] on Saturday for a few minutes, but he removed it for unknown reasons. I saved a copy:
    Quoted from the original mail to the KDE folks:
    The number one goal for developing Safari was to create the fastest web browser on Mac OS X. When we were evaluating technologies over a year ago, KHTML and KJS stood out. Not only were they the basis of an excellent modern and standards compliant web browser, they were also less than 140,000 lines of code. The size of your code and ease of development within that code made it a better choice for us than other open source projects. Your clean design was also a plus. And the small size of your code is a significant reason for our winning startup performance as you can see reflected in the data at http://www.apple.com/safari/.
    Mike Shaver writes in his blog:
    This whole Safari thing is a source of deep entertainment to me. I guess I'm supposed to be mortally offended ? or at least embarrassed ? that they went with KHTML instead of our Gecko engine, but I'm having trouble working up the indignation. We've all known forever that Gecko missed its "small and lean" target by an area code, and we've been slogging back towards the goal, dragging our profilers and benchmarks behind us, for years. If I had to write a new browser, and I was going to have to touch the layout code in a serious way, I would think about Mozilla alternatives. I think it's awesome that they pretty much have to compare Safari to Chimera and Netscape/Mozilla, because it shows how far we've come from the universal acceptance of IE's hegemony. I think it's fantastic that they chose to include "Gecko" in their user-agent, so that they could get standards-compliant content, because it means that our evangelism efforts in support of such content have been working. I'm thrilled that they're going to be another IE-alternative browser, which will try some techniques Mozilla decided against, because we can see if it really works or not. And I really really hope that Mozilla will learn from Safari/KHTML, because they've done a lot of great work in about a tenth of the code. Kudos, guys, and welcome to the web.

    David Baron writes:

    Why is Mozilla's layout engine so big and complex? Perhaps the simple answer is that there were too many people available to write it, and they wrote as much code as they could. After all, they didn't have any incentives to keep the code small.

    But what, in detail, is wrong? (Now I'm just speaking of the code in mozilla/layout, which is one of the pieces code I work on, and by far the most discouraging one for a company coming along and thinking of building a web browser based on Mozilla's layout engine.)
    I think some of the people who wrote the code didn't understand the specifications that they were implementing. Part of the problem may lie in the specifications themselves. For example, there's almost no information in CSS2 describing shrink wrapping. Might being an afterthought explain why Mozilla's layout engine has shrink wrapping code scattered throughout it in a disorganized fashion? Even lately I've watched some developers want to make incorrect changes in behavior or fail to understand the reason that another browser lays a page out differently.

    I think part of the problem may have been a desire to make everything modular so that it could be split up between different programmers. In the end, there were just too many pieces. (Could this be a problem of too many design documents?)

    There's overoptimization in certain areas. For example, our rendering object structures are extremely optimized for size at the cost of code complexity, and, to some degree, performance. However, our content tree structures are larger and the code is simpler. From what I understand about khtml, it has much smaller content tree structures (with the DOM using tearoffs), while its rendering objects (what Mozilla calls frames for some confusing reason) are much larger, allowing for simpler code.

    There's been an inability to focus on more than one or two things at the same time. In 1998-1999, there was a focus on standards compliance. In 2000-2002, there was a focus on making real web sites work. In 2001 there was a focus on performance. Now (late 2002/early 2003) there's a focus on memory use. In many of these cases, working on one objective can hurt another one, and I think we've often failed to balance them appropriately.

    (The real solution to cleaning up layout probably involves making layout objects use twice the amount of memory that they currently do. Is that a problem? I don't think so, since they take up so little of the total. We're better off increasing the amount of memory that frames use and attacking memory use in other areas. If I do this, will I be told that I have to fix the memory use regression in 72 hours or back out the changes? I hope not.)

    In the end, khtml's code is a lot simpler. Perhaps more importantly, the code looks a lot more like a description of the way the layout process works. After hearing a short explanation of what's what, I can understand some of khtml's code almost as well as the equivalent code in Mozilla.

    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.

    • If you're going to also selectively quote Shaver like that, I guess I should fill in the rest:

      Last I wanted to respond to some of the criticisms that are levied at Mozilla in that article and in people's blogs as of late. When I hear quotes like:

      "When we were evaluating technologies over a year ago, KHTML and KJS stood out," Safari Engineering Manager Don Melton wrote. (KJS is KDE's JavaScript interpreter.) "Not only were they the basis of an excellent, modern and standards-compliant Web browser, they were also less than 140,000 lines of code. The size of your code and ease of development within that code made it a better choice for us than other open-source projects."

      it really gives me pause. They are talking about Mozilla from over a year ago. They are talking about a pre-1.0 Mozilla release. Mozilla has gotten a lot better since that evaluation, especially in the form of the Chimera project for OSX, which has grown in leaps and bounds over the last few months. It's like comparing a modern sedan with your 1976 Ford Pinto. Of course, it's going to look better and drive better, it's newer. We're not your mother's Pinto anymore.

      Now, is our layout engine huge and ungainly and hard to understand? Yes. Yes it is. And, at least to some degree it's important to understand that Mozilla's layout engine has warts because the web has warts. It's an imperfect place and that leads to imperfect code. Remember that while KHTML is a good bit smaller than our layout engine, it also doesn't render a lot of sites anywhere near as well as Mozilla does. Over time, they are going to have to add many of the same warts to KHTML as we have to our layout engine. They might be able to do so in a more clean way, but they will still be there.

      Second, Mozilla's layout engine does so much more than what KHTML is trying to do. We're rendering our entire application with it so of course it's going to be bigger. Can we do better with our layout engine in the future? Yep. Will we? Yes, I think that we will. There's lots of interest in cleaning up the mess of layout.

      In any case, I welcome Apple's entry into the web browser field, even if it isn't using the software that I think is best suited for the job. They can only make the web a better place. Unless they screw up, of course.

      • "If you're going to also selectively quote Shaver like that, I guess I should fill in the rest ..."

        In fairness, nowhere in there does Shaver refute the contention that Gecko is basically unsuited to Apple's requirements, which pretty clearly were fast startup and rendering, followed by correctness.

        'jfb
  • Monolithic app (Score:3, Interesting)

    by Malc (1751) on Tuesday January 14, 2003 @03:08PM (#5082503)
    It sounds like the size of the Mozilla code base was part of the problem. It has frustrated me since the beginning.

    I would love to hear an explanation about why the Mozilla team chose to build a single monolithic app. This was supposed to be complete re-write (hence no Netscape/Mozilla 5), so why did they chose to follow an obviously flawed approach used by Netscape?

    It's frustrating: a crash in one component brings down several essentially different applications. I like most of the components that ship with Mozilla, but I hate having them all in one process. Separation of these components would have both increased reliability of the suite, plus reduced load times and demands on system resources. I like to keep my mail app running all the time, but I can't do this with Mozilla due to an annoying resource bug it has that causes it to blue screen my computer after a few hours in my nVidia display drivers (it is the only app I have that causes this problem). I can't close the browser but keep mail/news open :(

    Heh: I was just thinking the other day how nice it would be to have the configuration and profile management running in a separate process that could be run as a service/daemon and available to all components at all times. This would also improve load times! MSFT benefits from things like this for example with their Protected Storage service, which I believe popped up with IE4.

    BTW, posted by Mozilla under Win2K. My full time browser for over a year.
  • by jfedor (27894) <jfedor@jfedor.org> on Tuesday January 14, 2003 @03:08PM (#5082505) Homepage
    The article says:
    In a
    Web log [livejournal.com], Mozilla founder and former evangelist Jamie Zawinski said Apple is bad-mouthing Mozilla.
    Ummm... Actually, the title of his post was 'Apple says "fuck you" to Mozilla'. :)

    -jfedor
  • by Dante (3418) on Tuesday January 14, 2003 @03:09PM (#5082510) Journal

    Other Lizard Wranglers that deserve a voice in this. To be honest these guys are the ones I listen to when it comes to Mozilla.
    alsa [mozillazine.org]
    Blizzard [0xdeadbeef.com]
    mpt [phrasewise.com]

    Why should JWZ [jwz.org] be quoted about a project he bailed on years ago? jwz is entertaining when he whines, it's the only reason I can think of.

  • by jamienk (62492) on Tuesday January 14, 2003 @03:11PM (#5082518)
    Free Software has again helpped a proprietary company. But maybe this will be good for Freedom, ultimately, as more companies realize that they can benefit when "their" software is Free.

    The fact that KHTML is Free software let Apple quickly and easily break free from a hold that MS had them in. They tried bundling the OmniWeb browser, but that was clearly inferior to MS IE...

    Right now Apple is tripping over themselves to get AppleWorks good enough to replace the need for MS Office. Maybe Open Office will soon help here (Apple has focused on making X11 apps more seemlessly integrated with OSX).

    If Apple, Dell, HP, etc, collaborated with Free Software projects more, they could remove the need for users to get certain software from MS. That, in turn, would allow them to chart their own paths in terms of their wares and give them the opportunity to team up with others who are threatened by MS.

    Soon, Apple will turn to FreeSoftware for Ogg code.

    Apple's costs for distributing their free (beer) value-add-software packages are making them consider (and actually) charge for their "i" crap. (see http://www.thinksecret.com/news/freeiapps.html) FreeNet would go a long way to help them spread out their bandwidth. If only they gave us the right to redistribute their code. And hell, why not let us improve the code too, and give it away for free.
  • by WhaDaYaKnow (563683) on Tuesday January 14, 2003 @03:11PM (#5082520)
    "Translated through a de-weaselizer, (Melton's e-mail) says: 'Even though some of us used to work on Mozilla, we have to admit that the Mozilla code is a gigantic, bloated mess, not to mention slow, and with an internal API so flamboyantly baroque that frankly we can't even comprehend where to begin,'" Zawinski wrote.

    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.
  • by alanjstr (131045) on Tuesday January 14, 2003 @03:11PM (#5082521) Homepage
    There has been a lengthy discussion on MozillaZine here [mozillazine.org]
  • by Francis Avila (603590) on Tuesday January 14, 2003 @03:12PM (#5082522)
    It seems that Apple's problem was more that there was more stripping that needed to be done with Gecko before they got down to the foundation and could start building their own browser. This seems to be a common concern, that Mozilla includes too much stuff to be very useful as a working base, and thus the popularity of things such as Phoenix, whose sole goal is to remove features from Mozilla.

    If this is indeed the case, perhaps Gecko would benefit from being packaged and maintained separately from Mozilla, as a rendering engine but not a browser. In other words, something only useful for application developers. Even conceptually, rendering HTML != browser. Suppose you're rendering to postscript, for example? This might even benefit Mozilla, buy keeping the project more modular. (Although it's pretty modular already, but not down to the core.)

    The above is spoken with next to no knowledge of the intricacies of the Mozilla codebase, so flame gently.
  • Good for Standards (Score:5, Insightful)

    by farnsworth (558449) on Tuesday January 14, 2003 @03:14PM (#5082534)
    Apple using a different engine is good for the standards. Mozilla didn't set out to be the "most standards compliant" browser so that it could be the "only standards compliant" browser.

    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.

  • by valkraider (611225) on Tuesday January 14, 2003 @03:25PM (#5082587) Journal
    I was a switcher before switching was cool. I have used Mozilla since somewhere in the .9 range. I have used Opera for Windows for a few years. I have used OmniWeb and iCab on Mac.

    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....
  • by farnsworth (558449) on Tuesday January 14, 2003 @03:59PM (#5082630)
    I've been on projects that have been passed up/canceled/driven into the ground, and it doesn't feel good. But, hopefully this will give mozilla developers pause to reconsider some of mozilla's architecture. It's been 5 years and the basic architecture/toolkit has not really changed. Maybe they will ask themselves:

    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.

    • # Why are we using xpcom considering the huge bloat/threading issues on non-win32?

      Because XPCOM allows plugins to have some semblance of binary compatability, and because it enables XPConnect which makes it trivial to create cross platform UIs. Note that the large amount of code written in XUL/JavaScript is very easy to hack, a lot of contributors to Mozilla started this way. The development time costs were probably worth it alone.

      Why do the signatures on our api make almost no sense to outsiders?

      Signatures? If you mean function prototypes, they are fairly self explanatory usually. Anybody with a good grasp of C++ who wants to understand them can find out what the portable typing system is.

      # Why do we compare our performance almost exclusively to IE?

      Because Gecko is feature-comparable to IE (Trident) and KHTML isn't? Also remember that nobody uses Konq and everybody uses IE from a statistical viewpoint.

      # If Apple wont use our code because it's too big, do we have any real chance of being used on small devices?

      I dunno if they really target very small devices any more. For starters, very small devices probably aren't going to need fully featured web browsers anyway.

      Why are we still using xul now that we ifdef [hixie.ch] out platform-specific ui code?

      Well, that link goes to a simple preprocessing tool, it doesn't make any mention of XUL I can see. And more to the point, XUL is an abstraction system so if anything removing platform-specific code would make sense. Of course Moz does use some platform specific code, like common dialog boxes.

      Using XUL makes a lot of sense btw. Other than Qt which is only free software on X11 platforms, there weren't really any good C++ cross platform toolkits back then. The nearest is wxWindows which wasn't anywhere near as well developed as it is now, and still isn't really up to the quality needed of Mozilla from what I've heard (not used it myself, might be wrong).

      The choice was simple - either XUL or Windows only.

      Mozilla is complex at points, the use of XPCOM in all parts of the app was a mistake (which is now being rectified in de-comtamination, ho ho), but that's because the web is a complex thing. I think people malign Gecko too much really...

  • by infolib (618234) on Tuesday January 14, 2003 @04:03PM (#5082668)
    here [kde.org]

    Snippets:
    Jobs said the browser was "based on standards", "works with any Web site", has much-improved performance over IE (page-loading speed is "three times faster", JavaScript performs twice as fast and it launches "40% faster" - comparisons to Netscape 7.0 shows similar performance gains on the Macintosh platform)

    Apple [...] has today sent all changes, along with a detailed changelog, to the KHTML developers.

    Also:
    Mail from Safari team to KHTML devs [kde.org]
    and Dirk Muellers response [kde.org]

    -- With more than 200 comments this is apparently a big thing to the KDE community
  • Why is this bad? (Score:3, Interesting)

    by Frag-A-Muffin (5490) on Tuesday January 14, 2003 @04:08PM (#5082717) Homepage
    The way I see it. The more browsers out there the better. The battle is not what engine gets used, but rather, having enough browsers out there that *aren't* IE so that the stupid web designers would get off their lazy asses and author HTML properly (ie. follow the W3C recommendations? Duh? Isn't that what they're there for?) So that EVERYONE! can view their pages! No more 'IE only' crappy pages. That's my hope anyways.

    PS Yeah, I know. Long run-on sentance. What can you do? :)
  • by Elwood P Dowd (16933) <judgmentalist@gmail.com> on Tuesday January 14, 2003 @04:16PM (#5082808) Journal
    OK! Gecko supports more standards! Gecko is fast (enough)! Gecko is portable!

    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.
  • by Ender Ryan (79406) on Tuesday January 14, 2003 @04:27PM (#5082898) Journal
    If people really read the article, and then read the original comments, they'd see that the moz developers weren't "hurt" by Apple's decision. Quite the contrary. They're happy to see another standards compliant browser.

    This is really, really interesting to see this though. 2 years ago some people were getting worried that alternative OS users would be unable to browse the web by this time, but today we've got 2 OS standards compliant rendering that beat the pants off IE in speed, correctness, and to top it off, cost.

    And despite the technical problems with Mozilla, people are still able to crank out excellent, lean, fast browsers such as Chimera and Phoenix, and other applications for embedded devices, etc.

    Mozilla has become a platform, and KHTML has become the lean, fast rendering engine Mozilla was originally going to be.

    Cheers

  • Stop Whining!! (Score:4, Insightful)

    by extrarice (212683) on Tuesday January 14, 2003 @04:28PM (#5082904) Homepage Journal
    Yes, this will be flamebait. Mod me down, I don't care. I'm at the bottom of the rung anyway.

    QUIT YER WHINING!! Stop crying foul, and focus on your project! So Apple decided to use kHTML as the rendering engine instead of Gecko. So what? How does that impact the Mozilla project? Make it better than Safari! I'm sorry that the decision injured your geek pride, but if you cry foul every time a company doesn't use your sacred works, then you get destracted from the mission of finishing the product.

    Short version: FOCUS ON THE JOB!!
  • by Kiwi (5214) on Tuesday January 14, 2003 @04:44PM (#5083048) Homepage Journal
    One thing I would like ot bring up is that, in my experience, khtml handles some lousy dhtml sites better. While I much prefer Mozilla most of the time (more features, and, most importantly, more stable than konqueror), there are certain sites with loust DHTML which Mozilla will plain simply not render. Konqueror seems to better render sites which were only tested with Microsoft IE.

    In fact, the college I go to uses, for its on-line registration, such a site; this site refuses to allow me to sign on for on-line classes in Mozilla. However, Konqueror can render the page well enough so that I don't have to get on the phone to add classes or view my schedule.

    As an aside, the team which designed the web page were very incompetent (to give credit where credit is due, Unisys [burnallgifs.org] was one of the companies doing the contracting; other parties responsible for this fiasco will not be named because no one else responsible has attacked the free software movement). These same people also destroyed the computer database of students who were to receive financial aid when transferring it to the new system, forcing each and every student who wanted finanacial aid to completely resubmit any and all paperwork.

    - Sam

  • by reallocate (142797) on Tuesday January 14, 2003 @04:59PM (#5083157)
    I dumped Mozilla on OSX for Chimera, and I was happy. Last week, I dumped Chimera for Safari, and I'm happier.

    I only use one platform at a time. While I'm waiting for Mozilla to do something, should I find solace in its cross-platform abilities?

    Cross-platform code maymake life simpler for coders, but what does it bring to the user?
  • by alanjstr (131045) on Tuesday January 14, 2003 @05:17PM (#5083271) Homepage
    Hyatt works on Mozilla, Phoenix and Safari (he's an Apple employee).

    Here is his blog [mozillazine.org] which talks about it.

  • by Animats (122034) on Tuesday January 14, 2003 @06:29PM (#5083744) Homepage
    This makes sense from Apple's perspective. They need a browser, not another API. Apple has enough APIs already.

    Now Apple has a reason to push the HTML tool vendors into being more standards-compliant. The IE-specific crap has got to go.

    One browser is tyranny. Two browsers is war. Many browsers are freedom

  • by Anonymous Coward on Tuesday January 14, 2003 @10:00PM (#5085017)
    Lets see:

    Chimera: A fantastic, impracticable plan or desire: bubble, castle in the air, dream, fantasy, illusion, pipe dream, rainbow.

    Dave Hyatt (for I think it was he, forgive me if I am wrong) said that Chimera was named thus because of the the UNHOLY alliance between the gecko codebase, and Mac OS Xs' Cocoa, object frameworks.

    The fact is, and the Mozilla team will agree, that Gecko is a hopelessly over-engineered piece of technology (a little like Quartz). It wasn't built to be 'cross-platform', it was built to be THE platform and with this in mind the engineers of it have turned it into an overcomplicated device.

    This does not deny that geko is a fine machine, it is complete, fast and effective.. BUT it is fat, and messy.

    When OmniGroup decided to adopt the JS engine from the Mozilla project, they found they had bit off an awful lot to chew.. saying that great areas of it were un-threadsafe and integrating it with OSXs' object frameworks was a nightmare.

    Contrast with KHTML.. it is extremely lightweight (if far less complete than Gecko) is more modular and it's hooks outward to the host are more prevelant (Gecko wants to BE the platform remember)

    I had no Idea Apple would do this, and was suprised when they used KHTML, but that is probably because I knew little of it.. in fact talk of Apple working on a browser worried me.. because I assumed they would try to use Gecko.. it would have been like banging a square peg into a round hole had they tried to do it.

    I'm not taking away from Chimera, they gave the Mac community something great, but look at it.. it's integration with Aqua is roughshod and bizarre, it never 'feels' right.. now look at what Apple have done with KHTML.. it is natural, looks right (like OmniWeb) and works like a dream.

    Safari has a -long- way to go, and the bloat will occur (that last 20% of standards to support will add another 50% of code, I'll bet) but now It is, far and away the benchmark in OSX browsing, and I feel it will be for some time.
  • by gotan (60103) on Tuesday January 14, 2003 @10:59PM (#5085300) Homepage
    It is important to consider when they had to decide which codebase to choose. Over a year ago means mozilla version less than .9.8, and while that version was already usable it was very obvious that it still needed a lot of work. I don't know the state KHTML was in at that time, but its main advantage is the smaller codebase. It's a very sound decision to keep the project overseeable and manageable. Had they used the mozilla-code they'd had to invest much more into the development, they might still depend on (parts of) the mozilla development, and it'd probably have taken much longer. The benefits of using the mozilla-codebase don't outweigh these costs considering that all apple wanted was a standalone-browser.

    Over all the ruckus about HTML vs. mozilla aparently nobody noticed that Apple based their browser on an open source project and decided against doing it closed-source on their own. I think that's great news.

FORTRAN is a good example of a language which is easier to parse using ad hoc techniques. -- D. Gries [What's good about it? Ed.]

Working...