Eskil Abrahamsen Blomfeldt

Beta for Qt for WebAssembly Technology Preview

Published Monday April 23rd, 2018
29 Comments on Beta for Qt for WebAssembly Technology Preview
Posted in Announcements, HTML vs Qt, Releases

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.

For reporting issues you find, please refer to the Qt bug reporting tool.

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Announcements, HTML vs Qt, Releases

29 comments

Nick says:

Ah, so this isn’t a client-only thing to offer web apps without needing a server?

Jean-Michaël Celerier says:

It is client-only. Here are some examples: https://msorvig.github.io/qt-webassembly-examples/

Dmytro says:

TypeError: Failed to fetch

Morten Johan Sørvig Morten Johan Sørvig says:

Are you using uBlock Origin or another ad blocker? Looks like uBlock blocks all .wasm files from github.io.

Andy Brice says:

Sounds interesting. Do you anticipate that an application written for Windows and Mac desktops in C++/Qt will be relatively easy to port to WebAssembly?

Lorn Lorn says:

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.

Jean-Michaël Celerier says:

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.

Andy Brice says:

That is very useful to know. Thanks!

Morgan says:

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!

chris neglia / 911bodysnatchers322 says:

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

https://www.reddit.com/r/TruthLeaks/comments/8csa14/security_alert_disable_webassembly_in_your/

cneg says:

“Awaiting Moderation” If you don’t post my reply then you’re part of the problem our world is facing.

Censorship 2.0 is going to bite YOU on the butt one day. You’ve been warned

Andy Brice says:

Or maybe he was just busy? Sadly moderation is often necessary to keep an acceptable signal:noise ratio.

Stewie says:

you should setup a demo page for us to check out

David W says:

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 🙂

David says:

You can try different examples (Widget, Qml, QuickControls, etc) in:
https://s3.eu-west-2.amazonaws.com/wasm-qt-examples/last/index.html
Best experience with Firefox

Vadim Peretokin says:

It’s looking quite good – hope to see some real applications with this soon. Glad Qt is standing up to .NET’s efforts with Blazor here

Joseph Chang says:

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 web
https://github.com/pureqml
and
https://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

Morten Johan Sørvig Morten Johan Sørvig says:

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.

David Weisgerber says:

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?

Jason Hihn says:

I’m sorry, but this is not that. WebAssembly is plagued by very long loading times.
QML for WebGL is a failure. I tried my QML apps in WebGL and they would not respond in any kind of acceptable time.

You’re better off using QMLWeb, IMHO.

Morten Johan Sørvig Morten Johan Sørvig says:

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.

Morten Johan Sørvig Morten Johan Sørvig says:

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.

David Weisgerber says:

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.

Vasanth says:

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

diego says:

do you intend to make this work on mobile too? have access to sensors and native APIs?

Lorn Lorn says:

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.

Get started today with Qt Download now