WebAssembly Playground(observablehq.com) |
WebAssembly Playground(observablehq.com) |
A few years ago, I used a WASM demo website which can use a WASM version of ffmpeg to mux audio and video into a file (transcoding obviously wasn't practical, at least not at that time), and I was very impressed. I can see lots of potential of it.
But I still haven't see much usage of it even today.
(To be totally honest -- i'd rather it's not popular because it would make debugging websites/web applications close to impossible; but that's besides the point.)
Most websites are just that - "sites". Complicated softwares that _need_ to be run on the web are already leveraging WebAssembly to an extent.
1. Figma (Design tool) uses Webassembly underneath for graphics operations.
2. Zoho Writer (word processor) uses WebAssembly for leveraging ICU capabilities (grapheme splitting, sentence splitting, core algorithms, etc)
3. Google Docs (word processor) uses WASM for offline proofing
These are just examples. If you look at the pattern the transition isn't happening in a way that all softwares are entirely targetted for webassembly. It's happening in little steps leveraging webassembly to parts of the product where it makes sense. This I believe is how the transition should be as opposed to jumping all the way to webassembly just because it's shiny.
So in a way webasm/asm.js is already allowing whole new categories of webapps we take for granted now.
Afaik, WASM is only used by Sheets [1].
[1]: https://2024.wasmio.tech/sessions/webassembly-at-google/
sandspiel is quite popular and is built using WASM: https://sandspiel.club/
Google Earth - https://blog.chromium.org/2019/06/webassembly-brings-google-...
Ruffle (the "make Flash run safely" tool) - https://ruffle.rs/
Ableton's Learning Synths - https://learningsynths.ableton.com/
etc etc. It's just hard to tell when something is using WASM when it "just works" and is indistinguishable from optimized JavaScript
(cough also my WIP game is being built in WASM.Rust, https://ant.care/ https://github.com/MeoMix/symbiants I've been enjoying the experience!)
Me (and others, I'm sure) are currently waiting for WebGPU [1] to land in Safari so it will make sense to target it.
WebGPU allows for simplified porting of desktop games to the web, such as WGSL shaders [2]
WebGPU will be the next big thing [3], and currently it is enabled on Chrome Windows/macOS, and can be enabled in Firefox Nightly with a config setting.
There's also an issue with limited language support. For example golang still has some stuff left to stabilize around the WASI, and the resulting binaries are rather large.
In rust, things look better. I can compile a release of my game to about 8MB .wasm file, which gzipped sits at around 3MB. Most other tooling I have looked at produces far larger wasm binaries, which makes it a no-go for mobile apps.
Hopefully, 2024 will be the year of WebGPU!
1: https://caniuse.com/?search=webgpu
2: https://www.w3.org/TR/WGSL/
3: https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
1. It's too damn hard to get data into and out of wasm modules. The component model is addressing this but it's sprawled out into literally rebuilding "worlds" and turning wasm modules into sort of lightweight virtual machines. I wish there was just more of a focus on getting data into and out of modules first.
2. Lack of GC which has made languages like js/python/jvm/c# unfeasible. WASM GC is just now available and hopefully ship compilers can target and build wasm modules that aren't so large in not too distant future.
Once we are past these 2 items, wasm can run free and really should become the final unit of deployment.
edit: I also suspect that like the jvm which started as a client tech, wasm will find more use on the server side, than on the client side in info/business type software.
As someone who works on the Component Model, this perception is interesting to me, can you explain your thinking a bit more? From my perspective, getting data in and out of modules is indeed solved. Worlds are a type signature that describe what datatypes and methods are available in a particular embedding, with standards for command line and http proxies, but easy to define whatever your situation requires.
I've had success running F# (a .NET language, like C#) on WASM using Bolero: https://fsbolero.io
#1 is a pet grievance of mine though. The intentional choice not to build mmap or read-only pages into the WASM memory model is really frustrating.
If they weren't feasible, there wouldn't be several implementations shipping for several years now.
Just like a typical hardware CPU that isn't a *Language XYZ Machine", GC implementation ships with the runtime.
From my understanding, there are 3 answers here.
1. Most spaces do not need WASM. You don't necessarily see speed improvements since usually your JS and WASM (in the browser) are compiled into the same thing.
2. WASM is very good at bringing tools to new spaces. The biggest limitation here is in both tooling and education. It is not trivial to compile something like FFMPEG for the browser. Improvements to the WASI standard are helping here.
3. WASM is starting to see use in different spaces. For example, as a containerization format for efficient sandboxing.
Yeah, I agree with this. I have a few ongoing fresh-start projects that are being built with WASM as the primary build target. And like you said, the tooling is definitely not great. Plus the load times for some wasm binaries are pretty slow.
There is a more detailed overview here: https://www.midokura.com/why-webassembly-is-perfect-for-tiny...
[1] https://anoopelias.github.io/posts/wasm-micro-runtime-with-r...
It solves a problem that most web developers don't have: running performant code in the browser. It cant manipulate the DOM natively and so most developers have no use for it.
Additionally, the kind of developers who would like to be able to write C/C++ or other compiled languages in the browser are not usually web developers; most of the frontend developers I know are highly specialized in their frameworks or fields. They rarely, if ever, venture outside of frontend development and the kinds of technologies they need are not high performance WASM code but type safe and runtime negligible typescript code
WASM is a technology for software engineers to be able to target their programs for running in the browser, not a technology meant to make frontend developer lives easier
Writing as one of those people trying to make my programs run in the browser, the most painless way still seems to be "write it in js/ts." Which sucks. Doubly so if it's something I have already written in my language of choice, and triply so if it contains dependencies I didn't write. And that's practically every project I've wanted to run in the browser.
> By itself, WebAssembly cannot currently directly access the DOM; it can only call JavaScript, passing in integer and floating point primitive data types. Thus, to access any Web API, WebAssembly needs to call out to JavaScript, which then makes the Web API call. Emscripten therefore creates the HTML and JavaScript glue code needed to achieve this.
> Note: There are future plans to allow WebAssembly to call Web APIs directly.
https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...
From one perspective, it's a big success in that it's deployed "everywhere", has multiple implementations, and seems to work the same way everywhere. Many language toolchains target it, although there are varying degrees of success / performnance.
From another perspective, it's a "failure" because it's not the end of JavaScript, and it's not an operating system.
There were a number of people/organizations promoting as such -- saying it's basically going to take over all of computing, and be both the foundation of all languages and the foundation of operating systems. That seems a bit silly.
1) Tools that run docker containers and serverless function services (like AWS lambda) to support providing a .wasm files instead
2) Garbage collection in the runtime to make GC languages easier to port to wasm
3) Dynamically typed languages (NodeJS, Python, Ruby) being able to compile to webassembly directly instead of porting the runtime to webassembly and then running the code through the runtime. This is a big ask though, basically needs to redesign the runtime completely
4) wasm-DOM bindings will enable other languages to do HTML rendering which will require new web frameworks for every language that wants to take over the space from JS. This will lead to (even more) fragmentation of the web ecosystem
5) A new wasm-first SDK (unrelated to the DOM) for building cross platform applications. I can see this taking off only if it is built-into the browsers and backed by some standards committee, so not very likely I think
6) Something like the Interface Types proposal ( https://github.com/WebAssembly/interface-types/blob/main/pro... ) becomes a thing allowing wasm programs to be consisted of modules written in several different languages and being able to call said modules with low or 0 runtime performance hit (and of course, no compilation to multiple CPU archs). So much of programming ecosystems are locked to specific languages (like data science with python) when there is little technical reason for it be like that.
* wasm64: allowing more than 4gb RAM usage
* wasm virtual memory: allowing real memory allocation/freeing from wasm outside of the monolithic memory model
Both of these things are necessary for many complicated applications to run inside the browser seamlessly at high performance, both of these things have been on the WASM horizon for years and have made little or no progress.
GC strings worked for a while in Chrome, but the "test has ended"
This matters not just because of aesthetics but glue code removes the potential speed advantages of wasm.
That being said, one thing that's potentially holding back developer adoption is that, in its current state, wasm is best suited to low-overhead languages like C, C++ and Rust. And then there's the fact that most of the code that runs in the browser is UI code, and it'd be hard to justify writing your frontend in Ruby or Python, which would mean that the browser download a big wasm blob just to write your code, worse performance than JS once it starts running, and a much less stable ecosystem.
WebAssembly and Back Again: Fine-Grained Sandboxing in Firefox - https://hacks.mozilla.org/2021/12/webassembly-and-back-again...
Neural Machine Translation Engine for Firefox Translations - https://hacks.mozilla.org/2022/06/neural-machine-translation...
I think it's the focus on native apps. There's isn't exactly a benefit of WASM when you have a native app.
I was kinda hoping all the complaints about app stores would push people back to web apps and then I think you'd see a surgence of WASM. I guess Apple/Google gives apps too much tracking ability on native apps compared to web apps to make it worth it to re-do the app thrice (Android/iOS/Web Desktop) instead of just twice (Mobile Web/ Desktop Web).
- CPU features and system calls. Native code can leverage specific CPU features to gain performance. It has access to files and the network via OS system calls. Code compiled to WASM runs inside the WASM sandbox. It makes code slower. Getting data to/from the WASM code is harder.
- The WASM engine is right next to a “good enough” alternative (JS).
We insert the data into the database as we collect it, then we query the database for showing charts with the query parameters (time-range, parameters to plot, etc) based on the UI controllers. We also use its built-in parquet export functionality. It works great.
Oops.
337.35kB, 5 imports, 29 exports https://modsurfer.dylibso.com/module?hash=2c72ee42bd9430029d...
29.77MB, 27 imports, 1215 exports (!) https://modsurfer.dylibso.com/module?hash=2a466f0e990329d323...
18.59MB, 25 imports, 1 export https://modsurfer.dylibso.com/module?hash=36419ed20201176522...
Combined with the fact that google docs support proofing for those languages offline, it's easy to guess how they achieved it.
"Since only numeric values can be exchanged between the WASM module and the JS host, any JS native objects the WASM side might want to be working with must be managed manually in JS. "
Could you please provide links/info for how to do so? I want to be able to learn how to use it, but without this ability it seems entirely useless for me.
The document links to a repository talking about garbage collection, but I couldn't find where they're discussing opening up to Web APIs. Any ideas anyone?
For what it's worth I don't think 3MB is extremely large anymore, as several popular websites already weight in 2-3 MB for a full page loads.
Examples:
* www.youtube.com = 3.3 MB
* www.tiktok.com = 3.3 MB
* www.instagram.com = 2.1 MB
That said, I would love to shave off more size off my wasm binaries :-)
Some notes I found just now seems to be in line with my results, though: https://github.com/bevyengine/bevy/issues/3978#issuecomment-...
[profile.release]
lto = "fat"
codegen-units = 1
opt-level = 3
debug = false
panic = "abort"
strip = "debuginfo"
[profile.wasm-release]
inherits = "release"
opt-level = "z"[1]: https://kobzol.github.io/rust/cargo/2024/01/23/making-rust-b...
I agree that 8MB seems high. I can generate a 6MB binary using `--debug` with `wasm-pack` so definitely for a more complex thing I could see 8MB. I think `--release`, `codegen-units = 1`, `opt-level = 3/z` are the three biggest things that affect binary size for me.
I don't think 8MB is that big a deal for a web game though. Like how large are the images? If you're going to dynamically load in like 50+ MB of assets then having an initial game of 8 MB is the small pole in the tent. I have my stuff setup as a PWA so once everything has been downloaded it takes 0 MB on the wire to open a second time; you could set-up the game as 2 binaries; one super-small one that just basically handles an opening cinematic and a larger one that can actually play the game which is downloaded while the cinematic plays (or is cached in future opens).
We just shipped 1.0, but this slightly older blog post goes into the architecture a bit more: https://devblogs.microsoft.com/qsharp/introducing-the-azure-...
https://docs.flightsimulator.com/html/Programming_Tools/WASM...
It should also be future proof should they ever do a native ARM build.
Wasm was never intended to be used on every web page, just like the Video element wasn't.
The advantage of shipping an encoder in WebAssembly for is that you don’t have to rely on the browser supporting the specific codec you want. e.g. Safari and Firefox don’t yet support WebCodecs at all, but do support WebAssembly.
For a small taste,
"Meet Leon - superfast GPU-accelerated (WebGL) mpeg1-like video decoder in JavaScript"
https://www.easy-bits.com/mpeg1video-decoder-webgl-gpu
See mpeg1video-decoder-webgl.js on developer tools.
For example say you have some data like (eg. string "abc123") in host memory and then pass into module A which then reads/operates the data, and then returns some other data to the host. The host then calls into module B passing the original host data and data returned from call to module A. Can that original host data be shared efficiently and managed by WASM GC between modules?
I think incremental progress is generally great, but since we already have 'all of .NET' in WASM by shipping our own GC, end users seem like they wouldn't be happy with 'we use WASM GC now and all of your code is broken'
EDIT: We also have dependent handles in a few places, and I'm not sure how you'd do those without a more sophisticated GC. But it's probably possible and they're at least not used as widely as WRs.
Of course, without WASM, we'd be missing out on lots of cool software that was previously stuck on desktop/native. But I'm not entirely convinced it was the right path.
The MVP implementation of SIMD.js grew to about 10% of V8s entire codebase, just for the bare minimum "it runs" support without optimisations.
Maybe not. Someone could have written a backend for GCC and/or LLVM that targets JS in the same way that Emscripten targets WASM (with JS around the edges).
I didn’t realize enough of the work in decoding mpeg was paralellizable enough to do on the GPU, let alone in the constrained world of WebGL, but apparently it is.