I got called out by a few of the maintainers back when Qt first started targeting WASM for criticizing their reliance on rendering binary blobs of pixels to a canvas instead of writing native components in HTML.
At the time, I was told that this was basically just a tech demo, and accessibility was actually the browsers' fault because there wasn't a Javascript API, and that all of the touch controls were going to be fine, and implementing all of the browsers' input methods by themselves was actually better than messing with CSS, and everything would be fine if I was patient.
So now, checking in, I can see that scrolling still doesn't work on my Mac, that the demos still aren't responsive and completely ignore the window width, that I still don't have any accessibility options, that keyboard shortcuts like `tab` still don't work, that text still isn't selectable or searchable, and that right-click is still broken.
For the cluster example[0] I'm downloading 30 MB! of code to render just three gauge charts on a page that uses 14MB of RAM. CPU fans immediately spin up -- I'm plugged in, but I can only imagine what this demo would do to my battery life.
I'm very excited about WASM, and there are some communities doing some really exciting things you should check out. Rust is well on its way to being a first-class language on the web. .NET had some really interesting demos. .NET actually renders your components as HTML, so there's potential you could use C#/.NET for practical web development, and not just for a quick port of an existing app. There are people doing cool things here.
But I don't think Qt is built for the web. The devs are trying to cram a square peg into a round hole, and I'm skeptical that their future efforts will be any better. My understanding is that even on native platforms, Qt does a lot of behind-the-scenes rendering computations that then gets painted out as a pixel array. If that's true, that could explain their insistence on doing the same thing here, but... that doesn't make it any better.
Don't use a WASM compiler that spits its entire interface into a canvas as a pixel array. I've seen a few people call this Flash 2.0, and honestly I think that's doing a disservice to Flash. Flash had better accessibility controls than this.
Demos. Allowing a users to test-run your application in-browser instead of just looking at screenshots is a game changer. I wouldn't be surprised if this was the primary motivation for the wasm port in the first place.
I agree with others in that using wasm to build a web app would be lunacy.
WASM is fantastic, I have no problem with people who want to get rid of Javascript. The problem is reimplementing the entire browser stack, from scratch, on top of an existing browser. That's the part that's a bad idea.
> Pulling this off was really hard; we’ve basically ended up building a browser inside a browser.
So I played around a bit with Figma. It is notably better than Qt, because the only thing it's using WebGL for is its main canvas. When I saw that comment in the linked article, I assumed Figma would be making most of the same mistakes as Qt.
But all of the menus and site controls are normal HTML, and that helps a lot (although, holy crap learn how to use elements other than divs/spans).
It's not crazy to me that you would have a section of your app that fell back on custom conventions, that's what Canvas was built for. Apps like this explicitly are the use-case. However, there are still tradeoffs from that, and Figma's main canvas suffers from most of the same problems as Qt. The scroll hijacking feels really weird, it's totally inaccessible to screen readers as far as I can tell.
And it's not entirely clear to me why it was built that way. What makes it weird is that as far as I can tell, Figma projects export to HTML/CSS. I don't understand the line of thought that makes a programmer decide to completely reimplement something the browser gives them for free. It's not like they need to support older browsers, they're relying on modern WebGL and WASM. Why wouldn't they want a true WYSIWYG editor?
wasm is great. I just don't think Qt's wasm port is in a state where companies can just compile their desktop application, throw the resulting module on a web server, and then expect a decent result.
Ignoring the fact that most desktop applications aren't designed to be ran on a mobile-sized screen, Qt's accessibility support is non-existent (at least that was the case when I last evaluated their tech preview).
So to rephrase: Naively porting desktop applications and presenting them to customers as a first-class product would be lunacy.
Qt is not for web applications. Qt is not a web framework even if it runs in the browser. The browser is just one extra platform for cross-platform applications.
> The browser is just one extra platform for cross-platform applications.
In the current state, I don't think it would be accurate to say that Qt supports the browser platform, and given the fundamentals of their approach (webGL), they're unlikely to get to an acceptable level of support any time soon.
Someone else brought up legacy codebases, which I can see a use-case for. I could also see a use-case for letting people do design reviews on your native app without forcing them to install a new build.
But would anyone here feel comfortable shipping this kind of output as a commercial product and advertising that your app had web support? I wouldn't.
At that point I would seriously question trying to badly port it to the web versus just running guacamole or some other way of rendering actual desktop applications into a browser.
> Accessiblity will not work as emscripten does not have access to the DOM at this time.
Rust has had this figured out for a while. You build a few helper methods in Javascript and call them from WASM.[0]
WASM has access to Javascript, so it has access to everything in the browser; that's already how Qt is getting the mouse position and intercepting keyboard events. Spitting pixels onto a canvas is an architecture decision, not a language restriction -- it's possible to build accessible WASM apps.
> Seems responsive to me, tab works fine and dandy, text is selectable, right click works fine as well. I dunno what you are complaining about.
From a quick test in Chromium:
- Right click won't work on mobile (long presses should trigger a right-click).
- Clicking on the main document to enter edit mode is broken via touch controls. You literally can't enter edit mode at all.
- Tab support is poorly implemented. On the web, when we talk about tab support, what we mean is that you should be able to use the entire interface from the keyboard. Here if you open a menu you'll immediately get stuck in an infinite loop. This is something you'd get for free if the menu was rendered with a <ul> element.
- Scrolling is inverted from my browser settings.
- Middle-click scrolling doesn't work at all.
- Searching for text doesn't work at all.
- On mobile interfaces or when looking at the app in responsive design mode, the entire interface gets scaled by a fixed percentage. This is particularly interesting, because that had to be a conscious choice. Container sizing just works on the web, I would need to think about how to break something like that.
- I don't know if the intention was to support all of the keyboard shortcuts the app lists (ctrl-f/command-f), but a lot of them don't work. I'm impressed that command-z gets correctly interpreted as undo. I guess the app must just check the user string to determine what OS I'm working on. I'm curious whether that'll also work on less common operating systems.
- Accessibility is obviously nonexistent, but the position of multiple Qt developers I've talked to is that this is apparently the browser's fault, not theirs. Still worth bringing up though, none of these apps are ever going to be compliant with A11y standards.
I'm leaving out any of the bugs I'm noticing with collision detection or resize performance, and just pointing out the issues that would be immediately fixed, for free, by rendering to HTML.
Also as a quick sidenote, stuff like broken scrolling isn't an "issue" in quotation marks. It's just a bug. I don't think you can chock something up like "my mouse scroll wheel should work" to a user preference. In the same way, you can blame accessibility problems on whoever you'd like, but a text editor that's impossible for a blind person to use is a real issue.
Most native apps I use today are just interactive documents.
This position that we have to abandon the browser because XML can't handle application state gets brought up a lot and sometimes it's true, but most of the time it's not. I can count on almost one hand the number of native applications I have on my computer that couldn't be reasonably trivially represented in HTML.
And even the majority of those apps only have specific sections that would need to fall back to WebGL. Inkscape springs to mind, just because I currently have it open in front of me. There's almost nothing other than the main canvas itself that would require a custom renderer if you wanted to port Inkscape to the web.
Remember that HTML is not a layout tool, it's a render target. The point of HTML is just to represent state to users in an XML-based format.
At the time, I was told that this was basically just a tech demo, and accessibility was actually the browsers' fault because there wasn't a Javascript API, and that all of the touch controls were going to be fine, and implementing all of the browsers' input methods by themselves was actually better than messing with CSS, and everything would be fine if I was patient.
So now, checking in, I can see that scrolling still doesn't work on my Mac, that the demos still aren't responsive and completely ignore the window width, that I still don't have any accessibility options, that keyboard shortcuts like `tab` still don't work, that text still isn't selectable or searchable, and that right-click is still broken.
For the cluster example[0] I'm downloading 30 MB! of code to render just three gauge charts on a page that uses 14MB of RAM. CPU fans immediately spin up -- I'm plugged in, but I can only imagine what this demo would do to my battery life.
I'm very excited about WASM, and there are some communities doing some really exciting things you should check out. Rust is well on its way to being a first-class language on the web. .NET had some really interesting demos. .NET actually renders your components as HTML, so there's potential you could use C#/.NET for practical web development, and not just for a quick port of an existing app. There are people doing cool things here.
But I don't think Qt is built for the web. The devs are trying to cram a square peg into a round hole, and I'm skeptical that their future efforts will be any better. My understanding is that even on native platforms, Qt does a lot of behind-the-scenes rendering computations that then gets painted out as a pixel array. If that's true, that could explain their insistence on doing the same thing here, but... that doesn't make it any better.
Don't use a WASM compiler that spits its entire interface into a canvas as a pixel array. I've seen a few people call this Flash 2.0, and honestly I think that's doing a disservice to Flash. Flash had better accessibility controls than this.
[0]: http://qt-webassembly.io/designviewer/#ClusterTutorial.qmlrc