[Development] Qt for WebAssembly

[Tim Murison]

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

+1, I couldn't agree more with this sentiment.

I work in software consulting doing mobile and web work. While Qt has a
compelling offering in the mobile and desktop space with Qml, web work
has to be done with another toolkit. These days, react-native or
Angular are derigeur. As a result it is not possible to effectively
evangelize for Qt until Qt can match these technologies. Qt needs a web
solution that is as well adapted to the platform and as flexible as the
existing Qt solutions for mobile and desktop are. As described this 'Qt
for WebAssembly' feature seems to result in web applications that would
not be acceptable in many use cases.

I'd also like to echo and hopefully amplify what Jason H said about
qmlweb. IMO, this is the solution that Qt should be embracing and
integrating upstream. qmlweb aims to do what Qt has always done, make
cross-platform development easy, efficient and indistinguishable from
native development.