WebAssembly Playground

https://observablehq.com/@chaosalchemist/wasm-playground

by ifree • 2 years ago

151 97 2 years ago

thrdbndndn2• 2 years ago

Question from someone knew very little in this domain: what stops mass adoption of WebAssembly?

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.)

csjh• 2 years ago

Mass adoption in what way? What benefit does the average CRUD web app gain from using some form of WebAssembly?

thrdbndndn2• 2 years ago

To incorporate something currently is only available in "native" program form is what I am thinking; like ffmpeg example above.

anoopelias2• 2 years ago

Not sure if WASM is there yet, but maybe the crud app can be built using a programming language that the developer prefers? Like Java, C#, Go, Rust, C++, whatever instead of JavaScript/TypeScript?

iamcreasy• 2 years ago

To piggyback this question - do developers have to find another way to access/update DOM update if using webassembly for web development?

vinnymac• 2 years ago

At the moment you need to send state between WebAssembly and JS contexts in order to manipulate the DOM.

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...

subarctic• 2 years ago

Do you have any stats from which you know that adoption is limited? The thing is, you won't necessarily know if an app is using it unless you're deliberately checking the sources in the dev console, so there could be a lot of sites that you're using that have wasm running in your browser without your knowledge.

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.

aredox• 2 years ago

Yeah, Mozilla and the Chrome team were pushing a lot for it, and spent a lot of engineering effort on it. So far it seems a strategic failure, both for Mozilla which couldn't afford such diversion of ressources, and for the Chrome team after NaCl's retirement.

taberiand• 2 years ago

I think there's a lot of inertia with the JavaScript-based systems and WASM represents a certain upheaval to that model. I have been toying with Blazor WASM recently though and to be honest, so far my experience has been very good, including debugging. I think WASM will grow quiet adoption over time, particularly for business apps.

SeanAnderson• 2 years ago

shrug It finds its uses. It's just not that overstated.

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!)

bennettbackward• 2 years ago

The official Windows video editor Microsoft Clipchamp[1] also extensively uses WASM for it's video export process.

[1] https://clipchamp.com/en/windows-video-editor/

rapnie• 2 years ago

Figma, Adobe. And (on the wasm server-side of things) Docker, Nginx.

modeless• 2 years ago

I bet it is used in a lot of ways people don't notice. In my site[1] I use wasm to run an ancient piece of code called SGP4 to propagate satellite orbits, but it's totally invisible to the user. Someone actually ported SGP4 to JavaScript but it's slower and the results don't perfectly match the original, so it's great to have the option to run the real C version (actually the original is Fortran but the C port is the standard these days).

[1] https://james.darpinian.com/satellites/

kinow• 2 years ago

Ah, I used your site a lot after I bought a beginner's telescope some years ago, thanks for all the fun I had waking up early to spot satellites! Had no idea it had any wasm, interesting!

jb1991• 2 years ago

From what I understand, it’s still pretty clunky to do multithreading with it. So people who want the speed of near native execution often also want extra threads.

baudaux• 2 years ago

