[webkit-qt] webkit2, v8, diplomacy
chighland at gmail.com
Tue Jun 5 06:51:27 PDT 2012
>> I don't understand why the push for V8 in the first place. JSC and V8
>> are in an arms race for performance, so you can't categorically say V8
>> is faster because that's not always true.
> I did not say it's faster or superior but using two js engines in a stack is
I agree completely. That's exactly what I was trying to say: Why V8?
Why not JSC? Having both is absurd, and JSC seems like a simpler
solution, so using V8 makes little sense to me.
>> JSC also has broader support
>> (see Konstantin's post). Furthermore, my understanding is that V8
>> doesn't expose the necessary APIs to be able to provide the full scope
>> of the QtScript API. (Has this changed since the original plans to
>> move to V8 were announced?)
> I don't think v8 lack's any API that JSC has. If we only consider public
> API, I think v8 is much more rich - maybe I'm wrong. Anyway, declarative -
> which is really a fundamental of Qt5 - is using v8 and I guess there is a
> reason for that and it's not desirable to move it to JSC.
I'll retract my statement about APIs; further research on the matter
indicates that the only one QtScript offered that V8 couldn't was
offline syntax checking.
But my actual question still stands:
Why is Declarative using V8? I didn't understand the rationale for
that in the first place. No one would ever give me a straight answer.
Why couldn't it use JSC? Is it purely a licensing issue? (V8 is BSD,
JSC is LGPL) Is there some feature of V8 that really helps Qt's use
case? Or was it just "V8 was faster at the time the decision was
made"? Because, as I mentioned, which of V8 and JSC is faster varies
from release to release.
This was a decision that was made without any input from the community
or any information given to the community; we were just told "We're
using V8" and that was that.
That's what I'm upset about, and everything I can see so far seems to
indicate that V8 just makes things harder. It's another dependency
that has to be pulled into Qt, and the choices are to either drag
around two JS engines or maintain a patch set to use V8 instead of JSC
for QtWebKit. Maybe we can use Chromium's patches for the job, maybe
we can't, I don't know, but this sounds like a pain in the butt; does
anyone really benefit?
More information about the webkit-qt