Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Qt & V8
My apologies if the answer is out there, but poking around I'm finding a lot of conflicting responses.
The top results say V8 support was coming but was then abandoned, and yet "What's new in Qt 5" clearly says Qt is using V8:
I've elsewhere heard it suggested that QtWebKit proper always stayed on JSC but QML went to V8 and is now dropping back to JSC.
At any rate, having trouble finding a straight answer. Can anybody clarify?
mcniva last edited by
Qt 5.2 is using the V4 engine as I understand it.
Er. V4? Do you mean V8? Why then does their 5.2 announcement talk about a "new engine" that is "slower than V8" (http://blog.qt.digia.com/blog/2013/09/30/qt-5-2-alpha-available/)?
Ugh. Why is this so poorly documented? =(
If you want to really know what is going on, follow the development mailing list :)
V4VM is the new engine and it will replace V8 in QtQML in Qt 5.2. It's a custom implementation of ECMA that is - indeed - a bit slower when it comes to parsing long JS scripts, but is several orders of magnitude faster than V8 when it comes to expressions most often used in QML: property bindings, small assignments, etc.
This is poorly documented because Qt developers do not need to know any of this. They are meant to be using C++, QML and JS, regardless of what the backend actually is :D
Qt 5.0 started using V8 because it was vastly superior to the engine used in Qt 4.8.
However, it still wasn't perfect. V8 is designed for web browsers, which have different requirements to QML applications, like what sierdzio described. The upstream V8 maintainers wouldn't accept patches that benefit QML, because those patches won't benefit browsers (which is perfectly understandable).
Thanks for all the info!
JKSH: When you say Qt 5.0 started using V8 -- does that mean in QtWebKit and QML or just QML?
sierdzio: I contest that Qt developers do need to know all of this, because the backend affects behavior (especially memory and performance) of the JS. It'd be great if it really were drop-in simple and ignorable, but we're not there yet. In any case, where would I go to follow said development list?
You're welcome. :)
Only QML used V8. Qt WebKit experimented with V8, but it never became official: https://bugreports.qt-project.org/browse/QTBUG-13184?page=com.atlassian.streams.streams-jira-plugin:activity-stream-issue-tab
Upstream, the WebKit Project has decided to completely drop V8 support: https://lists.webkit.org/pipermail/webkit-dev/2013-April/024447.html
zeveck then we disagree :) Even if you know what is the backend, you can't change it, so the information - although interesting - is of little practical use. If there is anything that you as a developer need to know, the documentation will tell you (there is, after all, a doc page named "QML performance", which lists some optimisation tricks for QtQuick).
True about WebKit dropping V8, but as I understand it Qt is going to wend towards Chromium, which I assume will bring V8 along since I don't think Chromium supports JSC? (Though the blog post makes the move towards Chromium clear, it doesn't actually address V8.)
sierdzio: Thanks for the links!
But if you want real insider information on technical details and roadmaps, subscribe to and ask at the Development mailing list -- that's where Qt's engineers live. This forum caters more for questions on how to use Qt.
topiolli last edited by
I can definitely see the reasons for this change. Having spent hours reading the code in the current implementation it is obvious that many things should be done differently.
Consequently, I have needed to hack my extensions by using hidden low-level APIs. In Qt 4, this was just a matter of finding a pointer to the internal QScriptEngine, which was used to execute QML code. In Qt5, I have used the v8 API directly. I have to say I'm disappointed I need to do this once again with Qt 5.2.
[quote author="topiolli" date="1382519308"]Consequently, I have needed to hack my extensions by using hidden low-level APIs. In Qt 4, this was just a matter of finding a pointer to the internal QScriptEngine, which was used to execute QML code. In Qt5, I have used the v8 API directly. I have to say I'm disappointed I need to do this once again with Qt 5.2.[/quote]
Please rise this issue on dev ML. I don't think your use case is being considered by people working on QML, they may be interested in knowing that you need some more stable JS extension APIs.
Matthew C. Tedder last edited by
My love of V8 makes it emotionally hard to accept a new V4VM but the arguments made in here seem valid and I think this may convince me to move ahead and try out QML again. It's either that or Electron.