There are a lot of projects around WebAssembly. But technology is hidden from external view. (Some self promotion, I am creating https://exaequos.com, a new Unix like OS running in a web browser)

srvaroa• 2 years ago

There are usages outside of the browser too. We are using wasm as a runtime for applications and modules deployed in small IoT device. Wasm helps overcome the typical limitations of those devices giving platform independence, sandboxed environments, ability to verify and sign modules ahead of deployment, allows developers to program in dominant languages and compile to wasm, and still retain a low footprint which is critical in this context.

There is a more detailed overview here: https://www.midokura.com/why-webassembly-is-perfect-for-tiny...

anoopelias2• 2 years ago

Sometime back I did some experiments with WASM over ESP32 board[1]. It was fairly easy to get a simple WASM program to work, though there was a fair amount of (ongoing) work left to bring it into usable shape.

[1] https://anoopelias.github.io/posts/wasm-micro-runtime-with-r...

emnudge• 2 years ago

I sunk a decent amount of time into WebAssembly over the past few months (I am the author of "watlings").

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.

vsnf• 2 years ago

2. WASM is very good at bringing tools to new spaces.

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.

lenkite2• 2 years ago

No direct DOM access means it will continue to remain a second class citizen on the web

novagameco• 2 years ago

Yeah the problems it is meant to solve are not problems that most frontend developers have. Frontend developers are often constrained by development time and maintainability, not performance. Frontend developers care about expressing their code in the most succinct and maintainable way: how can I do something with the least amount of boilerplate possible? That's why we have frameworks: to standardize common patterns in web development and cut down on the amount of time required to build an application. Most frontend developers are not working on performance-heavy applications that require WASM, they're working on forms which get POST'd directly to an API somewhere that does all the real heavy lifting (or just serves as a CRUD interface to a database)

jedisct12• 2 years ago

It's possible. See https://github.com/thi-ng/umbrella/tree/develop/packages/was... for example.

lewisjoe2• 2 years ago

By mass adoption, do you mean why not all existing softwares are ported to webassembly so that they can be run on browsers?

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.

martinald• 2 years ago

As far as I know Figma used asm.js (then WASM) from the start. I actually don't think they'd have had the success they had without it - it would have been too slow built in JS.

So in a way webasm/asm.js is already allowing whole new categories of webapps we take for granted now.

lesuorac3• 2 years ago

Is there a citation for 3?

Afaik, WASM is only used by Sheets [1].

[1] https://2024.wasmio.tech/sessions/webassembly-at-google/

lioeters2• 2 years ago

In addition to the use cases other comments have listed, Firefox uses WASM internally as a sandbox environment.

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...

lukax• 2 years ago

WebAssembly can be used to reuse logic between web, mobile and desktop apps. For example you can write your core logic once in Rust and then make a native UI for different platforms. We've used this approach for Koofr Vault [1] (client side encrypted cloud storage) and we couldn't be happier. Rust for core logic, React for web and desktop apps (with Tauri), SwiftUI for iOS and Jetpack Compose for Android.

[1] https://vault.koofr.net

singularity20012• 2 years ago

I feel like some elements in the WebAssembly committee try to actively hinder sane JS integration. Once we can use wasm gc objects in js and js objects including strings in wasm (without gluecode hell) adoptation might skyrocket.

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.

chubot• 2 years ago

I think it depends on what your expectations are.

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.

n_plus_1_acc• 2 years ago

lichess uses the stockfish chess engine compiled to wasm, for example

shortrounddev2• 2 years ago

what stops mass adoption of WebAssembly

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

6gvONxR4sf7o• 2 years ago

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.

shzhdbi09gv8ioi3• 2 years ago

I'm developing a wasm game, and currently I am targeting WebGL2 in order to run in iOS Safari.

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

speps• 2 years ago

8MB seems high for Rust. Even the project I did [1] which was using D (with GC) ended up with an 8MB WASM. Rust's WASM target is much more exercised than D's, so I think you might need to tweak some compile options.

[1] https://github.com/speps/tt

jedisct12• 2 years ago

Super Mario 64: https://probablykam.github.io/Mario64webgl/

ledgerdev4• 2 years ago

From my perspective It's 2 primary blockers.

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.

ryukafalz• 2 years ago

Yeah, I think the GC bit was one of the huge missing pieces for dynamic languages on Wasm. Things seem to be moving very quickly now that Wasm GC is out there: https://spritely.institute/news/building-interactive-web-pag...

andsoitis• 2 years ago

Lack of GC which has made languages like js/python/jvm/c# unfeasible.

I've had success running F# (a .NET language, like C#) on WASM using Bolero: https://fsbolero.io

phickey2• 2 years ago

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.

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.

kevingadd3• 2 years ago

Sadly the current iteration of WASM GC is still too limited for stuff like JVM or C# garbage collection semantics without jumping through a lot of hoops. I'm optimistic that in a few years there will be an expanded version of it that more runtimes can adopt, though.

#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.

pjmlp4• 2 years ago

Lack of GC which has made languages like js/python/jvm/c# unfeasible.

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.

neuronicnobody• 2 years ago

For #1, check out https://extism.org/

emadda• 2 years ago

I think it’s a few things:

- 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).

lesuorac3• 2 years ago

Question from someone knew very little in this domain: what stops mass adoption of WebAssembly?

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).

penteract• 2 years ago

Around a year ago I used the GHC WebAssembly backend to get some Haskell code running in the browser, but that needed WASI(WebAssembly System Interface) which was tricky to set up correctly. There were plenty of warnings about things being incomplete and experimental, and the code would crash unless I told it to do some pointless work during initialization (my best guess is that there was some bug involving the Haskell garbage collector and memory allocation - there are enough warning messages that I don't think "it's never a compiler bug" applies here).

vouwfietsman• 2 years ago

Besides the other comments here, currently its mostly:

* 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.

DanielHB2• 2 years ago

Some things that might greatly increase wasm usage and overall tooling:

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.

pjmlp4• 2 years ago

lib/wasm32-wasi/crt1.o: undefined symbol: main

Oops.

ifree2• 2 years ago

Looks like a race condition between disassembly and linking, re-evaluate the code block may help

Thorrez• 2 years ago

Is the site working? There seem to be broken sections: a section that just says "undefined", a large section that's blank, and a section that just says "Error: process exited with code 1.".

ifree2• 2 years ago

You may need to wait for a while till the wasm file is loaded, and there is a chance that the disassembly or execution result is not shown. In that case, please try to run the code block again.

DanielHB2• 2 years ago

In my job we are using duckdb compiled to wasm in our browser-based application. We store time series data in it and can query the data to show charts and logs using SQL.

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.

nilslice2• 2 years ago

Very cool -- if anyone else is curious about the WebAssembly code that powers this app, here are some pre-analyzed modules from the page:

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...

WebAssembly Playground

Related Stories