First look: Qt 5 makes JavaScript a first-class citizen for app development

The community behind the Qt project has issued an alpha release of Qt 5, the next major version of the open source development toolkit. Ars takes a close look at the underlying vision behind Qt 5 and some of the key features that it brings to the table.

Qt (with a lowercase t) will depend less on Nokia because of the open governance model it is taking on. Plus according to the article: "The transition to a more open governance and development model has further cemented the toolkit's long-term sustainability." The article also mentions other companies being able to take a larger role in developing Qt.

What's with the lack of interest for support of other platforms, specifically Mac? They seem to have resources to port to alpha-stage platforms, such as Haiku, but a large install base such as Lion hasn't gotten much attention. I can guess that it may be because of the App Stores' dislike of opensource products like Qt, but there's probably more than that.

What's with the lack of interest for support of other platforms, specifically Mac? They seem to have resources to port to alpha-stage platforms, such as Haiku, but a large install base such as Lion hasn't gotten much attention. I can guess that it may be because of the App Stores' dislike of opensource products like Qt, but there's probably more than that.

As the article says, the Haiku port is a third-party project. If somebody was willing to contribute the necssary OS X improvements, they would be accepted upstream. There just aren't any volunteers who have shown interest in submitting complete patches for those things and working them through the code review process.

I'm disappointed by the direction of Qt. It's a fabulous toolkit and still is truly the best in terms of what it offers, but development has definitely stagnated... and it's not just the lack of Nokia's involvement, but also the direction of the project. I tried using QML to develop a more full interface and hastily reverted back to QWidget - and I'm someone who comes from a background in web design and scripting, not straight programming.

Perhaps this isn't Qt's fault so much as it is the general state of platforms right now. Too many devices, OSes and ideologies to target - Microsoft's approach to Windows 8 is definitely not helping matters for developers in terms of weighing Windows 8's potential against the more traditional forms of computing found in OS X, iOS and Android. I really hope that the concept of such "water-downed" applications for the more traditional desktop isn't the new norm, though, as I still like using powerful applications with full, intuitive interfaces. Not these "dumbed-down" interfaces like those created with Metro and QML for the desktop.

Please keep in mind this release is ALPHA quality without official binaries available. There is so much movement under the hood that it will take a 5.1 release sometime at the end of 2012 to provide the promise outlined in this article. I'm very confident Qt will not only provide the best cross-platform support of any toolkit but also the best cross-device support. Metro/OSX will NEVER provide cross-anything support so that leaves Android/Dalvik as a possibility but who in their right mind would ever want to get locked into JAVA.

As laptops adopt touchscreen LCDs I can see Qt becoming an extremely well suited candidate and the upcoming Raspberry Pi will ensure it's equally competitive on ARM devices as well.

While I can only observe with interest and praise Qt trying to push the envelope, the choice of javascript, a "language" plagued by such a large number of inconsistencies and design flaws it can only be described as crippled, is definitely a bad move.

I'm surprised by the headline, and the contents of this article. I think that in general Ryan Paul does a pretty good job, but I think in this case he does a bad analysis of the future of Qt.

Qt is and probably always will be a C++ library/framework. Qt Quick only means a departure from Qt Designer and XML to QML, which mostly (say, 80-90%) is a declarative language very very similar to JSON, but with heavy reminiscenses of CSS because of its declarative nature.

So yes, that runs on top of a JavaScript engine, because the remaining pieces of the UI that require small functions of imperative code are JavaScript (the other 10-20%).

But that is hardly making Qt a framework that promotes JavaScript as "a first-class citizen for app development", in my humble opinion. I've been doing lots of real JavaScript development lately (for web applications), and the experience as a developer is much, much different than using Qt Quick. I still have to see a Qt Quick application that makes the usual heavy use of anonymous functions and prototypes, for example.

Yes, designers will feel there is a familiar look because of the curly braces, and that's nice for them. But the "hardcore" developers will still use C++ for everything, and will see the small pieces of JavaScript code as some sort of "scripted pieces that look a lot like C++" anyway.

