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:
http://qt-project.org/doc/qt-5.0/qtdoc/qt5-intro.htmlAnd then the latest 5.2 announcement says, "While the new engine is somewhat slower than V8 when it comes to pure Javascript performance". New engine? New versus what? This implies they switched back to JSC from V8? Or something else?
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?
-
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).
So, to take QML to the next level, V4VM was born -- a JavaScript engine that is fully optimized for QML and that has all of Qt's interests at heart. You can read more of the technical details at http://blog.qt.digia.com/blog/2013/04/15/evolution-of-the-qml-engine-part-1/
Note: Qt WebKit is a browser toolkit, so it would continue to use a browser-optimized JavaScript engine, not V4VM.
-
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).
You can find all information on Mailing Lists here: "link":https://qt-project.org/contribute, or to be more specific, "here":http://lists.qt-project.org/mailman/listinfo.
-
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.)
http://blog.qt.digia.com/blog/2013/09/12/introducing-the-qt-webengine/
sierdzio: Thanks for the links!
-
Qt WebEngine will probably use whatever JavaScript engine is in the upstream Chromium project -- I doubt there is a good reason to spent many months ripping out the built-in engine and transplanting a different one.
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.
-
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.
The problem is that QML doesn't really provide proper ways of extending the functionality of the JavaScript engine. The old QScriptEngine API had pretty good support for extensions, but even in Qt 4, QDeclarativeEngine hid these as implementation details. The only way to really extend QML was to hack the private API and hope nothing changes.
With Qt 5, the same problem persist. The extension interfaces are not only incomplete but also broken in many ways. All this makes it practically impossible to write JavaScript extensions to QML. The only use case that has good support is UI components implemented by deriving QQuickItem.
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.
-
When V8 came out was around the same time I stopped programming in C++. I still love QT but was very under impressed by the JavaScript engine in QML. I have moved most of my focus since on JavaScript and Node.js (and even Microsoft Jscript.net for a time) because of the speed at which I could develop complex business applications and network applications.
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.
In terms of the future and general popularity of QT, there could be nothing better than JavaScript QT. going head-to-head with Electron. However, my personal preference would be doing this without XML. I wish I could just code QT in JavaScript similar to how it's done with C++. There is a QT npm for node.js but I couldn't get it to compile... clearly not well maintained.
