On 5/26/06, Geoffrey Garen <[EMAIL PROTECTED]> wrote:
There seems to be a lot of misunderstanding on this thread. Let me
try to clarify some things.
First, the most helpful thing to do in these circumstances is to file
bugs in WebKit Bugzilla (bugzilla.opendarwin.org). I've filed bugs
9128 and 9129 about script.aculo.us. I am yet to see a flame war
change a blogger's perspective on the world. On the other hand, I
routinely see reduced test cases and diligent work do wonders.
Second, Firefox has bugs. Lots of them. I just did a search for open
bugs in the Firefox component and got up to 8,272 before the Bugzilla
server gave up. And that's just the bugs they know about. For
example, in the case of https://bugzilla.mozilla.org/show_bug.cgi?
id=235441, Firefox has created a classic bind for which people
usually scold Internet Explorer: do we do the standards-compliant
thing, or emulate a Firefox bug to improve compatibility? So I don't
think 'Replace Safari engine with Firefox engine... profit" is the
end of the story, any more than 'Replace Firefox engine with Internet
Explorer engine... profit" is. Another issue with SpiderMonkey is
that it's far slower than JavaScriptCore, and speed is a big priority
for us.
Thats a bold statement considering one is bytecode based and the other
uses a tree.
Can you show where the engine test were performed results etc etc.
I simply can't believe this with out a very large test suite.
I think your either spreading a rumor here or reporting results based
on a small test suite.
There is nothing googliing that indicates there has been any serious
comparision.
Finally the plan as written is to move to a bytecode interpeter if
SpiderMonkey which is bytecode based is truly slower then why go to a
bytecode interpeter. I've looked at the SpiderMonkey interpeter it
seems okay for bytecode interpeters nothing obviously wrong with it.
If someone has plans to write a bytecode interpeter that blows
SpiderMonkey away please share.
As far as I'm concerned its technically impossible for a tree walking
function calling interpeter to come close to bytecode in execution
speed if you have succeded this is a major breakthrough. All I can
guess is that its faster for small bits of code that runs once.
Agian I'd love to see a honest comparision of the two engines and a
real plan for improvement.
Third, there is no such thing as a perfect browser. Compatibility is
a two-way street. WebKit needs to implement reasonable behavior, but
web developers also need to test their applications with WebKit.
Because web developers use Firefox, they tend to make their sites
work in it, too. Take script.aculo.us, for example. Many of the
script.aculo.us unit tests fail because they expect Firefox's result,
"transparent," but in Safari get "rgba(0, 0, 0, 0)" instead. They're
the same thing, but script.aculo.us doesn't know it. script.aculo.us
is also developing "ghost train," which "should be able to work
completely with most standards-compliant... applications," even
though it "currently... only works in Firefox." So this is not just
an issue of having a standards-compliant engine; it's also an issue
of encouraging developers to pay attention to Mac customers, and
having an app that developers enjoy using.
Geoff
On May 25, 2006, at 6:04 PM, Abhi Beckert wrote:
> I've seen several blog posts recently (eg:
> http://rentzsch.com/code/dashcodeForAjaxAppDevelopment) that boldly
> state WebKit's "ajax support" is vastly inferior to FireFox. All of
> them have been very vague and haven't specified exactly where WebKit
> is lacking, so I thought I'd ask you guys: Is WebKit inferior, or is
> it just because FF is cross platform/has more users, and the companies
> are focusing on FF first, and other engines later?
>
> If these claims are unfounded, lets chop them off at the head.
> _______________________________________________
> webkit-dev mailing list
> [email protected]
> http://www.opendarwin.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
