5 ms·

Why was that a good decision?

• tptacek 15y ago
  Because WebKit is such an obviously successful project, is what I read out of that.
  • azakai 15y ago
    Both WebKit and Gecko are obviously successful, so it isn't clear that Apple's choice was better than the other option at the time. We do know that this choice turned out very well for Apple, but we don't know if things could have turned out better otherwise if Apple had picked Gecko. For that matter, we don't know if things wouldn't have turned out better for Apple if it had started from scratch. For one thing, doing so would have avoided KHTML's LGPL license, which requires source code to be shared. That would have allowed Apple to make its web engine closed source or entirely BSD, which could have led to very different results than how things unfolded. Better or worse, it is very hard to say. Edit: I'm curious, why the downmod?
    • tptacek 15y ago
      At a glance, it looks like Webkit is more successful than Gecko, simply because it powers more browsers and because Gecko has virtually no footprint in mobile browsing. We can obviously go round-and-round all day on which is the better engine. I'm only saying that Webkit was a successful project for Apple. I'm not sure how productive it is to second-guess it. (I didn't downvote you).
      • azakai 15y ago
        I agree entirely, there is not much point in second guessing Apple. Their decision worked out very well for them. Safari is an excellent browser and WebKit is an excellent browser engine. I do think though that the KHTML/Gecko thing is a pointless debate. For one thing, both are very good, so I'm not sure what there is to argue. But the real issue is KHTML/Gecko is a false dichotomy: Apple has huge resources and amazing engineering talent, so it could have written a new browser engine from scratch, and I'm pretty sure that browser engine would have been awesome. And, doing so would have given Apple complete freedom to pick the project's license, either more closed than KHTML's LGPL license (even entirely closed source, like most of OS X), or more permissive (even BSD, like Apple prefers in its open source projects). There are a lot of interesting possibilities there, that we can only speculate about. So again, I agree second guessing is pointless. But it just seems like debating KHTML/Gecko is even more pointless, given the other options Apple had.
        • chc 15y ago
          I recall someone from Apple (I want to say David Hyatt) actually explained why they went the way they did. They looked at assimilating Gecko, but it was just too large to mold into the product they wanted without essentially throwing out most of the existing product. But still, starting from scratch would have ballooned the budget since a Web browser is a nontrivial undertaking†. KHTML was a happy medium — it was a solid, functional base, but it wasn't yet overwhelming for the Safari team. † Think about it. HTML rendering engines are probably the most-used piece of software around these days, and yet in the almost 20 years since the Web came about, there have only been about 10 notable rendering engines written for it, of which only three have had real commercial viability (Gecko, Trident and WebKit).
          • azakai 15y ago
            It does make sense that KHTML was a compromise for Apple as you say. It's interesting that that was the motivation there, thanks for sharing that! About Opera, a comment: Opera definitely has real commercial viability. Unlike the other three you mention, Opera has had to be profitable all its life, and from the Opera browser itself (not subsidized by other products). Today Opera makes a lot of money from its mobile browser (but it is in danger from WebKit now).
            • chc 15y ago
              You're right, that isn't fair to Opera. I honestly just forgot about them when I was writing the postscript. Thanks for the reminder.