To conclude: I think that Qt Quick is a win-win for everyone. Because designers that are capable of writing web UIs, and who think that really know the JavaScript language because are able to write some short functions to handle events, and make it look good with CSS, will also be able to write nice prototypes using Qt Quick and no compiled code.

*BUT* usual C++ developers that love Qt, will also like Qt Quick because will be able to get rid of huge diffs in commits to Qt Designer files, and will be able to quickly make real applications from prototypes written by designers, because they can replace many interpreted code with native one and interface with easily. But they will not need to learn about the *real* JavaScript that you find in full web applications (closures, prototypes, variable hoisting, etc.) and that confuses many C++/Java developers who see JavaScript as a similar language to the one they know.

I love XAML. At first I was really sceptical about learning new syntax just to write code and write it seperately for GUI. But now it seems only logical.

Yeah, but with about 75% less verbosity.

I'd worked with XAML before too, and when I first saw QML, that's what really struck me: exactly the same concepts, but so... much... cleaner.

Quote:

While I can only observe with interest and praise Qt trying to push the envelope, the choice of javascript, a "language" plagued by such a large number of inconsistencies and design flaws it can only be described as crippled, is definitely a bad move.

Unlike C++, you mean, which is universally praised as a consistent and clean language?

Yeah....

And as @suy says, Qt is, and will always be, a C++ toolkit. The JavaScript stuff is a much nicer way of defining yout UI, but Qt Quick is still about the *mix* of C++ and JS.

For GUI QML is not only a faster way to develop, it is also a lot less error-prone, because of the way all bindings are 'live', updating calculated values automatically. This is something that takes a lot of glue code in C++, and that developers often miss, or even if they remember it most of the time, forgets in a few rare cases. In short QML makes UI more safe. You make a declaration, and the result is automatically updated whenever the input values in it are changed. Qt QML apps are much more consistent and resizeable than other applications, since it just works from the very first mock-up.

For GUI QML is not only a faster way to develop, it is also a lot less error-prone, because of the way all bindings are 'live', updating calculated values automatically. This is something that takes a lot of glue code in C++, and that developers often miss, or even if they remember it most of the time, forgets in a few rare cases. In short QML makes UI more safe. You make a declaration, and the result is automatically updated whenever the input values in it are changed. Qt QML apps are much more consistent and resizeable than other applications, since it just works from the very first mock-up.

This is probably true for some simple application where GUI is a big part of a project. On the other hand, Qt being primarily used for development of desktop applications most of which are in a different class than simple mobile or web=-based applications, situation there is different. For those application GUI usually is relatively small part of a project. Often they use complex data structures (obviously implemented in C++). GUI often needs to be aware of state of the data. If GUI is implemented in a different language this creates a problem. GUI can't access application data directly, special layer should be developed to handle this. Nothing new here - remember SWIG? So, it's doable, but usually it's just not efficient. Tcl/Tkl/SWIG approach is used heavily in development of CAD applications but the reason for this there is not the ease of GUI development but rather flexibility and customization. End users can use Tcl/Tk to customize/enhance application's GUI. This is not a stated goal for QML. For a desktop application developer whose primary language is C++, the benefits of QML will rarely overweight the overhead brought in by the introduction of a second language into development process.

Qt (with a lowercase t) will depend less on Nokia because of the open governance model it is taking on. Plus according to the article: "The transition to a more open governance and development model has further cemented the toolkit's long-term sustainability." The article also mentions other companies being able to take a larger role in developing Qt.

This sounds ominous, as it implies that fewer paid develpers will be working on the project. The more a project depends on unpaid volunteers, the less likely it is that anyone finishes the more boring parts of the project, even if those parts matter a lot to the end user.

Ryan, I think you misunderstood Lars. He said:“Qt 5 should be the foundation for a new way of developing applications. While offering all of the power of native Qt using C++, the focus should shift to a model, where C++ is mainly used to implement modular backend functionality for Qt Quick.”

This is not meant as a statement that JS should be used to code application logic and C++ will only be used to build QML itself, but rather that it should be possible to build full, complex GUIs using QML, and have them interface with C++ code that will do the heavy lifting.

