>Yes, let's throw away all the great toolkits (Qt, Cocoa, etc.) that we have, which have developed into an extremely stable base over the past 20 years, with look & feel consistency between applications, and replace it by some experimental browser tech and constantly reinvented web frameworks. </sarcasm>
I don't think you understand how WASM works. Qt can compile and work on GLES 2.0 (WebGL) and WASM is just a sandboxed bytecode that maps closely to CPU instructions and C memory model, meaning you could run Qt apps inside of WASM/Browser sandbox, and given the small size of WASM binaries compared to ASM.JS that's feasible even considering the size of Qt.
Browser with WASM is just a sandbox on top of native APIs and some chrome - it's essentially the app model for desktop with low friction distribution - you have back/forward, easy switching/kill, resource sand-boxing, etc. just like you do on your phone.
I do. And most of this you could already do for a while without Web Assembly, either native using e.g. NaCl or compiled to Javascript/Asm.js (Emscripten). Running Qt in the browser it not some future, it is already possible.
The problem is that if you go that route, you lose a lot of platform integration. Moreover, you throw in another layer for what is practically a solved problem (the Linux kernel has all the necessary bits for sandboxing, which Chrome et al. also use for sandboxing).
it's essentially the app model for desktop with low friction distribution
As someone who distributes a Qt application on Windows, Linux, OS X. I don't need this. I just need to be able to distribute one app bundle that works on all Linux distributions. OS X and Windows are already a walk in the park. And by having a native app, I have proper integration now (e.g. Full Screen, Dock, and file association support on the Mac).
just like you do on your phone.
My phone uses native apps, thank you.
(Though is it is in the process of switching to LLVM bytecode.)
>Running Qt in the browser it not some future, it is already possible.
It's possible, it's just not feasible - NaCl is chrome only and has some limitations around distribution and the tool-chain is very specific (Google provided port of Clang/LLVM), asm.js/emscripten sucks both in parse/compile time and in download size.
>Moreover, you throw in another layer for what is practically a solved problem (the Linux kernel has all the necessary bits for sandboxing, which Chrome et al. also use for sandboxing).
What you get is a cross platform layer. You can then add in platform specific extensions and code around those as optional features. The only systems that lets you do something similar right now is full blown VMs like JVM/.NET and this is lower level, potentially allowing more languages to target it.
Like you said browser will just wrap the native interfaces to provide compatibility - low friction cross platform app development/deployment.
I don't think you understand how WASM works. Qt can compile and work on GLES 2.0 (WebGL) and WASM is just a sandboxed bytecode that maps closely to CPU instructions and C memory model, meaning you could run Qt apps inside of WASM/Browser sandbox, and given the small size of WASM binaries compared to ASM.JS that's feasible even considering the size of Qt.
Browser with WASM is just a sandbox on top of native APIs and some chrome - it's essentially the app model for desktop with low friction distribution - you have back/forward, easy switching/kill, resource sand-boxing, etc. just like you do on your phone.