[Development] Toolability of mixing QML and JS

[Koehne Kai]

> -----Original Message-----
> From: development-bounces+kai.koehne=digia.com at qt-project.org
> [...] 
> Now maybe these don't solve your specific toolability concerns. But as you
> haven't mentioned any specific concerns yet, I can only address the problems
> I'm aware of. As I said, I'd like to hear your toolability complaints about JS
> embedded in QML, in a separate thread.

Oh well, the issues have been discussed up every so often, right from the start of QML ... I guess the ship sailed long ago for a stricter separation between 'imperative' and 'declarative' parts but since you asked for it I can try to collect the main points it:

 - Designer: Any visual designer will only be able to cope with the declarative parts. JS snippets are opaque blobs. They are often written in a way that assume things about when they're evaluated, how often they're evaluated, expect a  certain environment/backend that only the real application provides etc. The best a visual tool can do is warn about their use and ignore them (and hope that the declarative parts can stand on their own).

- Editors: A lot of IDE's out there understand .js files. Writing a parser for only the declarative parts of QML is relatively easy. Writing a parser for .qml files that also understands all of JS, not so easy.

- Performance: Moving from the QML land to the JS land and back has significant conversion costs. Given that some expressions are 'magically' faster (v4 optimized ones), and that it's often non-intuitive how often things are actually evaluated, this can be a source of hard-to-track performance issues. We came up with the QML Profiler also because of this.

 - Architecture: We only give the people a blurry advice where to draw the line between QML code, JS code, and C++ code. I guess most would agree that you should keep JS code to small snippets for 'production' code, but actually our examples do not reflect that at all. One result of this is that we were trying hard to come up with a debugger in Qt Creator that supports all languages, including mixed debugging of JS and C++ at the same time. 

 - Compiling QML: It would be almost trivial to compile only the declarative parts of QML to C++/binary at compile time. This would have helped addressing concerns about performance, deployment, protecting IP, runtime sizes etc.

That said, I of course also see the advantages of the current mix, and the quick prototyping that the current language allows is certainly one of the selling points of QML. 

Regards

Kai


> It will almost certainly be easier to address them with the new JS engine than
> the old one.
> 
> --
> Alan Alpert
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development