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.
The output reminds me of Flash. That's not necessarily a bad thing considering how good Flash was at some things (especially without the security holes) but still, it feels wrong.
The technology itself is amazing, and as long as it was used for replacement for desktop and mobile ask it would be great, but I have the same fear that it might replace proper web sites.
Hopefully the need to be discoverable by search engines will mean that most sites will still use the dom, but at some point Google might provide a proprietary crawling interface...
I don't believe it's meant to be a replacement for interactive web pages but as a browser-based viewer for QT's file format. With that in mind, your qualms aren't quite applicable here.
It's not enabled in the properties of the elements by default, so it's not selectable by default because it's a GUI, not a web document. Web developers have forgotten what an app is while trying to write apps by using tools meant for Web documents.
There was a TextEdit example where you select text.
"Please try out the Qt Design Viewer, but keep in mind that this is a technical preview. Bugs and issues can be reported here. The viewer application is fully open source."
If I make a form in QT and compile it to Webassembly with this tool, will I get native Windows form elements on Windows and native OSX form elements on OSX? Or will I get the browser form elements? Or QT form inputs regardless of the OS I'm viewing it with?
At least there is nothing to install for WASM. Plus you're getting updates when the browser updates and don't have to worry about updating other things independently.
I do agree there is some potential for misuse here but that's pretty much true of any web based tech in the last couple decades.
^ this is the single most important point to make here. The design issues with Flash were not the reason it was abandoned. It was abandoned because it was not a browser standard, and Apple decided not to support it with iOS. The idea of rich, interactive content that lies beyond the scope of html is still a great idea, even if the some of the results were kinda crazy.
I loved Flash for those things. However, a majority of my interactions were websites for things like restaurants where I couldn't copy/paste basic things like the address, didn't have progressive loading, search, bookmarks, scrolling and the performance was abysmal. Flash could technically do all of those things, but never happened in practice.
html5 was supposed to bring all the cool things Flash had without most of the annoying things I mentioned above. I saw some cool tech demos years ago, but for whatever reason (lack of good artist tools?) I haven't really seen much in years.
Then you need to have a better look into Adobe shops.
As part of the pro-Flash crowd I am happy that Animate is not the only option, we have Blazor, Unity, Qt and plenty of other stuff in the process of taking advantage of WebAssembly, WebGL and eventually WebGPU.
> Plus you're getting updates when the browser updates
Yeah, this is so great. I love how when Chrome updates the first time I hear about it is when people are calling me because some website they rely on is broken by some arbitrary change.
> Does someone know if WebAssembly support is available on the open-source Qt?
it is. I know that on windows the toolchain is available directly from the online installer, but I think that it isn't on linux. It's a quick build however :
git clone qt5 https://code.qt.io/qt/qt5.git
cd qt5
git submodule update --init qtbase qtdeclarative
mkdir ../build
cd ../build
../qt5/configure -xplatform wasm-emscripten -nomake examples -nomake tests -opensource -confirm-license -prefix /opt/qt5-wasm
make -jwhatever && make install
It is open source. You will need the emscripten compiler.
https://wiki.qt.io/Qt_for_WebAssembly
It is possible to use cmake, it is a bit of a pain to set this up though.
Remember that WA lives in a black box with nary any access to networking, other APIs etc. and communication in/out of the block via shared memory is very, very low level.
QT is still heavily reliant on QMake in reality, but that should be a small part of the decision equation.
As someone who is completely ignorant about QT, what are the arguments for using it? I looked at their product page and it seems incredibly expensive. Why pay to develop for a particular platform?
I would definitely call Qt a platform, just like Java is a platform (it actually has a lot of similarities to Java). The platform happens to run on multiple other, lower-level platforms.
It simplifies developing cross-platform native apps. Imagine electron apps, except it uses less resources, and has a consistent look and feel with the rest of the OS. You also don't have to pay if you don't want, but Qt is licensed under the LGPL so you have to be aware of what you can and can't do under that license.
No, you only have to make your proprietary compiled object files available. what lgpl requires is for the user to be able to update the LGPL parts - so Qt in this case and this does not need your code.
Correct. As long a linking is dynamic, Qt doesn't care how/where the Qt libs are distributed. They typically recommend bundling for Windows and using system packages for Linux.
Every Qt application I've ever used has been ... off.
Granted, it's closer than Swing. That's a pretty low bar. We need to either start qualifying this ("it's a good GUI toolkit for a cross-platform one"), or accepting that this is a scale (10 is "actually native", 0 is "just looks like Motif everywhere"). I'd give Qt 8/10 -- it's pretty good, and the screenshots look great but after a moment using it I'll say "wait, I think I know why everything feels just a little bit off".
As a counter to that, you've only got one set of data points, the ones you noticed. Potentially there are dozens or hundreds of well-made Qt apps that you haven't noticed, and so they by definition wouldn't be a part of your dataset.
If you want to develop to responsive cross-platform application, it's the best choice. It's basically industry standard in embedded platforms at this point.
It's not expensive is you have a business that makes any money. It's free if you don't modify qt source itself and follow LGPL.
It's expensive because it doesn't really have any competition. Your car's infotainment center was probably written using Qt.
Electron is eating a bit of their lunch but it lacks a few features yet, uses a lot of resources comparatively, and doesn't support the same targets or developer communities that Qt does.
How well does this play with web searches? Do I will be able to find a Qt application searching for words on its interface? Do we need a store like https://addons.mozilla.org/ to find the content?
And, mainly, is this going to substitute all web information or just will move desktop apps to the web?
I would like that documents continue being documents, and applications should be applications. But, like with Flash, many people may disagree on that point.
Unless hooks for that are added in the future, it isn't searchable, and it's a platform for apps. It uses WebGL for display, not the DOM, not even Canvas.
I use and like Qt, but I also think that documents should be just documents - without gratuitous JS framework bullshit.
Genuinely curious how websites built in this fashion will adhere to accessibility guidelines, especially with companies (like Target[0]) getting sued recently.
Additionally, can these sites be responsive such that the content will look good on desktop and mobile?
I sometimes wish the effort that went behind QML went somewhere else. That to be said, clearly other folks are finding benefits in it, just not for the app I have to support (yet).
The statement is overly harsh, but essentially correct.
QML simply lacks a lot of features, and C++ hooks are often required to make it work well.
Oddly, you need to launch a QML app using at least a little bit of C++ no matter what. That's not a problem for mot pro devs who can hack a little bit of C++, but it's actually problematic for most others. Even 10 lines of C++ is too much for most devs who don't know it. It's like having to speak 10 lines of Russian. The docs are often tricky and ambiguous about how to start and launch apps as well.
History repeats itself. We had Flash. It was amazing back then. After while, people realized that Flash is actually against core philosophy of web - easy information sharing. Flash sites were poorly indexed by search engines, power hungry and with lot accessibility issues.
Not qt is trying to do basically same what Macromedia did with Flash. Enable rich binary components on a web, with exactly same issues Flash had.
Don't take me wrong, webassembly is great, so is qt. Maybe you can create very specialized electron app with that, but please don't overuse it for generic web content.
My 'hot take' I've had for a while is that most applications, including native ones, are just interactive documents.
I can count on one hand the number of native apps I use that couldn't have their interfaces trivially represented by HTML and CSS.
If you're not building Blender, Photoshop, or Maps, odds are pretty good that your native app is just a document. And even in the case of apps like Photoshop, only the main view is special -- everything else is just menus and toolbars.
People draw a hard line between a document and an app, and I've just never been able to see that line.
If I were able to not see that line, my life will be a lot easier, maybe you can help me with it. Can you try to define, in your head, what do you call a "document"? (Doesn't have to be a mathematical definition)
P.S. Just in case it does sound like it - no, I'm not trolling. That ^ is a genuine question.
It's not my intention to be terse or dismissive, but I'm going to give a very short, incomplete answer because a long one would take too long for me to write. I would need to think a lot more to come up with something more descriptive.
If I can translate your application's current state to an org-mode document (or any other hierarchical document format) without losing any significant information, then your interface is an interactive document. Maybe your backend is better suited for C, or needs native capabilities or something. I don't care about that. The actual interface itself is just hierarchical information.
HTML is just a way of organizing information into a tree. It's not a layout tool (even though some web devs treat it like one), it is a display format. CSS is the incidental styling that gets applied on top of that format.
For example, I have KeepassX sitting open in front of me. It has a row of buttons on the top, a tree view, and a currently selected record in a table.
When I click one of the entries in that table, I'm taken to a new interactive document (basically a form) that has some fields I can change to edit my password. At no point in KeepassX do I ever see a state that couldn't be described purely in a format like org-mode.
So now I try to resize KeepassX, and when it gets to below about 400-450 pixels, it refuses to get any smaller. It's not responsive. This is because it was written in some native format that was only thinking about grids and pixel-perfect positioning, and the idea that rendering content was a different concern than rendering style never occurred to anybody.
A number of native formats like GTK already use XML to lay out their interfaces. The only difference is that they're using XML as a layout tool and not as a display target. But for an app like KeepassX, rendering to an XML-like format would be a strict improvement over whatever the heck it's doing now.
This is my feeling too. 'This ship already sailed'
It was the fight to turned the document, information transparent world of the web into a application you run on the browser where you dont care about the output as a information piece, but only how the pixel have rendered.
The browsers themselves together with the companies that drive them, killed the web on its conceptual level, and now the browser is just a multi-platform engine to render apps that are located in remote servers (and lets not forget how they will push for cloud stack here, given the profits it will make for them).
The web got corrupted into its core concepts, and now is just a shadow of its former self.
I'm not very knowledgeable on this topic, but it seems weird that WASM files would need to be loaded into an html page in order to render.
I would like to see a future where you can just open a WASM file in the browser and it will compile/render to the screen as an application. This would alleviate the pressure put on html pages to behave as if they're something they're not. It would let html go back to, as you say, its core responsibility, which is to be an interactive document.
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