
Qt for WebAssembly - anhack
http://blog.qt.io/blog/2018/05/22/qt-for-webassembly/
======
danShumway
Oof - the point of WebAssembly is not to stick your entire UI in Canvas.

This really rubs me the wrong way, it's a major step backwards for
accessibility and user control.

WebAssembly lets you bypass Javascript - it should not be viewed as a license
to build web apps that ignore user-defined shortcuts, don't work with
screenreaders, aren't responsive on mobile, can't be customized with user-
defined CSS, and that can't be scraped or automated in the browser.

Honestly, at the risk of sounding dismissive, I am increasingly suspecting
that native developers just don't understand what the web is trying to do. The
web is different from native because it's solving problems that native
developers don't even realize they have.

Sometimes APIs on the web are difficult because they're poorly designed. But
sometimes APIs are difficult because they're solving really hard problems that
developers aren't aware of. Before those APIs are thrown in the trash, we
should take a step back and think about why they were built in the first
place.

It will be a large blow to the software industry if the result of WebAssembly
is that everyone ignores large portions of what made the web great in the
first place.

~~~
alxlaz
> WebAssembly lets you bypass Javascript - it should not be viewed as a
> license to build web apps that ignore user-defined shortcuts, don't work
> with screenreaders, aren't responsive on mobile, can't be customized with
> user-defined CSS, and that can't be scraped or automated in the browser.

At the risk of sounding dismissive of web technology, this describes virtually
every web application I've seen. Many years ago (early 00s), I dreamed of a
web that was exactly as you describe it, but what we have today is far from
it.

 _If_ applications that don't overload user-defined key events (apparently,
this year it's trendy to ignore Page Up and Page Down events because they
break custom scrolling...), respond well to being customized with user-defined
CSS, are easy to scrape and automate, and don't have entirely foreign and
weird UI metaphors were a thing on the web, we certainly wouldn't have people
clinging to native applications. But this really isn't the web we have.

What's left as an advantage for this model of running native UI code in a
canvas is that at least you get native looks, as opposed to whatever the
cheapest UX designer the company managed to hire cranked out on his sixth
sleepless night in a row, and get to skip the boring installation, and get
some free sandboxing with it.

It's definitely not great and it's far from what I hoped we'd have but I'm
willing to take it over what we have _now_.

~~~
danShumway
I don't agree with people who say the web is a failed platform.

I have custom CSS and Javascript I load onto sites like Youtube and, back when
I still used it, Facebook as well. And to be clear, neither of those are good
web apps by my definition; Youtube is a SPA that forces me to use mutation
observers to tell when new DOM is added. Facebook does some really weird stuff
with iframes. But, I can customize both of them, right now, without the
developers' permission.

I'm also using the web to automate Twitter right now for a side project.
Twitter's API is a mess, so it was far easier for me to just load up Headless
Chrome and do my automation through it. Generally speaking, even if a site is
outright hostile to bots, it's not terrifically difficult to build
undetectable automation tools for it that work anyway.

I completely agree that people do crummy things on the web - the web should be
better than it is right now. I don't dismiss that you've had bad experiences
on the web, but at the same I wonder if I just frequent better sites than you
do or something. On the whole, even sites that I think are fairly badly
designed are usually more responsive, more customizable, and frankly better
designed than most native apps that I use.

I use Linux pretty much universally. Most Linux apps don't work well with
touchscreens (even the native apps bundled with Gnome are a problem). Most
Linux apps can't handle fractional scaling or zooming. Most Linux apps are not
user configurable in any way whatsoever. None of them are easily scraped or
automated unless they expose a CLI interface. There are definitely exceptions,
but... that's the experience I run into daily. Same as above, it's possible
that I just use different apps than you do.

When a GUI element is bothering me on a website, it usually takes me less than
a minute to fix without restarting or refreshing the page. Maybe 10 or 12
minutes to code a permanent solution. If a GUI element on a native app is
bothering me, I usually need to recompile it from source.

I almost feel like we're coming at this from different perspectives and with
different concerns. It's obvious to me that with my concerns moving to a Qt
style approach would be a step backwards. For users like me, even the crappy,
SPA infested, poorly optimized load of dung that the web is right now is still
miles ahead of native platforms when it comes to giving me, the user, control
over the code I run.

I don't know, I may just be optimizing for different things than you are.

What I will say is that if you build a web app right now and you utilize CSS
and the DOM, you at least have the option of making a user friendly
experience. If you compile with Qt and publish to the web with the
implementation they have right now, you don't get that option. Your app will,
objectively, be worse than even the Facebooks and Grubhubs and Twitters and
whatever of the web, at least by the metrics I care about. And nobody will be
able to fix it without recompiling and self-hosting your app.

I think that's a step backwards, but maybe you like Qt enough as a dev
environment that it's something you're willing to tolerate.