To those concerned that there is less developers due to the change in Nokia's involvement, that's just not the case, the number of contributors to Qt has greatly increased since open governance, since a lot more people can contribute(yours truly included).

P.S. I got a tingly feeling at the mention of the removal of QHttp, as I'm the one who did the work on that.

This sounds ominous, as it implies that fewer paid develpers will be working on the project. The more a project depends on unpaid volunteers, the less likely it is that anyone finishes the more boring parts of the project, even if those parts matter a lot to the end user.

Qt still exists as a commercial project. Digia the company which offers official commercial support has engaged the community in a great way have been contributing a lot, so I don't think there's a reason for concern.

For GUI QML is not only a faster way to develop, it is also a lot less error-prone, because of the way all bindings are 'live', updating calculated values automatically. This is something that takes a lot of glue code in C++, and that developers often miss, or even if they remember it most of the time, forgets in a few rare cases. In short QML makes UI more safe. You make a declaration, and the result is automatically updated whenever the input values in it are changed. Qt QML apps are much more consistent and resizeable than other applications, since it just works from the very first mock-up.

This is probably true for some simple application where GUI is a big part of a project. On the other hand, Qt being primarily used for development of desktop applications most of which are in a different class than simple mobile or web=-based applications, situation there is different. For those application GUI usually is relatively small part of a project. Often they use complex data structures (obviously implemented in C++). GUI often needs to be aware of state of the data. If GUI is implemented in a different language this creates a problem. GUI can't access application data directly, special layer should be developed to handle this. Nothing new here - remember SWIG? So, it's doable, but usually it's just not efficient. Tcl/Tkl/SWIG approach is used heavily in development of CAD applications but the reason for this there is not the ease of GUI development but rather flexibility and customization. End users can use Tcl/Tk to customize/enhance application's GUI. This is not a stated goal for QML. For a desktop application developer whose primary language is C++, the benefits of QML will rarely overweight the overhead brought in by the introduction of a second language into development process.

You sound like a pointy haired boss. Adding an additional language is never a problem if you have half-way competent programmers or better, programming language means NOTHING! Give me a new language I have never seen before and I will still be a top programmer in it. This is pretty common knowledge among programmers, only hiring staff and managers doesn't grasp that idea. Knowledge about the problem area is much more valuable than knowledge about the tools. You wouldn't judge bridge engineers on how well they know a new type of cement cannon, would you?

Also, you don't need any special tricks to allow QML access to Qt C++ datastructures, QML can already read all of them natively, and new datastructures are enabled for QML access using standard Qt introspection syntax (Signal, slots, properties, etc.). This what everybody refers to when saying QML is for the GUI while the heavy lifting is still done in C++. QML is not designed to be a language for full program, it is designed to complement C++ programs.

Let me repeat that: QML is DESIGNED to interface with C++, it is not a weird grafting of two independent languages, it is a language specially designed to make C++ development easier. You can theoretically write apps in pure in QML + JavaScript, but that I wouldn't call that applications, just apps.

I'm surprised by the headline, and the contents of this article. I think that in general Ryan Paul does a pretty good job, but I think in this case he does a bad analysis of the future of Qt. [...] But that is hardly making Qt a framework that promotes JavaScript as "a first-class citizen for app development", in my humble opinion.

The Qt developers themselves have described making JavaScript a first-class citizen as one of the primary goals of Qt 5. You might want to have a look at the Qt 5 vision statement that Lars Knoll published on the Qt Labs blog:

Quote:

JavaScript will become a first class citizen within the Qt community and we should expect that a lot of application logic and even entire applications will be written in JavaScript instead of C++. The expectation is that many application developers will actually start out with QML and JavaScript and only implement functionality in C++ when required.

There are still issues that prevent Qt applications from being accepted in Apple's Mac App Store without patching the toolkit.

With the release of Qt 4.8.1, both of these issues have been fixed: the saving of settings to a disallowed location, and problem with the Qt File Dialog that made it incompatible with Apple's app sandboxing. See this Qt blog post: http://blog.qt.nokia.com/2012/03/28/qt- ... -download/

