As flash have been unsupported on browser since its phasing out completed years ago, various html5 API provide pieces of the puzzle for its replacement. Nonetheless, these API and new standards are emerging technologies - some of them are still evolving/not mature. Therefore, as of 2022, there still appear to be a gap in terms of a robust ecosystem of well known library/framework/documentations for end-to-end applications.
There are notable exceptions though. For example, html5 game do have frameworks that worked these details out for the most part (and hide it under some abstractions). But not all media-rich application is a game.
Perhaps another concern is that this domain is diverse enough that there is no such thing as a "one-size-fit-all" approach.
Below I sketch one possible combinations, or piecing together, of disparate web techs. (Still learning - expect inaccuracies or even naivetee)
Context: 2D media app that involves raster components and so SVG alone is insufficient.
- At the top most layer, html5 Canvas is used to display the output to user.
- When rendering is needed, we call a service/web worker to do it. This has the benefit of running on a separate thread to avoid blocking (especially since it is going to be compute intensive. For interactive app latency matters).
- The Service/Web Worker hosts a webassembly module. Actually it calls the wasm function.
WebGL is an older and more mature technology than webassembly. Besides, as WebGL uses the computer's GPU, performance wise it is going to outdo wasm for graphic intense processing (duh).
However, WebGL is even harder to use/program than wasm, although libraries such as three.js does make it somewhat easier. Still, using them requires speaking in the languages of 3D graphics processing and awareness of the underlying hardware, which has a fundamentally different computational model than CPU (programmable pipeline).
It seems to be possible to mix wasm and WebGL, but given that both of them are already difficult to use in and of themselves, combining in this way is going to be a major challenge. It might be worth it in the most demanding/sophisticated application to fully exploit their respective strength.
Note: in the case of both WebGL and wasm, there is the consideration of the ability to reuse existing codebase in foreign programming langauge. Eg. some C++ libraries. This is however programming-language specific. Eg. this advantage diminishes if you're coding wasm in Rust.
I heard that wasm is heavily sandboxed and have no easy access to much of the browser's context. So how do you solve I/O?
Well, this used to be a major drawback, luckily situations are improving. In our case of canvas, it used to be that you need to marshall the raw data out back to the JS layer first. But now with OfflineCanvas etc it seems to be possible to just interact with it directly inside wasm.
wasm itself has an interesting situation w.r.t. tooling. You basically need to use specialized tool to compile the code in whatever host programming langaueg you use into wasm modules. It should also produce some glue code to make it possible to call from JS side (some magics are involved here if I'm not mistaken).
Emascripten is the most famous such tool. Though for Rust there seems to be wasm-pack instead.
Finally, for the wasm-Web worker integration, there are library for that:
https://github.com/mbasso/wasm-worker
(Seems to be pretty old, not sure if it works or not)