A more likely and practical outcome is using the HTML5 DOM UI instead of Qt, and JavaScript instead of Python, etc. Native web technologies the browser already has support for.
There is already a movement towards using the DOM for web game UI instead of canvas, for example this recent article makes some compelling arguments: https://blog.pocketcitygame.com/5-reasons-to-use-dom-instead...
Using web platform technologies can actually reduce the download size over native apps. In the game I am working on, written in C and compiled using emscripten, as a rough measure, the equivalent program compiled natively totals an executable size of about 2 MB, not including texture resource data. An optimized asm.js build is about 950 KB and WebAssembly only 580 KB, this includes the .html shell, .js loader, and .wasm binary itself.
This is not a completely fair comparison because I compile out some native code not relevant to the web, and vice versa, but here are a few specifics of where I believe the gains may come from:
curl: the native C app uses libcurl for fetching resources from HTTP and HTTPS servers, but on the web, we have XMLHttpRequest and HTML5 Fetch. Emscripten provides the built-ins emscripten_wget() and emscripten_async_wget() for these purposes. No need for shipping HTTP and SSL stacks because the browser already has it included.
glfw and glew: libraries for wrangling OpenGL, emscripten has its own implementation which largely simply bridges to WebGL or other HTML5 APIs, a very thin layer. SDL, too.
databases: many apps bundle their own copy of SQLite, often as the single C file amalgamation. I used to, too, even through emscripten and it worked fine (there is even a pre-packaged emscriptenified sqlite.js), admittedly I haven't looked into it much yet but the web platform supports IndexedDB built-in, no extra dependency needed.
JSON: how many JSON encoders/decoders are there out there, separate copies in all of the apps? On the web, you can rely on JSON.stringify and JSON.parse (from JavaScript, but all functionality is bridged through WebAssembly anyways).
We may see a resurgence in "small C libraries" targeting WebAssembly. There is a growing trend of header-only libraries, especially the popular stb: https://github.com/nothings/stb#stb_libs and there is a growing list here: https://github.com/nothings/single_file_libs I consult to find tiny libraries appropriate for linking into a web-based C application. lodepng (for decoding PNG images) and miniz (for reading and extracting zip files) are about the only substantial dependencies I have beyond what is in the emscripten standard library. Everything else is provided by the browser, the web has grown to a surprisingly powerful and complete platform.