One commenter mentioned "the App Stores' dislike of opensource products like Qt." I think that this is a misconception, based on the VLC case. I have a Qt-based app in the Mac App Store, and it was even featured by Apple on the front page for a week.

There are still issues that prevent Qt applications from being accepted in Apple's Mac App Store without patching the toolkit.

With the release of Qt 4.8.1, both of these issues have been fixed: the saving of settings to a disallowed location, and problem with the Qt File Dialog that made it incompatible with Apple's app sandboxing. See this Qt blog post: http://blog.qt.nokia.com/2012/03/28/qt- ... -download/

Thanks for the correction! I've issued an update on the article. The metabug for App Store acceptance issues (https://bugreports.qt-project.org/browse/QTBUG-16549) doesn't appear to have been updated yet, so I hadn't realized that the individual problems had been resolved.

I don't come from an IT or a gaming background. When I read about a technology like this, my first thought is, could Qt Designer or Qt Creator itself (or something at level) be built with it? (Actually, -could- is not the right question, more like -should-). Until something at the level of MS Word or the Visual Studio IDE or Qt Designer can be developed with a technology, I don't think the phrase 'first class' applies. Business apps that are top-heavy with simple forms, and graphic-intensive games (at the opposite spectrum with comparably few 'widgets' but lots of rendering) are only subclasses of all possible applications out there.

One commenter mentioned "the App Stores' dislike of opensource products like Qt." I think that this is a misconception, based on the VLC case. I have a Qt-based app in the Mac App Store, and it was even featured by Apple on the front page for a week.

It's not a problem for programs that use Qt Commercial. Using the LGPL version could be problematic, however. Thus why Nokia retained the Commercial license despite shifting from GPL to LGPL.

For GUI QML is not only a faster way to develop, it is also a lot less error-prone, because of the way all bindings are 'live', updating calculated values automatically. This is something that takes a lot of glue code in C++, and that developers often miss, or even if they remember it most of the time, forgets in a few rare cases. In short QML makes UI more safe. You make a declaration, and the result is automatically updated whenever the input values in it are changed. Qt QML apps are much more consistent and resizeable than other applications, since it just works from the very first mock-up.

This is probably true for some simple application where GUI is a big part of a project. On the other hand, Qt being primarily used for development of desktop applications most of which are in a different class than simple mobile or web=-based applications, situation there is different. For those application GUI usually is relatively small part of a project. Often they use complex data structures (obviously implemented in C++). GUI often needs to be aware of state of the data. If GUI is implemented in a different language this creates a problem. GUI can't access application data directly, special layer should be developed to handle this. Nothing new here - remember SWIG? So, it's doable, but usually it's just not efficient. Tcl/Tkl/SWIG approach is used heavily in development of CAD applications but the reason for this there is not the ease of GUI development but rather flexibility and customization. End users can use Tcl/Tk to customize/enhance application's GUI. This is not a stated goal for QML. For a desktop application developer whose primary language is C++, the benefits of QML will rarely overweight the overhead brought in by the introduction of a second language into development process.

You sound like a pointy haired boss. Adding an additional language is never a problem if you have half-way competent programmers or better, programming language means NOTHING! Give me a new language I have never seen before and I will still be a top programmer in it. This is pretty common knowledge among programmers, only hiring staff and managers doesn't grasp that idea. Knowledge about the problem area is much more valuable than knowledge about the tools. You wouldn't judge bridge engineers on how well they know a new type of cement cannon, would you?

Also, you don't need any special tricks to allow QML access to Qt C++ datastructures, QML can already read all of them natively, and new datastructures are enabled for QML access using standard Qt introspection syntax (Signal, slots, properties, etc.). This what everybody refers to when saying QML is for the GUI while the heavy lifting is still done in C++. QML is not designed to be a language for full program, it is designed to complement C++ programs.

Let me repeat that: QML is DESIGNED to interface with C++, it is not a weird grafting of two independent languages, it is a language specially designed to make C++ development easier. You can theoretically write apps in pure in QML + JavaScript, but that I wouldn't call that applications, just apps.

