So, you're saying I could use a QTWebView in the browser?
What would be the security model of such a browser environment? Maybe like an iframe?
I suspect similar to wt c++
Qt for WebAssembly Technology Preview
21–30 of 196 posts
Re: Qt for WebAssembly Technology Preview
#22So, you're saying I could use a QTWebView in the browser?
No no no. Obviously you should compile your existing Qt application to webassembly, put that in a QTWebView and have that be your application.
Re: Qt for WebAssembly Technology Preview
#23This reminds me of a time, when I used to work for a very large company. After an unfortunate amount of meetings and powerpoint presentations about ubiquity and compatibility, we ended up putting a Flash VM inside a Java client, to read HTML. Oh boy, sometimes you just walk away from a crash, but you're never the same.
I think this is misdirected criticism. WebAssembly runs at almost native speeds on a single very lightweight "VM".
Re: Qt for WebAssembly Technology Preview
#24So, you're saying I could use a QTWebView in the browser?
No no no. Obviously you should compile your existing Qt application to webassembly, put that in a QTWebView and have that be your application.
And we will run this all on nebulet, an OS being written for a pure web assembly user space [0].
But seriously, you say this like it's horrible, but a bytecode/VM that allows us to abstract over code that runs in a browser/code that runs a native app/code that runs in a device driver is really exciting. The fact that it allows infinite nesting is a inevitable mildly beneficial side effect to having interoperability.
Re: Qt for WebAssembly Technology Preview
#25This reminds me of a time, when I used to work for a very large company. After an unfortunate amount of meetings and powerpoint presentations about ubiquity and compatibility, we ended up putting a Flash VM inside a Java client, to read HTML. Oh boy, sometimes you just walk away from a crash, but you're never the same.
I think this is misdirected criticism. WebAssembly runs at almost native speeds on a single very lightweight "VM".
The problem here is probably more download time, not run performance.
Re: Qt for WebAssembly Technology Preview
#26This (assuming it's Qt Quick) opens the door for a competitor to HTML for web apps.
Except this looks like it would be a big download, wouldn't it? And how would this UI interact with assistive applications like screen readers?
Re: Qt for WebAssembly Technology Preview
#27Say what you will, we need these kind of projects in order to push forward WebAssembly (and eventually JavaScript may not be the only dominant language for front-end web development). I'm curious how much of the canvas they're taking advantage of if any of it. It's quite exciting. I might wind up porting one of my existing Qt applications just to try this out and see what that would be like.
Wasn't it more like: most people know JS so everything (server, mobile/desktpp apps, etc) was made with it.
And not like: JS is so shitty, better we make everything with it, even if there are better alternatives.
?
Re: Qt for WebAssembly Technology Preview
#28I'm seeing a ton of snarky comments, but isn't this what exactly WebAssemly is about (which I see people praising everyday as it opens up possibilities)
I had the impression WASM was about writing parts of web apps in it, so they get more performance.
I can't imagine many people would like to download a 60GB AAA game or something like Photoshop to run it in the browser.
Re: Qt for WebAssembly Technology Preview
#29Earlier quoted context omitted.
I think this is misdirected criticism. WebAssembly runs at almost native speeds on a single very lightweight "VM".
The problem here is probably more download time, not run performance.
WebAssembly is binary packed bytecode and generally takes much less space than UTF-8 JavaScript source files.
Re: Qt for WebAssembly Technology Preview
#30Earlier quoted context omitted.
See also https://www.destroyallsoftware.com/talks/the-birth-and-death... You jest, but this sort of thing probably is the death of almost all native software, sadly.
There are some things we mourn. Nobody mourns cross platform distribution of native apps. Anyone who does hasn’t had to manage the insanity of installer apps and of papering over a million different OS versions and app versions. It’s 2018 and we still don’t have a common, wide spread, OSS framework for self-updating native apps that runs on all the major desktop operating systems. And let’s not even go into app store…
The best native apps aren't cross platform. The worst native apps often are (at least from a mac perspective). We are simply moving to the lowest common denominator for all platforms, to the profit of business and the loss of the end-user. We can now develop software that is equally shitty for everyone much cheaper than we could before.
Is that the end of the world? No, of course not. But we aren't building better tools over time--for instance, google docs is distinctly worse than the word I used on macintosh back in the 90s for all the use cases I care about. So is pages! All this software is more complex, and generally for little benefit.