For communication between the QML host and the HTML/JavaScript client, he chose WebSockets. His idea was simple and powerful at the same time: By leveraging Qt’s introspection system, he could create mock objects on the JavaScript client side which mirror the API of the server-side QML/QObject objects. In October 2011, Noam Rosenthal presented an alternative approach to the problem, which he called Qt WebChannel. Due to that, hybrid QML/HTML applications were notoriously hard to implement. The reason for that was the multi-process architecture at the core of WebKit2, which is used internally by WebView in such an environment, the synchronous API of the WebKit bridge cannot be supported, since inter-process communication is inherently asynchronous. Up until now though, WebView, the Qt Quick 2 integration of Qt WebKit, was missing this functionality. This is a crucial functionality for any application that uses Qt WebKit as the foundation for an HTML app framework or similar. In the single-process world of the C++ Qt WebKit API, it was easily possible to publish a QObject instance to the JavaScript client side, thanks the Qt WebKit Bridge. But how does one bridge the gap between C++/QML on one side, and HTML/JavaScript on the other side? A bit of history Qt WebKit makes it trivial to embed HTML content in any graphical application. In particular, something like an HTML 5 app framework is often requested by customers. Hybrid applications, which mix a UI built with Qt Widgets or Qt Quick with embedded HTML websites, are very popular.

Qtweb browser widget