Hacker News new | ask | show | jobs
by firecraker 1356 days ago
Qt in the browser sounds cool.. but feels reminiscent of shockwave..
3 comments

While some people were too busy cheering the death of plugins, they were being bought back to life thanks to the rejuvenating powers of WebAssembly and WebGL.

All of them already have some kind of support in WebAssembly.

Still, overall better than the situation of having to install a plugin that may or may not be available or working fully on your system. Plus security concerns of running sometimes obscure binaries on your system to access web content.
You can compile heartbleed to WebAssembly, and there are ways to exploit memory corruption to change observable behaviour.
I'm aware it's not impossible to exploit the current plug-in free browsers we have now. It's still objectively better than before.

Not that I'm satisfied with the current state of browsers mind you. I just think not being forced to install someone's binary blob to look at web content is a net benefit.

Except you can't disable WebAssembly, and you can't control how a SPA is implemented, see Figma for example.

Now you can enjoy Flash like ads using WebAssembly + WebGL, making it all a Phyrric victory.

WebAssembly can absolutely be disabled:

Chromium-based: --js-flags=--noexpose_wasm

Firefox-based: about:config javascript.options.wasm = false

It's inevitable.

The only way for Qt to compete with Electron is to become Electron.

That feels like to opposite, though. Electron brought the browser to offline/"native" apps. It literally packaged webkit in a way for web tech to be used as a desktop app, whilst Qt in the browser (and Shockwave, Java Applets, ActiveX et al) were bringing the desktop to the browser.
Electron brings non-native content to the desktop. Qt in the browser brings non-native content to the web.

Now we can have broken accessibility, usability, broken theming, and bad integration on both platforms, yay!

Yeah I don't think anyone would really choose to write a new web app with Qt. I assume the target market is people that want to port their existing Qt code to the web. It could also be useful for demoing Qt apps.
Yep, I do it with https://ossia.io (https://ossia.io/score-web) to make the occasional demo ; it's pretty alpha and drag'n'drop still seems to kill it but every Qt release has made it better without me having to do anything.. looking forward to updating!
How do you do it? I didn't know qt web was a thing? I remember I heard about one project but that was gpl i think
At one point Nokia pushed the idea that you would write Qt apps to run on their cloud; they had a few actual customers doing it too. I don't know if the current owners kept going with the concept.

It makes sense, from the perspective of shops who invested heavily in upskilling on Qt, to reuse the knowledge to build web apps.

ossia score is GPLv3 itself

regarding the how.. Qt provides a CMake wrapper which sets up the relevant flags automatically so with CMake/Qt projects it pretty much just works. Here's my build scripts:

- https://github.com/ossia/score/blob/master/ci/wasm.deps.sh

- https://github.com/ossia/score/blob/master/ci/wasm.build.sh

drag and drop requires configuring your app with asyncify option. https://doc-snapshots.qt.io/qt6-6.4/wasm.html#asyncify
I think this is how I do it (https://github.com/ossia/score/blob/master/ci/wasm.build.sh) but it still stops working after some time
Don't underestimate people's reluctance to learn new stacks.
I think the better use case for having Qt in the browser is if a web app could benefit from sharing code with a mobile or desktop Qt project. Other than that, yeah, I'm not sure why anyone would use Qt for web apps besides preference.
Easier testing and deployment. Develop and test one platform. Deployment is a url.