~~~
de_watcher
If web-Qt goes widespread you'll be editing QML scripts (which is much more
pleasant for applications than CSS scripts) and installing WebGL/WebVulkan
hooks/shaders.

So that's probably a question of familiarity.

~~~
martin_ky
Yes, this. The HTML language and DOM model is inadequate for implementing
interactive user interfaces. It's a _text document_ markup language after all.
QML has its own DOM structure and a library of primitive visual elements
called QtQuick. QML and HTML are very similar in fact. The main difference
though is, that the QML language and its library of primitive elements was
designed from the ground up as the language for building interactive, fluid,
animated user interfaces.

Consider something trivial as centering a user control within a parent
control. Good luck getting it right with HTML and CSS in a way that works
across browsers. With QML you just write:

    
    
        Rectangle {
            anchors.centerIn: parent
        }
    

Now I don't say HTML can be replaced by this. I am advocating, that both
technologies have their relevant use cases. They could coexist in a browser. I
can imagine even mixing them together: QML for the layout, user controls and
interactions with chunks of inline HTML for text formatting and document
embedding, or vice-versa.

There is some discussion on this from last year -
[https://news.ycombinator.com/item?id=14894937](https://news.ycombinator.com/item?id=14894937)

------
yoavm
The TextEdit example is super impressive. I don't remember many WYSIWYG
editors being so responsive.

[http://example.qt.io/qt-
webassembly/widgets/richtext/textedi...](http://example.qt.io/qt-
webassembly/widgets/richtext/textedit/textedit.html)

~~~
TheAceOfHearts
I'm on macOS and unfortunately it doesn't seem to support many of the native
platform's hotkeys, nor does scrolling work with a trackpad. But it's still a
really impressive feat, hopefully they can continue improving on it!

~~~
zem
mouse scroll wheel doesn't work either (on linux + chrome). but very nice and
responsive.

~~~
llornkcor
mouse wheel support was added after this blog and its tech preview

------
leoc
Isn't progress wonderful? 2010:
[https://news.ycombinator.com/item?id=1056391](https://news.ycombinator.com/item?id=1056391)

Speaking of which, the linked page is no longer up, so here's a Wayback
Machine impression:
[https://web.archive.org/web/20100304101843/http://labs.troll...](https://web.archive.org/web/20100304101843/http://labs.trolltech.com/blogs/2009/12/17/take-
it-with-a-grain-of-salt/)

... and ofc the Google Video link in my comment
[https://news.ycombinator.com/item?id=1056393](https://news.ycombinator.com/item?id=1056393)

> 1 point by leoc on Jan 16, 2010 | parent | favorite | on: QT on Google
> Native Client

> 1997^H^H^H^H1961 is calling; someone just picked up the rotary phone.
> [http://video.google.com/videoplay?docid=-2950949730059754521...](http://video.google.com/videoplay?docid=-2950949730059754521..).

is now broken too, so here's a link into a YouTube upload:
[https://www.youtube.com/watch?v=oKg1hTOQXoY&t=612s](https://www.youtube.com/watch?v=oKg1hTOQXoY&t=612s)

------
joezydeco
Unless this release has changed significantly in the last two months^, Qt/WASM
has a _long_ way to go.

^
[https://news.ycombinator.com/item?id=16907402](https://news.ycombinator.com/item?id=16907402)

------
pier25
If anyone is curious, everything is being rendered on canvas.

~~~
d33
What are the implications?

~~~
0x4f3759df
Somebody is going use a technology similar to this to defeat ad-blockers.

~~~
spiritcat
damm you, cold hard truth!

but it is really cool

~~~
0x4f3759df
People argue that we will just block ads at the transport level, but I don't
see why the site won't just add an extra hop and serve the ads from their
server.

~~~
chii
> serve the ads from their server.

because ad networks don't trust their own clients to not spoof the traffic
numbers.

------
TimTheTinker
There has always been a steady stream of innovations on the web that have
pushed the edge of what was possible.

Guess what? At one time, you could do just about anything imaginable using
Java applets. Then browsers caught up and soon after, Flash appeared; rinse
and repeat many times...

Qt on WebAssembly is just another leap forward in what is possible, and it’s
good because it raises the bar in some fundamental ways. But as /be says,
“always bet on the web.” It will catch up and this too shall pass.

~~~
singularity2001
java/flash was plugin, wasm is buildin

~~~
TimTheTinker
Qt isn’t built in.

~~~
singularity2001
but can be run without user confirmation/interaction, which is good and huge.

~~~
TimTheTinker
At one time Java, Flash, Silverlight, etc. would all run without user
confirmation/interaction. User confirmation was only introduced when security
problems became an issue.

So my point still stands — Qt on WebAssembly is analogous to the plugins of
yore like Flash and Java applets. WebAssembly is kind of like a new plugin
container for native code.

~~~
martin_ky
> Qt on WebAssembly is analogous to the plugins of yore like Flash and Java
> applets. WebAssembly is kind of like a new plugin container for native code.

No it’s not. With WebAssembly, it is a matter of trust in your browser vendor
and its ability to properly sandbox WASM/JS content. With plugins, you
basically gave up full control of your machine also to whichever plugin
vendor. The number of trusted relationships is different - it’s fewer with
builtin WebAssembly. That is a noteworthy distinction, I think.

~~~
TimTheTinker
That's true... but my point was that WebAssembly (including asm.js) now
provides what Flash and Java provided previously -- a portal to run non-JS
code at near-native speeds.

~~~
martin_ky
Right. There's nothing revolutionary here, that's for sure.

I think, it could have been Java (or the JVM at least) in place of WebAssembly
in browsers already a long time ago, were it a more open standard.

~~~
TimTheTinker
This has been tried, and it failed. The primary problem was that startup time
of embedded Java applets was abysmally slow. You'd watch the "java loading..."
progress bar in the browser window and wait for several seconds before it
would finally start. Flash may have gotten its name because it had an
incredibly faster startup time than Java.

Java itself is a very open standard (OpenJDK, Java language standard, etc.).
Openness of the standard wasn't the problem. In fact, it offered a much
stronger uniformity of experience no matter what browser you used, unlike web
technologies of the time.

The security issues with Java and Flash were the final nail in the coffin, but
they had already been fading -- Java due to UX issues and startup lag, Flash
due to it simply being a divergent technology from the web itself.

------
dzonga
With apple cancelling out OpenGL support. What will happen in terms web
assembly apps that would've needed that kind of access to OpenGL api's ?

~~~
vbezhenar
By default, both Firefox and Chrome use the ANGLE layer to render WebGL draw
calls under Windows. ANGLE is an implementation of the OpenGL ES 2.0
specification that is hardware-accelerated via Direct3D 9. So native OpenGL is
not even used on Windows. I'm sure that it's possible to achieve something
similar with Metal.

~~~
hajile
It seems like writing one OpenGL to Vulkan converter to rule them all would be
the best solution. It would allow GPU vendors to focus on optimizing the much
smaller and performant Vulkan engine and would probably reduce driver size by
a couple orders of magnitude.

------
Multicomp
I have no experience with either of these. I read this as "that framework
which makes native applications for most major platforms now targets the web
browser".

If the above is even 2/3rds what happens, what stops QT from taking over all
multi-platform targeted applications "one <toolkit> to rule them all" style?

~~~
21
> what stops QT from taking over all multi-platform targeted applications

The fact that Electron is much better. I know this in a highly unpopular
opinion here. I've programmed in them all (MFC/wxWidgets/QT/WinForms/WPF) and
HTML/CSS/JS is just so much easier.

~~~
shittyadmin
Try writing something as simple as a dialog in Qt. It all makes sense, you
subclass a QDialog, instantiate it and show it.

Try doing that in pure HTML/CSS/JS, you're basically left with a clusterfuck.
There's piles and piles of libraries built to workaround this clusterfuck from
Bootstrap to react-modal and even the best of them have worse APIs for this
than Qt does.

Ultimately, drawing widgets just makes more sense for desktop applications
than trying to hack document-oriented HTML to be a usable UI framework.

Don't get me started on layouts...

~~~
dchest

        <dialog>
            <p>Hello world</p>
            <button>OK</button>
        </dialog>
    
        <script>
            let dialog = document.querySelector('dialog');
            dialog.querySelector('button').addEventListener('click', () => dialog.close());
            dialog.showModal();
        </script>

~~~
yoavm
Yeah, it would be great when it'll work for more than just 60% of the internet
users. Maybe then we can actually use it!

~~~
dchest
I'm so sorry that a little bit of HTML and JavaScript reminds you and other
commenters under my post of web developer's Old Browser nightmares and brave
endeavors of satisfying 100% of Web users at any the cost, but we're talking
about Electron which ships a quite recent version of Chromium :-)

------
datalus
Obligatory Gary Bernhardt video reference:
[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

------
cjhanks
The Qt team continues to do great work, congrats.

------
ravenstine
> Downloading/Compiling...

Huh. I thought the point of WASM was for there to be precompiled binaries.

~~~
TomMarius
No, it's an intermediary format, not native machine code.

~~~
singularity2001
to be fair compiling wasm 'bytecode' takes only milliseconds, so its mainly
downloading

------
eptcyka
GTK too has had the ability to render it's windows in html/javascript[0].

[0] - [https://developer.gnome.org/gtk3/stable/gtk-
broadway.html](https://developer.gnome.org/gtk3/stable/gtk-broadway.html)

~~~
llornkcor
That is a completely different thing. broadwayd is only a display server. Qt
for WebAssembly runs in the browser in the same secure javascript sandbox.

------
xmichael999
Huh, and here I am waiting around for QT with decent C# support...