As some one who developed applications using FORTRAN, FORTRAN-77, C, C++, C#, Java, JavaScript, CSS, HTML, DHTML, Perl, Tcl, Incr Tcl, Tk, iWidgets, MFC and countless other languages like CShell, MS Power Shell, AWS, SED, TPU, CLD (back in VMS days) I know how difficult/easy it is to learn a new language. It's easy. What is difficult is how to develop a high quality application with a long life cycle. And when it comes to using multiple languages the rule is simple - the fewer the better. Only when the use of another language brings critical advantages it makes a sense to consider adding another language.

The fact that QML can access Qt data is useful but not sufficient. Application data may be stored in proprietary structures - and for most serious applications it will be. Even if it's a reasonably simple data structure based on the use of STL containers - how would QML/JavaScript handle this? Admittedly, I do not know much about QML, so I may be missing something. However given the fact that it is JavaScript based I expect problems there.

I would understand the benefits of QML for those developing for Symbian. But this is the past, is not it? I do not think Qt is in a position to compete with native development tools on Android, iOS or Windows Phone OS. Qt is however being actively used for development of desktop applications and this is where QML benefits are marginal at best.

While I can only observe with interest and praise Qt trying to push the envelope, the choice of javascript, a "language" plagued by such a large number of inconsistencies and design flaws it can only be described as crippled, is definitely a bad move.

Oft-repeated FUD. Javascript in browsers is one thing, javascript divorced from browsers is another. Node.js and Rhino prove the point.

I'm sure combining C++ (extremely common and accepted systems level mid-level language) and Javascript (extremely common and accepted UI/high level script language) is a terrible idea. Oh wait, no, it's a great idea. Maybe Python would have been a good choice too but beyond that there's no developer "market" like the one for Javascript

While I can only observe with interest and praise Qt trying to push the envelope, the choice of javascript, a "language" plagued by such a large number of inconsistencies and design flaws it can only be described as crippled, is definitely a bad move.

Oft-repeated FUD. Javascript in browsers is one thing, javascript divorced from browsers is another. Node.js and Rhino prove the point.

OH HELL NO!. As someone who is wrestling with the shortcoming of the C++ / Rhino-JS combination on a daily basis (because someone found it a wonderful idea to use javascript as a server-side *data-processing language*, of all things!) I can tell you that the problem with js is not the engine. It's the bloody language, the whole weak-typed, convert-everything-to-a-string half-baked madness of it.

As pointed above by RoverDaddy, lilo777, and a number of others, JS might let you build a pretty flashy business app, but it is simply not going to let you interface easily with the complex, heavy data-structures of industrial applications, and the CPU and memory requirements that come with it. When you have to display on a screen an interactive, navigable, zoomable network visualization with 1000s of nodes including metadata, good luck with using js as your programming language...

The fact that QML can access Qt data is useful but not sufficient. Application data may be stored in proprietary structures - and for most serious applications it will be. Even if it's a reasonably simple data structure based on the use of STL containers - how would QML/JavaScript handle this? Admittedly, I do not know much about QML, so I may be missing something. However given the fact that it is JavaScript based I expect problems there.

That is a fair question. Basically you can make the top interface of the data-structure into a Qt container or data-model. Data-models has been central part of Qt since 4.0. You can also give access to variables in custom object by declaring them properties. Declaring them properties will make Qt's moc object produce accessor methods and a signal for changes to the variable. This means in practice you just add single declaration Q_PROPERTY (If I remember correctly), and the variable is accessible.

For more advanced datastructures such as trees, you can probably export them to JS, but I don't think you should, instead export the view of the data to JS. This way the real data-processing is still in C++. QML should have as little processing as possible. Consider it template code. It just hooks data to content, and device-information to layout.

I always understood that you can slap a QML control onto a QWidget-based form and it'll just work nicely (unlike WPF where you have to implement everything in XAML), which gives you the best of both worlds. If that's so, why are they almost deprecating the QWidget style in favour of everything-as-QML-with-javascript GUI scripting?

Still, it sounds like this is the best GUI development toolkit there is in the industry at the moment. I just hope that the improvements are reflected in the Wt project.