[Development] QML 3 and JavaScript

[Simon Hausmann]

Am 11.11.19 um 09:10 schrieb Dmitriy Purgin:
> Hi all,
>
> as we learned at the recent Qt World Summit in Berlin, we're getting 
> QML 3 with Qt 6. There are some cool features and changes to improve 
> the clarity and the performance of the QML part but there is one thing 
> that bothers me: the optionality of JavaScript.
>
> What I didn't quite get is whether JavaScript becomes optional in QML 
> 2 already and will be disabled in QML 3, or will it be optional in QML 
> 3 only, and QML 2 remains as it is now?
>

QML 2 will remain as it is now. Although many language related features 
are being added to it still, especially related to hygiene.


> As for QML 2, there is a lot of JavaScript code in the existing 
> codebase. Just look at Sailfish OS (actively developed) or Ubuntu 
> Phone, there are tons of logic implemented in QML/JavaScript. I 
> understand that UI should be separated from the logic but in the real 
> world, you can't completely enforce this that unless it is technically 
> impossible. And I'm afraid if it becomes impossible with QML 3, this 
> will be considered a step back by many Qt users.
>

Right, and a step back for our users would not be in our interest. So 
when you read "optional", it does not mean that we want to eliminate 
(imperative) code from .qml files. Quite in contrary, the ability to 
write little pieces of code in binding expressions, signal handlers or 
just functions is incredibly powerful and we have no intention of 
removing that concept. What we'd like to offer is a subset of the 
language that looks the same (modulo type annotations) and works the 
same but has a slightly reduced feature set in exchange for the ability 
to perform vastly better in terms of runtime-performance and memory 
consumption.

We have tried this and are continuing to develop this technique with the 
new Qt for MCUs graphics engine. We as well as some of our early 
customers have been writing UI related _code_ in .qml files just the way 
they're used to with great success. It's just that "heavier" code, such 
as say taking a function closure with captures that keep an outer 
variable alive, or making an xml http request within .qml files is not 
possible (at the moment).


> Our company has multiple customer projects where JavaScript is 
> actively used to implement parts of the view logic. One of the 
> projects is a domain-specific framework where we do the framework part 
> in C++, and the customer implements almost all of the logic themselves 
> solely in QML.
>
> I'm sure some parts of the codebase can be rewritten to be 
> declarative-only and work exclusively through bindings but there is 
> another thing: there are QML components that *require* imperative code 
> to work with them: the QML WebSocket type [1], sometimes even 
> Animation [2] or Timer [3]. And there are also signal handlers that 
> can execute arbitrary JavaScript code now, and even a simple 
> console.log() is so practical for debugging.
>

Yes, and I don't see a problem with those and the code around them. The 
objective is to allow writing code that can be compiled to sane 
(generated) C++. Even websocket handling might work if we make a good 
mapping for array buffers (which we already do in the dynamic setup with 
QByteArray).


> (btw how do you guys debug complex bindings and state changes? I know 
> the QML debugger exists but in most cases it's quicker to add a 
> console.log() to the property change and see what's wrong).
>

QML Debugger and console.log() :-)


> I understand that QML 2 is not going anywhere in Qt 6 but maintaining 
> both QML 2 and QML 3 will be a burden for the developers of the Qt 
> Framework, and I'm afraid QML 2 won't get much love after QML 3 is 
> released. Just as it happened to Widgets, it will be in the "done" state.
>

One thing we'd like to do differently is to allow good co-existence and 
mixing.


> Another question is: how will we control the JavaScript engine? Will 
> there be a compile switch to disable or enable it (like QtQuick 
> Compiler) or will it be a runtime option to the QML engine? If it's a 
> runtime option, there will still be the library size penalty for the 
> JavaScript engine that we, in fact, don't need, right?
>
I think most likely it'll be a compile time option, per app/project as 
well as for Qt itself.


Simon