5 ms·

I guess you ignored the part where I said except mobile obv. My biggest issue with webkit is that there was a perfectly fine rendering engine to begin with tha

by wdewind 16y ago

I guess you ignored the part where I said except mobile obv. My biggest issue with webkit is that there was a perfectly fine rendering engine to begin with that both Safari and Chrome could've simply built a new UI around. Instead they gave us yet another OS to support. Web developers complain all the time about supporting multiple browsers, yet support web kit? And for the record, steam is a great example of what I'm talking about: completely mediocre rendering performance for really simple tasks (essentially a web browser). It's shocking how bad web content looks in steam, I'm kind of surprised you even brought it up. Yes - Webkit long term will be good, it can't not (even IE9 is looking alright at this point). Right now though (ruling out IE6), > 50% of my web dev cross browser issues are dealing with web kit, not IE7+, and for a much less significant audience (ie: expensive). So you're right, it's not a "fail," but I think how great the response is to it is really disproportional. I REALLY want to love chrome etc but I just can't - it's not ready yet.

naz 16y ago
> My biggest issue with webkit is that there was a perfectly fine rendering engine to begin with that both Safari and Chrome could've simply built a new UI around. You're right, there was. It was called KHTML, and they did.
- wdewind 16y ago
  http://en.wikipedia.org/wiki/Gecko_%28layout_engine%29 http://en.wikipedia.org/wiki/Gecko_%28layout_engine%29 Not that it really matters for the sake of the argument, because my point was that gecko was widely used already whereas KHTML was not and so they should've used it instead, but gecko was also around before KHTML.
  - othermaciej 16y ago
    It's not likely we would have had the same success on mobile if we'd started with Gecko, since at least at the time it was a much larger code base.
  - pyre 16y ago
    When Apple announced that they were going to use KHTML in Safari (when they announced Safari) they stated that it was due to the library's small footprint. I assume that they didn't want to spend the time to reign in the Gecko engine to do what they wanted it to do (or hack/optimize it down to size). Just because something exists and seems to be 'good enough' doesn't necessarily mean that it would be a good fit. Unless you develop for WebKit, Safari, Firefox and/or Gecko, I'm not sure any of us are really qualified to make those kinds of statements. Also remember that you can't compare the current state of the two codebases. You have to compare the state of the codebases at the time that Apple created Safari/WebKit.
    - wdewind 16y ago
      Agree to disagree, but I hope you don't complain about browser fragmentation.
  - mpyne 16y ago
    > but gecko was also around before KHTML. Actually, KHTML pre-dates even Gecko, given that it descended from the "KDE HTML Widget" KHTMLW. Even in 1997 this library was being developed (example email: http://marc.info/?l=kde-devel&m=88665877914652&w=3 http://marc.info/?l=kde-devel&m=88665877914652&w=3) By 2002 or whenever Gecko was more widely used than KHTML but that doesn't really matter because it was harder to integrate into Apple's code. Apple even had to go so far as to write a KDE/Qt wrapper layer (KWQ IIRC) and it was still less work than integrating/fixing Gecko. As another example, the lead Safari dev, David Hyatt is famous for (among other things) co-starting the Firefox project (called Phoenix at the time) so it is a very large stretch to claim that Apple simply ignored the better choice. Hyatt would have to go way out of his comfort zone to adopt something other than Gecko, and the fact that he did so anyways should say something...
  - blasdel 16y ago
    Do you know who Dave Hyatt is? He invented XUL, contributed to Gecko, wrote the initial version of Chimera (now Camino, one of the first real embeddings of Gecko), started the Firefox project, and started WebKit He had a pretty fucking good idea of the pros and cons of Gecko when he decided not to use it again.
  - masklinn 16y ago
    > Not that it really matters for the sake of the argument, because my point was that gecko was widely used already then maybe you should have said that > whereas KHTML was not and so they should've used it instead That's not really relevant, and Gecko's size and complexity make it a hard sell when you have long-term goals of appliances and embedded. Furthermore entrenched projects and interests means Apple would have had low if any say about the project's orientation, giving up heaps of control. So it made sense for technical, future-proof and business reasons to go with a KHTML fork rather than Gecko. > but gecko was also around before KHTML. That's not even correct.
deleted 16y ago
[deleted]
tiles 16y ago
Gecko is not an HTML rendering engine, it's a Mozilla XUL+HTML rendering engine. It's a legacy codebase and not easily embeddable. XULRunner and other developments are changing that but that still involves XUL. I'd love for a separate pure-HTML Gecko engine that competes with Webkit, but until that happens, there are technical reasons for choosing one or the either.
masklinn 16y ago
> My biggest issue with webkit is that there was a perfectly fine rendering engine to begin with Yes, KHTML. Ooops. > with that both Safari and Chrome could've simply built a new UI around Chrome is a new UI and JS engine tacked to webkit, they didn't create a new rendering engine. > Instead they gave us yet another OS to support. What? > Web developers complain all the time about supporting multiple browsers, yet support web kit? Web developers complain all the time about supporting shitty browsers, not multiple browsers. Since ~Safari 3, webkit-based browsers have been very, very good browsers, often superior to Gecko in terms of rendering quality and JS quality (and perfs). Furthermore, it got very fine dev tools by now, more than on-par with Firebug's in most arenas, to the point where a number of developers have switched to webkit as their main development platform and relegated Firefox to "also checked". Not to mention, webkit-based browsers are the one offering the most new and interesting features for Making Cool Shit Easily (multiple backgrounds for instance). That's something web developers tend to dig. > Right now though (ruling out IE6), > 50% of my web dev cross browser issues are dealing with web kit, not IE7+, and for a much less significant audience (ie: expensive). You are doing it very, very wrong. This simply isn't something I observe. Quite the opposite in fact. A year ago I got into a codebase which had been developed solely on and for Firefox for more than a year (crappers gonna crap), getting it into a useable form for Webkit took a few days, it's still barely useable for IE8 and entirely broken for IE7. > So you're right, it's not a "fail," but I think how great the response is to it is really disproportional. It's not. > I REALLY want to love chrome etc but I just can't - it's not ready yet. Whatever.

by wdewind 16y ago

naz 16y ago

> My biggest issue with webkit is that there was a perfectly fine rendering engine to begin with that both Safari and Chrome could've simply built a new UI around. You're right, there was. It was called KHTML, and they did.

wdewind 16y ago
http://en.wikipedia.org/wiki/Gecko_%28layout_engine%29 http://en.wikipedia.org/wiki/Gecko_%28layout_engine%29 Not that it really matters for the sake of the argument, because my point was that gecko was widely used already whereas KHTML was not and so they should've used it instead, but gecko was also around before KHTML.
- othermaciej 16y ago
  It's not likely we would have had the same success on mobile if we'd started with Gecko, since at least at the time it was a much larger code base.
- pyre 16y ago
  When Apple announced that they were going to use KHTML in Safari (when they announced Safari) they stated that it was due to the library's small footprint. I assume that they didn't want to spend the time to reign in the Gecko engine to do what they wanted it to do (or hack/optimize it down to size). Just because something exists and seems to be 'good enough' doesn't necessarily mean that it would be a good fit. Unless you develop for WebKit, Safari, Firefox and/or Gecko, I'm not sure any of us are really qualified to make those kinds of statements. Also remember that you can't compare the current state of the two codebases. You have to compare the state of the codebases at the time that Apple created Safari/WebKit.
  - wdewind 16y ago
    Agree to disagree, but I hope you don't complain about browser fragmentation.
- mpyne 16y ago
  > but gecko was also around before KHTML. Actually, KHTML pre-dates even Gecko, given that it descended from the "KDE HTML Widget" KHTMLW. Even in 1997 this library was being developed (example email: http://marc.info/?l=kde-devel&m=88665877914652&w=3 http://marc.info/?l=kde-devel&m=88665877914652&w=3) By 2002 or whenever Gecko was more widely used than KHTML but that doesn't really matter because it was harder to integrate into Apple's code. Apple even had to go so far as to write a KDE/Qt wrapper layer (KWQ IIRC) and it was still less work than integrating/fixing Gecko. As another example, the lead Safari dev, David Hyatt is famous for (among other things) co-starting the Firefox project (called Phoenix at the time) so it is a very large stretch to claim that Apple simply ignored the better choice. Hyatt would have to go way out of his comfort zone to adopt something other than Gecko, and the fact that he did so anyways should say something...
- blasdel 16y ago
  Do you know who Dave Hyatt is? He invented XUL, contributed to Gecko, wrote the initial version of Chimera (now Camino, one of the first real embeddings of Gecko), started the Firefox project, and started WebKit He had a pretty fucking good idea of the pros and cons of Gecko when he decided not to use it again.
- masklinn 16y ago
  > Not that it really matters for the sake of the argument, because my point was that gecko was widely used already then maybe you should have said that > whereas KHTML was not and so they should've used it instead That's not really relevant, and Gecko's size and complexity make it a hard sell when you have long-term goals of appliances and embedded. Furthermore entrenched projects and interests means Apple would have had low if any say about the project's orientation, giving up heaps of control. So it made sense for technical, future-proof and business reasons to go with a KHTML fork rather than Gecko. > but gecko was also around before KHTML. That's not even correct.

deleted 16y ago

[deleted]

tiles 16y ago

Gecko is not an HTML rendering engine, it's a Mozilla XUL+HTML rendering engine. It's a legacy codebase and not easily embeddable. XULRunner and other developments are changing that but that still involves XUL. I'd love for a separate pure-HTML Gecko engine that competes with Webkit, but until that happens, there are technical reasons for choosing one or the either.

masklinn 16y ago

> My biggest issue with webkit is that there was a perfectly fine rendering engine to begin with Yes, KHTML. Ooops. > with that both Safari and Chrome could've simply built a new UI around Chrome is a new UI and JS engine tacked to webkit, they didn't create a new rendering engine. > Instead they gave us yet another OS to support. What? > Web developers complain all the time about supporting multiple browsers, yet support web kit? Web developers complain all the time about supporting shitty browsers, not multiple browsers. Since ~Safari 3, webkit-based browsers have been very, very good browsers, often superior to Gecko in terms of rendering quality and JS quality (and perfs). Furthermore, it got very fine dev tools by now, more than on-par with Firebug's in most arenas, to the point where a number of developers have switched to webkit as their main development platform and relegated Firefox to "also checked". Not to mention, webkit-based browsers are the one offering the most new and interesting features for Making Cool Shit Easily (multiple backgrounds for instance). That's something web developers tend to dig. > Right now though (ruling out IE6), > 50% of my web dev cross browser issues are dealing with web kit, not IE7+, and for a much less significant audience (ie: expensive). You are doing it very, very wrong. This simply isn't something I observe. Quite the opposite in fact. A year ago I got into a codebase which had been developed solely on and for Firefox for more than a year (crappers gonna crap), getting it into a useable form for Webkit took a few days, it's still barely useable for IE8 and entirely broken for IE7. > So you're right, it's not a "fail," but I think how great the response is to it is really disproportional. It's not. > I REALLY want to love chrome etc but I just can't - it's not ready yet. Whatever.