I suspect that Wasm on the web mostly just works and so we don't hear too much
about it. It is occasionally mentioned in passing though, usually as part of
another announcement. Well-known production users of Wasm on the web include
Dropbox [1], Adobe [2], Figma [3], and 1Password [4].
That reminds me of the time when Java applets had their high time.
I think that WASM in the browser will either largely replace JavaScript or will wither away like Java applets did. I fear there is no in-between and if it is only because no one will support two languages and ecosystems in parallel and in the long run. Not the big companies and certainly not the small ones.
There is an in-between, which is the world we live in right now.
JavaScript and TypeScript are great languages with excellent Web integration, whereas wasm is focused on pure computation (forcing it to bundle its standard library, for example). But wasm has predictable performance that is close to native builds, and sometimes you need that.
Very few web pages use only wasm. Most uses of wasm on the wasm are as part of a JavaScript site, for the parts where wasm makes sense.
I'd bet the current state is not sustainable and we will see a consolidation one way or another.
The danger for WASM is that JavaScript doesn't stand still either and we might as well see improvements that make the gap to WASM's selling points smaller.
JavaScript is being developed with the assumption that wasm will continue to exist. For example, JS is unlikely to get SIMD support because wasm can do SIMD in a cleaner way than JS can. (I am one of the people developing JavaScript.)
Rather, what we're likely to see is work which makes integration between wasm and JS easier - see, for example, the wasm string builtins proposal [1], the proposal for native support for importing wasm from JS [2], or the proposal for fixed-layout JS objects which would allow directly reflecting wasm-GC objects in JS [3].
> Where is WASM in the browser really used apart from crypto miners?
Art and design: Photoshop, Figma
Games: Unity, many other engines or components inside engines (e.g. Bullet)
Videoconferencing: Zoom, Google Meet, etc.
Productivity: Google Sheets
Other: Google Maps and many, many more. For example, here is a talk about how Google uses wasm in a large range of its products: https://www.youtube.com/watch?v=2En8cj6xlv4
Look, wasm is a supplementary technology, used where JavaScript isn't good enough, like all the examples I just gave. Those use cases work extremely well right now, and most users on the web benefit from wasm, even if they are unaware wasm is running on the page - which is how it should be.
That is exactly the success that wasm aimed for from the start.
People have made that same argument about Java applets 25 years ago and we all know how that panned out.
I see your point and I see and love the advantages of WASM but I doubt they will be enough to outweigh the burden to support two ecosystems in the long run. Support in the browser, as well as on the development side.
"That is exactly the success that wasm aimed for from the start."
If this is true WASM has been doomed from the start. If WASM doesn't set out to eat JavaScript's cake it will be left with the crumbs and slowly but surely starve to death.
The difference with Java applets from back then is that wasm was designed by web browsers in order to work well in them.
Java applets were plugins, which led to security issues, and worse, security issues not under the control of the browser. Wasm is a proper part of the browser.
Java applets had limited interop with JavaScript and HTML. Wasm is also somewhat limited there, but it was designed to at least have fast calls to JavaScript itself.
Java also has language-specific issues. Most native code that people want to run on the web is not written in Java or another JVM language. Wasm was designed to support compilation from C++, Rust, etc. (and it has recently added Java support too).
WASM is also great for enabling web apps to locally perform tasks that would be compute/bandwidth intensive if foisted upon the server.
E.x. the Cobalt video downloader has an experimental on-device video remuxing feature that uses FFmpeg (libav) compiled to WASM. It's a win-win for both the provider (who saves on hosting and bandwidth fees) and the user (who enjoys snappier functionality and enhanced privacy guarantees.)
>>Where is WASM in the browser really used apart from crypto miners?
Amazon's Twitch service (and by extension also AWS's Interactive Video Service product that uses all the same backend stuff). Their video player is either fully a WASM thing or has some WASM components, I'm not completely sure which.
See, that's the problem. As long as WASM is not able to pull its own weight and needs JavaScript to provide the spine it will languish in a niche or two.
Ultimately someone will decide that supporting two different languages and ecosystems is too expensive and not worth the marginal advantage and it will go back to JavaScript only.
We've been there and we have done that with Java applets.
The ease of interoperation with the host language (JS in this case) is a benefit, not a problem. WASM (without the WASI stuff) is fundamentally a portable assembler target, something that other languages can target, and all the baggage of browser and OS APIs can stay in the host environment and be selectively exposed to the WASM runtime. This makes WASM truly portable (again, without the WASI stuff).
nah, web developers that aren't doing simple CRUD are using interesting libraries powered by wasm without even care that it's powered by wasm: opencv, sqlite, duckdb, imagemagick, ffmpeg, ... anything AI/using GPU: tensorflowjs.
Those libraries are not something will be able to be JS only anytime soon, and no, Java applets has never allowed us to use C/C++ libraries on the web before.
Come up with great interface for web apps in WASM and the world will follow. Eventually browsers can just implement your interface directly without the javascript glue.
Maybe we should drop the Web from Web Assembly and call it something else?