[Development] QML and JavaScript extensions

Kuba Ober kuba at mareimbrium.org
Thu Nov 14 14:43:48 CET 2013


On Nov 11, 2013, at 3:38 AM, Topi Mäenpää <topi.maenpaa at intopii.com> wrote:

> V8 was touted as the unifying solution for Qt JavaScript support. It 
> really would have made sense to use the same script engine everywhere. I 
> feared that the script engine would be changed once again and discussed 
> with Digia guys before switching to Qt5. The message was clear: QtScript 
> will be deprecated and QML with V8 is the future. This seemed to be a 
> sure bet, and the pointer to QV8Engine was even available through 
> QJSEngine::handle().

I don’t know who exactly “touted” it, since (and developers, please correct
me if I’m wrong) Qt 5.0 and 5.1 uses a heavily modified version of V8. Thus
webkit and QML in Qt 5 had two completely separate JavaScript engines, and
in Qt 5.2 they still do, except that now QML’s engine doesn’t derive from
V8 anymore.

I can’t understand why would that ever be a problem, since, due to modifications
needed for QML support, the possible ways to extend V8 from QML are 
different from extending V8 merely from webkit. Both Qt and webkit’s javascript
engines are implementation details - it’s fairly obvious from the exposed APIs.
I personally think that the “touting” you allude to is merely the fog of war,
I never saw it explicitly mentioned as a strategy for extensible, reusable
general-purpose Javascript engine functionality.

Personally, I think that if you want JavaScript in any application, Qt-based or not,
you have to choose an engine that will work on the platforms of your choice
and for your purposes, and stick to it - meaning it’s on you to integrate it.
Note that V8 is out of the question on many app stores due to sandboxing requirements.
If you want your platform to be usable on the ever-more-powerful mobile
platforms, that needs to be kept in mind.

Cheers, Kuba Ober


More information about the Development mailing list