[Development] Toolability of mixing QML and JS

Thomas Hartmann Thomas.Hartmann at digia.com
Wed Jun 26 12:00:38 CEST 2013


> 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).

Since we do rewrite this does not make much difference for the Visual 
Designer. Inline code is ignored as a call to a .js file is ignored.

> - 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.

We provide a QML parser that includes Java Script as open source. Anyone 
who wants to parse QML is most likely to use this one and even if not he 
has access to the complete grammar. So this is not really an issue.

> - 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.

This is hopefully a thing of the past, soon.

>   - 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.

For prototyping writing inline code does help. We should provide tooling 
that helps/automates refactoring inline code into .js files.

Kind Regards,
Thomas Hartmann

More information about the Development mailing list