For the library world, WASM aims to offer an alternative to dynamically loaded C libraries - which it doesn't really do yet.
For the container world, WASM aims to offer an architecture agnostic universal binary format that can be run anywhere - which it doesn't really do yet.
For the web world, WASM aims to offer ~~not exactly sure~~. People say it's not a replacement for JavaScript and refuse to consider it as at least an additive alternative.
So I guess WASM in the web is something like an enhanced Web Worker that allows hot paths to be optimized using lower level languages?
That said, WASM in the browser doesn't support threads (and likely won't because of restrictive security permissions on the web making memory shared between threads impractical).
Perhaps the use case for WASM is simply enabling the consumption of existing C/C++ libraries on the web (like ffmpeg) that would otherwise be impractical to port to JavaScript?
When you think about it, WASM was announced almost a decade ago. Golang had just released version 1. JavaScript didn't have Promises or ES Modules in the specification. Mozilla announced it was backing Rust and it had its first stable release. Feels like WASM hasn't really progressed that much in that time.
For me, I would love a world where web technology powered _applications_ (not blogs posts or static sites) were PWAs backed by efficient WASM implementations (think; Slack, Discord, VSCode, JIRA, etc). Instead we get everything written as Electron apps and even if you want to use WASM, you're limited to a single thread that can't even create a div.
I guess having amazing, efficient, cross platform desktop application experiences enabled by capable web technologies would compete too effectively with native apps, Flutter, WinUI or whatever other competing interests exist.
If anything, I would consider calling that scenario an actual "Web 3.0" - but it's probably a pipe dream at this point.
You can and this makes it appropriate for tech demos but it's a huge point of contention for engineers who are concerned about performance sensitive applications - particularly where boot time (TTI, TFP, etc) is important.
Further, deferring the loading of a wasm module to js evaluation forgoes the browser's ability to optimize based on static analysis, dropping launch optimizations.
Lastly, the added tooling adds an aspect of distrust. Web development is already saturated with complex tooling.
We cannot simply run `cargo build --target wasm32-unknown-unknown` and have it work. Additionally, if you want to code split you would need to split your application up into a wasm executable with dynamically linked wasm libraries - something that isn't supported at present.
> That’s… not true? It has been supported in all major browsers for years
At present, you must initialize multiple instances of a wasm module and pass a SharedArrayBuffer between those modules to share memory. This means threads are controlled in JS and not in WASM.
Additionally, ShareArrayBuffer is not supported in multi-origin websites - making it impossible to use in contexts like established applications which already use subdomains extensively (like Slack, Jira, etc).
For the container world, WASM aims to offer an architecture agnostic universal binary format that can be run anywhere - which it doesn't really do yet.
For the web world, WASM aims to offer ~~not exactly sure~~. People say it's not a replacement for JavaScript and refuse to consider it as at least an additive alternative.
So I guess WASM in the web is something like an enhanced Web Worker that allows hot paths to be optimized using lower level languages?
That said, WASM in the browser doesn't support threads (and likely won't because of restrictive security permissions on the web making memory shared between threads impractical).
Perhaps the use case for WASM is simply enabling the consumption of existing C/C++ libraries on the web (like ffmpeg) that would otherwise be impractical to port to JavaScript?
When you think about it, WASM was announced almost a decade ago. Golang had just released version 1. JavaScript didn't have Promises or ES Modules in the specification. Mozilla announced it was backing Rust and it had its first stable release. Feels like WASM hasn't really progressed that much in that time.
For me, I would love a world where web technology powered _applications_ (not blogs posts or static sites) were PWAs backed by efficient WASM implementations (think; Slack, Discord, VSCode, JIRA, etc). Instead we get everything written as Electron apps and even if you want to use WASM, you're limited to a single thread that can't even create a div.
I guess having amazing, efficient, cross platform desktop application experiences enabled by capable web technologies would compete too effectively with native apps, Flutter, WinUI or whatever other competing interests exist.
If anything, I would consider calling that scenario an actual "Web 3.0" - but it's probably a pipe dream at this point.