[Development] Qt for WebAssembly

Fri Mar 9 15:53:54 CET 2018

<box type="soap">
While I am excited about this, I still wonder that it's the right approach. By right, I mean scalable. 
After evaluating the WebGL platform (which I was excited about as well) had having extreme performance issues, I foresee that this will has performance issues as well, because of one defect: You're rendering to a canvas what the browser can draw natively. If people want to serve Qt apps to the web, then the best approach (IMHO) is to use a server to send a client which is defined in HTML5 (name clash with Q_OS_HTML5) as non-canvas DOM elements (unless you're using a QPainter). This will leverage the browser in the best way possible, and let it handle the low-level drawing. To this end QMLWeb is an existing approach (https://github.com/qmlweb/qmlweb). 

While I wish you the best of luck, I don't think it's going to work out well. The other day I asked the question on the blog, "Why can't we divorce behavior from the the UI?" (conceptually speaking) I was asking it in the context of QtQuick/QWidgets consistency, but I'd like to extend that to HTML elements as well. You should be able to define the UI component and the behavior component of a GUI item seperately and just attach the same behaviors to he various UIs. The thing here is that the HTML version of it would already come with some behaviors supplied by the browser, and the UI component would similarly be rendered by the browser. I know this isn't do-able in 5, or maybe even 6,  but it's where I think things are headed. 

For example, a simple .ui file translator that gives you a HTML5 app would be the start. If you don't think this is possible, you should check out Webtoolkit (https://www.webtoolkit.eu/wt) which is a copy of Qt for the web. It works. At one point I wrote a script t translate Designer's .ui files from the Q* to the W* versions and it worked, mostly. If Qt wants to target the web, properly then bringing in Wt would be the 'proper' (IMHO) approach. 

We've had efforts to cram Qt binaries into browsers for over 10 years now (ActiveQt). None of it has really succeeded. I speculate it's because the initial load time is a huge turn-off. You can't use Qt for regular web sites, soo the appeal is limited. The ideal approach is one where Qt is advanced as a preferred web development technology, as well as a native technology. Incidentally that also opens Qt up to the biggest possible licensing base. 
Qt can compete with (and IMHO is better than) React and Angular.  But this smallest-effort-to-the-browser is fundamentally broken, and I think will only result in an "also-ran" situation. 

I don't want to steal your thunder, but what is fundamentally different about this approach this time? Why will the results be any different?
</box>

> Sent: Friday, March 09, 2018 at 7:57 AM
> From: "Morten Sørvig" <Morten.Sorvig at qt.io>
> To: "Qt Project Development Mailing-List" <development at qt-project.org>
> Subject: [Development] Qt for WebAssembly
>
> Hi all,
> 
> As you may have noticed work on Qt for WebAssembly is underway. With the
> recent updates the wip/webassembly branches are now based on Qt 5.11, which
> they will continue to be while we work on bringing up Qt Quick. The tracking
> bug for the project is QTBUG-63917 (with subtasks). This is a continuation of
> the initial port at https://codereview.qt-project.org/#/c/178543/
> 
> I think this may be a good time to discuss how we want to support Qt for
> WebAssembly and what direction the project should take. I’ll start out
> by describing some recent developments:
> 
> * We are targeting WebAssembly using Emscripten as the SDK. The platform plugin
>   is implemented (mainly) using the html5.h API from emscripten.
> 
>   The platform define is Q_OS_HTML5. We have wip branches for qtbase and
>   qtdeclarative. If (minor) adjustments are needed in other modules then
>   those could be submitted to the 5.11 branch under the Q_OS_HTML5 define.
>   
> * Binary sizes: We are using static builds. The minimal Qt demos (QtCore + QtGui) come
>   out at 2.1M compressed. The SensorTag demo (QtCore + QtGui + QtWidgets + QtQuick + QtCharts)
>   (as seen on Embedded World) is 6.3M.
> 
>   In the end it may be that application assets will contribute significantly to
>   the overall application size. We can look into building an asset download
>   pipeline using web service workers. 
> 
> * Load times: In addition to the network connection this depends on the browser
>   wasm implementation, Firefox has recently gotten very fast and can download and 
>   instantiate the small Qt demos in a couple of seconds.
> 
> * Qt Applications as web page components
>    
>   Qt for WebAssembly draws to a HTML <canvas> element. The default Qt html template
>   makes the canvas cover the entire browser viewport, but any layout is possible.
>   The size and position of the canvas may very well be outside of the applications
>   control. Multiple canvases per “process” is possible but not yet supported.
> 
>   On the Qt side each canvas corresponds to a QScreen. The application is responsible
>   for positioning windows on the screen(s). Qt::WindowFullScreen windows fill the entire
>   canvas area with application content, normal windows get window decorations.
> 
>   We provide a Javascript API (qtloader.js) for managing the application process.
>   (Here we have the luxury of using modern JS features due to the natural selection
>   of browsers that the wasm requirement provides.)
> 
> * Fonts
> 
>   We don’t have access to system font files. This means fonts must me embedded in
>   the application binary or downloaded on demand.
> 
>   Exact font style matches with “native” system fonts will probably remain out of
>   scope, but should still be able to match the font size setting. Page zoom is
>   handled via the high-dpi implementation.
> 
> * (No) thread support
> 
>   Wasm and Emscripten do have pthreads support. However this requires SharedArrayBuffer, 
>   which has been disabled in all major browser after recent security incidents.
> 
>   So we are looking to upstream a no-thread configure option, and modules that
>   want to work on the web should support it. It’s still possible to develop with
>   pthreads enabled by enabling SharedArrayBuffer for your browser.
> 
>   No-thread could be implemented either by removing QThread (and friends), or by
>   making QThread::start() a no-op.
> 
> * QML interpretation vs compilation
> 
>   We’re currently using the QML interpreter, which is working reasonably well
>   for development purposes. The end state is to compile to wasm, ahead of time.
> 
>   There has been some discussion on whether compilation should be implemented
>   before anything is merged to the main Qt branches, or be handled later on.
> 
> * Networking
> 
>   We are looking there approaches: (not mutually exclusive)
> 
>   - A QNetworkAccessManager backend implemented using XMLHttpRequest/Fetch.
> 
>     This allows making HTTP REST requests back to the origin server, or to other servers 
>     by using CORS.
>   
>   - A QWebSocket (client) backend implemented using HTML5 WebSocket
> 
>     This would allow making websocket connections to any server.
> 
>   - Using the emscripten sockets implementation and websockify.
> 
>     This is a tunneling solution where the server runs e.g. websockify and will forward
>     to a pre-determined target. Supports (unix) TCP and UDP sockets, so no work
>     is needed in Qt.
> 
> * QtMultimedia
>   
>    Very open for contributions :)
> 
> Further information including getting started instructions is available on QTBUG-63917,
> and also or on QTBUG-65198 (platform documentation).
> 
> Thanks for reading!
> Morten
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>