Qt Developers Begin Brewing Their WebAssembly Plans

[phoronix]

Phoronix: Qt Developers Begin Brewing Their WebAssembly Plans

The Qt Company developers are soliciting feedback from developers and the community about what they would like to see out of WebAssembly support for the tool-kit...

http://www.phoronix.com/scan.php?page=news_item&px=Qt-WebAssembly-Planning

[ddriver]

Great, that's just what Qt needs - even more bloat, running on top of an even slower and more unstable platform abstraction. But fixing long standing critical bugs - that's not a priority.

[Radical_Edward]

I think Web assembly will be the end of html supremacy on the web. It will have to compete with stuff similar to ionic since it will be much easier to implement.

[ddriver]

I think Web assembly will be the end of html supremacy on the web.

How so? It doesn't seem that this is the design intent. The purpose is to have code translators generate bytecode so that existing code bases can be leveraged from inside a browser.

HTML is just structural declarative markup, not computational logic. And while it can also be expressed in an assembly like language, that would be the exact opposite of productive. Nobody writes in assembly. 99.9999% of the assembly code is generated from other languages, which is also the case for webassembly. Granted, HTML is quite verbose and has overheads, and a JSON like syntax would make more sense, but webassembly is not the tool for that.

What webassembly might end up replacing is JavaScript, but not HTML and not CSS. Walking away from declarative languages will make it tremendously harder to define, style and maintain user interface.

[cybertraveler]

At least in the short term to medium term WebAsm doesn't even compete with Javascript; it complements it. Javascript can interact with the DOM and do all sorts of other stuff that WebAsm code can't. Javascript is also a garbage collected language which is easier and faster to program in than using C/C++ (which is what is currently being used to produce WebAsm binaries).

WebAsm, right now, is a nice way to get CPU and memory intensive apps running faster in a web browser.

[starshipeleven]

Great, that's just what Qt needs - even more bloat, running on top of an even slower and more unstable platform abstraction. But fixing long standing critical bugs - that's not a priority.

Like it or not, if they don't support WebAssembly it's not going to be good for their sales.

Also, how is WebAssembly more abstraction and bloat? It's supposed to run inside browser components, and to be significantly faster than current logic (javascript) that can be used in there.

[ddriver]

Also, how is WebAssembly more abstraction and bloat? It's supposed to run inside browser components, and to be significantly faster than current logic (javascript) that can be used in there.

Well, Qt uses its own platform abstraction layer that runs directly on the system's native APIs. And it is C++ compiled to machine code.

If you put Qt on top of wasm, then that's another level of abstraction. You no longer run directly on the system native APIs, you run on top of the wasm runtime which runs on top of the system native APIs.

And while wasm is faster than JS, even when JITed, I can guarantee you it is slower than the native binary generated by the C++ compiler. I haven't run tests, but I won't be surprised if C++ translated to wasm and executed by the wasm VM is at least 2-3 times slower, maybe even more. Who needs that?

Oh and there are the implications of running on top of a web browser (or a standalone browser derived runtime), and even the most efficient ones are notoriously bloated, adding significant memory usage overhead, plus potential stability issues.

Qt has a serious problem if having like ZERO vision and future direction, making it susceptible to blindly following pointless fads in its struggle to gain relevance. Which is exactly what this is. It doesn't need to go that road. The QPA is already trivial to implement directly on top of the host OS, which is why Qt already supports so many platforms. It is already C++ code, which is as fast as it gets.

This is WebGL all over again. Cool that they ported OpenGL to be useful inside a browser, but even with wasm, it is several times slower than native OpenGL, and again, cool, but who needs that? I mean aside from the industry eager to sell newer hardware because of increasingly inefficient software. I might be oldschool, but I think the future should be about efficiency, not about waste.

Going this road will not gain it more platform support. It will hurt its performance. It will increase memory usage. It will decrease stability. It will introduce bugs. It may potentially compromise security too. To no benefit whatsoever. And I highly doubt something entirely unnecessary and also detrimental in so many ways will increase their sales.

EDIT: Wow, it appears that wasm was another overhype. I don't see anywhere nearly the claimed "up to 30 times faster than JS". Just ran all the benchmarks on this site, to a rather mediocre results:

https://takahirox.github.io/WebAssembly-benchmark/

collisionDetection 0.8060
Fibonacci 2.6991
ImageConvolute 1.3684
ImageGrayscale 0.4413
ImageThreshold 1.2005
MultiplyInt 5.6468
MultiplyDouble 1.6989
MultiplyIntVec 0.6607
MultiplyDoubleVec 0.3447
QuicksortInt 0.9182
QuicksortDouble 1.1569
SumInt 0.9124
SumDouble 0.5071
VideoConvolute 1.3211
VideoGrayscale 0.3654
VideoMarkerDetection 0.9324
VideoThreshold 0.9504

The number says how much faster wasm is compared to js. If it is less than 1, that means it is slower.

Running in latest chrome, the highest gains wasm shows are in MultiplyInt , Fibonacci and MultiplyDouble, where it is 5.6, 2.7 and 1.7 times faster than js.

And in the rest it is about the same, with the exception of several cases where it is substantially slower.

On average, wasm is not even 30% faster than JS.

Now judging by the comparison here:

https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=gpp

C++ is on average 8 times faster than JS.

Giving a rough estimate that a Qt application will run about 5-6 times slower on top of wasm than it would run as a native binary. So why bother?

[starshipeleven]

I highly doubt something entirely unnecessary and also detrimental in so many ways will increase their sales.

Does not matter how efficient it is, for most company software it's irrelevant as it's basically a local GUI for some backend, but it does need to follow fads so the clueless managers taking the decisions can be impressed and buy it for their new project (regardless of the opinions of the actual developers) instead of $another_dumb_thing still using the same buzzwords.

Really, if company software was about performance and efficiency then Java and PHP would have died long ago.

[kpedersen]

One day HTML, CSS and even Javascript will be seen as deprecated "fixed functionality". If you want to use correct HTML, CSS or Javascript, you will need to compile an implementation yourself into webassembly and then provide it to the web browser.

I see this as good and bad. It is bad because the complexity will certainly rise (and so too will dependencies etc...), however I also see it as a benefit because you can specify the exact interpreter you have tested on. I am sure an IE6 compatible HTML implementation will be developed and we can all carry on with our little lives

[ddriver]

One day HTML, CSS and even Javascript will be seen as deprecated "fixed functionality". If you want to use correct HTML, CSS or Javascript, you will need to compile an implementation yourself into webassembly and then provide it to the web browser.

Why stop there, and not implement a browser while you are at it?

"Regular" applications already do that - you do from scratch whatever works out for you, no need to conform to anything. No browser needed. Native binary code, running blazing fast.

I get the benefit of being able to use the many C libs out there in web applications - that's nice. But "wasm everywhere" - that's just utterly, brutally, laughably dumb.

Going "grassroots" is IMO a great idea considering how bloated and inefficient software currently is. It drains CPU cycles, it wastes RAM, and it is riddled with security vulnerabilities.

But going grassroots so you can insert yet another layer of that garbage and keep all the existing garbage, that's the kind of stuff that can make me glad if tomorrow I hear that they discovered an asteroid that will 100% hit the planet and put an end to this stupidity.