[jillesvangurp]

That's so far the strategy. There are all sorts of garbage collected and interpreted things that run fine in wasm. But at the price of having to include a heavy runtime; which bloats the binaries. Not a showstopper for some things; like enterprise applications running in a fast network. But a bit of a blocker for normal websites.

Firefox and Chrome actually have support for the new GC and threading support in wasm. That's behind a few feature flags. But e.g. Kotlin's new wasm compiler depends on that and manages to ship binaries that are quite small. That compiler is also being used for a new experimental target for compose multiplatform, which is based on Google's Android Jetpack Compose and extends it to other platforms (IOS, Desktop, and Web). Web now comes in two variants: html & kotlin/js and canvas + wasm. The latter renders using the same graphics libraries used on Android and IOS but compiled to wasm. None of this stuff is ready yet because the tooling and frameworks are pre-alpha quality and it requires feature flags to be set by the user. But, this is starting to look like a nice alternative stack to things like flutter and react native for cross mobile, desktop, and web development.

The feature flags are likely coming off fairly soon. Safari is a bit behind. 2024 is going to be interesting. I'm guessing there will be a whole lot of activity around this in most commonly used languages and stacks.

[josephg]

> But at the price of having to include a heavy runtime; which bloats the binaries.

The other problem is that the "bring your own GC" model means if you use WASM in the browser, you end up having 2 garbage collectors for your program. And that makes sharing objects between javascript and the wasm bundle much more difficult & uglier. You essentially need to do manual memory management for any object thats shared across the wasm boundary to make sure its freed at the right time.

Having a unified GC means object references can be passed naturally from javascript to C# and back without any special code at the boundary.

[toyg]

> The latter renders using the same graphics libraries used on Android and IOS

That's annoying. I was hoping WASM would be a way to break out of the js/java/swift/ObjC stranglehold, not another baton to enforce such tyranny. It would be cool if they were targeting toolkits like QT instead.

[flohofwoe]

What does one have to do with the other though? You can use any programming language where the compiler supports WASM output, and any cross-platform graphics library that also has a (Web)GL or WebGPU backend.

(also not sure how Qt fits in here, but it also has WASM support: https://www.qt.io/qt-examples-for-webassembly, but IMHO Qt is way too bloated for this sort of thing)

In the end, WASM running in browsers can only use browser features that are also available to Javascript, e.g. for rendering that would be canvas-2d, WebGL, WebGPU or the DOM). But at least WebGL and WebGPU are close enough to similar native 3D APIs that you can share some code between native ports and WASM running in browsers - but it still makes sense to use a higher level graphics libraries which abstracts over the 3D-API differences, or alternatively use wgpu.rs or libdawn in the native versions (which are the standalone native WebGPU libraries used by Firefox and Chrome).

[jillesvangurp]

QT makes more sense with languages like C++ or languages that don't have their own UI frameworks. The whole point of running something like C# and Kotlin is using the frameworks common for those languages.