Beta for Qt for WebAssembly Technology Preview

WebAssembly is a bytecode format intended to be executed in a web browser. This allows an application to be deployed to a device with a compliant web browser without going through any explicit installation steps. The application will be running inside a secure sandbox in the web browser, making it appropriate for applications that do not need full access to the device capabilities, but benefits from a swift and uncomplicated installation process.

When Qt 5.11.0 is released, we also plan to release a technology preview of our Qt for WebAssembly port, allowing you to try out running Qt applications directly inside the browser window.

Today we published the beta release of this port, and it is available as a source bundle in your Qt account download area. Feedback on this beta release would be greatly appreciated.

There is additional info in in the official wiki page, including information on how to set up an environment and build the package.

It really depends on what features the app needs. If it is heavily dependent on QNetworking, it most likely won’t work at the point. Threading is an issue (webassembly has only one thread at this point), there’s no local filesystem support currently, etc.

It might be as easy as a compile for a different platform, such are most of the examples.

To give an example, the app I’m working on (https://github.com/OSSIA/score) is roughly 300kloc of Qt / C++ code and compiled in WASM almost from the first try. I’m still having freezes in some places but overall it’s working great.

A sample page (maybe one of the Qt examples) would be greatly appreciated – it’d be interesting to see what the performance & load times are like without having to compile myself! Sounds awesome though!

Sorry, I know you guys try to proliferate various technologies for your own interests instead of like working together to make one really great technology, but this will be abused

WebAssembly is just another tool put out by the FIVE EYES coalition, the corporate infiltration into the public sector international intelligence community. Firefox, Opera, all of our beloved open source softwares have nasty backdoors that are on/enabled by default to allow inspection of our activities that are then gathered and shared by a collectivism of technocratical donor class warlords who use this info to betray and assail us and our rights

Sorry to be political but there is NO NEED for WebAssembly

It’s just another way to compromise the security of your browser. Here is a longer explanation, if the above didnt work for you. (You should disable webassembly. QT can be QT. It doesn’t need to be QT+Firefox+Google+CIA+GCHQ+EIIR+Pope, k? Thanks.)

It’s a crying shame not to have a live demo of this tech linked in the announcement post — such a missed opportunity! Sure it might be 500mb of alpha-quality crap full of debug symbols, but we don’t care about that 🙂

Really curious what’s the point, wierd way to deliver fancy ui features
There are a couple of projects to bring qml’s declarative approach to the webhttps://github.com/pureqml
andhttps://github.com/qmlweb
Both working on top of native browser components with much better performance and compatibility than webassembly by design
Would love if you’ll collaborate with those guys instead of reinventing the wheel

I think pureqml/qmlweb and Qt for wasm are sufficiently different that they don’t have to be mutually exclusive. The projects you are linking to are re-implementing the QtQuick runtime for the web environment. This project is implementing a Qt platform port that supports running the official Qt Quick runtime and other Qt modules on a new target.

(to be completely accurate we are also doing some work on Qt Quick itself)

One thing that would be interesting is to have compatible JavaScript API, so that projects can easily move between them. I don’t know how feasible this is in practice yet.

This is really a game changer for us and we will be rethinking about our WebUI development.
One question regarding performance of the UI:
Do you think that QML will be faster than the traditional widgets?
The widgets are at the moment rendered using the canvas (as I understand). Is QML already rendered using WebGL?

You should definitivly make a critical evaluation before deciding which project to use, but I’d like to get the facts right so that others can make well-informed decisions as well.

WebAssembly app loading times are determined by several factors: browser cache status, bandwidth availability, whether or not the web server sets the correct mime type for .wasm files (which will enable streaming compiles), the browser wasm compiler implementation, and client CPU performance. (I think that was all of them)

The most performant browser at the moment is Firefox, which can load the examples from the GitHub page almost instantly (~2 seconds) on a standard desktop machine with a good internet connection. As you say the loading times on other browsers are not that impressive, but I see no reason why they will not eventually catch up.

Both Widgets and Quick are rendered on a WebGL canvas now. Widgets are CPU rendered to a texture, Quick uses WebGL.

Which one is fastest may be an “it depends” type of question. One thing that is special for webassembly is that there is no SIMD support, which may degrade CPU rendering performance.

We do have the Qt industry standard platform porting example (wiggly widget) available online , and also the Slate app representing the Qt Quick side, so you could take a look for yourself. See the GitHub link posted in the earlier comments. The wasm-qt-examples page also have many of the Qt examples.

I made some intensive testing and find it cool that most of the samples already work out of the box. There are some glitches however when it comes to window handling and overall I have the impression that QML renders faster than Widgets.
This leaves me with some questions:
* Do you think widget rendering is improvable or do you think you should go with QML?
* Is it at the moment possible to mixup widgets with QML? Some QML samples also won’t show up in the wasm version.
* At the moment it seems everything is statically linked. Do you think it is feasible to have load time linking (DLL) for the wasm port? It seems as if this would be supported.

Could the reverse be possible too? One thing most ppl complain about qt is lack of support for a variety of lang.. it would be interesting to see qt define web assembly derivative (or similar ) standard that other languages could target

I do have an untested QSensors backend that handles device orientation and motion changes. Other sensors like light and proximity are in various states of development and would likely be added in the future.

Commenting closed.

Attention Qt 5.6 LTS Users

Patch level releases, bug & security fixes and support for Qt 5.6 LTS end on 16 March 2019.Find out what this means for you regarding support options and licensing when upgrading.