[webkit-qt] webkit2, v8, diplomacy

[Balazs Kelemen]

On 06/05/2012 04:35 PM, Keith Kyzivat wrote:
> On 06/05/2012 09:22 AM, ext Balazs Kelemen wrote:
>> On 06/05/2012 03:12 PM, Coda Highland wrote:
>>> 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 insane.
>>
>>> 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 have been hearing speak of Qt trying something new/moving away from 
> using v8 (I think because v8 is not optimized for the quick entry/exit 
> that QML does), though I imagine that Qt5 will stil provide 
> opportunity to use v8...
>
> Isn't there a way we can have v8 and JSC be separate options, with one 
> or the other compiled in at compile-time?
> How about separating out the JS engine entirely into a separate shared 
> library?
> Granted, there's a maintenance cost for maintaining both engines...  
> Maybe you're considering that in addition to the memory savings you 
> mentioned?

JSC is a hard dependency of WebKit. Organizing jsc into a shared library 
- which is possible - doesn't solve this. If you think about abstracting 
the js engine with some Qt api, that neither does work because we 
obviously cannot force everybody in webkit to use our js api.