[Development] QtScript vs Qml/QJsEngine ?

[Olivier Goffart]

On Saturday 26 May 2012 12:51:23 Stephen Kelly wrote:
> Hi,
> 
> There is a discussion on a kde list touching on whether there is a
> replacement for QtScript in Qt 5.
> 
> http://thread.gmane.org/gmane.comp.kde.devel.kwrite/32993/focus=75079
> 
> Is the QJSEngine the start of public API providing a replacement for
> QtScript?
> 
> Thanks,

To summarize the problem with QtScript:

QtScript was originally developed using its own JavaScript engine. 
While good, it was year behind the state of the art JS engine. It was much 
much slower (did not have JIT)  and the new ECMAScript feature were not 
implemented yet.  (the old engine is still available in the QtScript Classic 
solution [1])

So we switched the internal engine to use JavaScriptCore.
JavaScriptCore is the WebKit main JavaScript engine. It is developed only for 
use within WebKit.  It does not have a real public API[2] so QtScript hooks 
into the JavaScriptCore internals.
Also, patches to JavaScriptCore were required to add some feature and make 
sure we can have all of the QtScript old API.  One of the problem is that 
QtScript was exposing some implementation details in its API.  Some of the 
function (for example in QScriptContext) are not even implemented at all in 
the JavaScriptCore port because it did not match the way JavaScriptCore is 
working.  But still, most of the API of QtScript just works like before so 
there is not that much behaviour changes.

The problem is that JavaScriptCore is changing a lot.  And the upstream do not 
care about QtScript use case, they only care about the use within WebKit.  
Which means they do not want to include out patches. And they are not really 
open to have a stable API to do what is possible with QtScript.

Updating QtScript from upstream is a lot of work. Not only our patches need to 
be re-applied, but the whole QtScript code need to be re-adjusted to the new 
internals and changes in the private API.  That can easily be one week of work 
for a couple of developers.

This is the reason why we wanted to change again the backend to V8. That 
engine has a stable API. And it is not tight to a html engine, their developer 
care about the QtScript use case (embedding a script engine into an 
application).
We started the work to port the QtScript API to V8 (our work is still on 
gitorious [3])
We made good progress, but run into the problem that V8 has different 
internals, and some concept of the QtScript API are really difficult to map to 
V8. Nothing is impossible of course, but another problem is that this mapping 
has a cost performance wise, and the QML team were not ok with that cost.
When Qt5 was decided, we decided to give up on the QtScript API that comes 
from the old backend, and write a smaller API that maps better the V8 API.
(Also, QtScript was no more an important module since QML team had decided to 
use V8 directly for performance reasons)

So in your case, the situation is indeed quite bad.  The QtScript is not 
really maintained anymore.

One possible solution in Qt 4.x would be to use the V8 API directly. Its API 
is probably good enough for what you need to achieve.  The only problem is 
that the V8 API is not really Qt-ish. It has its own way to manage memory you 
need to get used to. And you won't have nice automatic QObject bindings with 
signals/slots. (you just need to write your own V8 wrappers)


[1] http://doc.qt.nokia.com/solutions/4/qtscriptclassic/index.html
[2] The available C public API is very limited does not let you do more than 
executing scripts. There is no way to bind objects properly or do what is 
required for most of QtScript usage.
[3] http://qt.gitorious.org/+qt-developers/qt/qt-script-ng/commits/master-v8


-- 
Olivier

Woboq - Qt services and support - http://woboq.com