Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly Playground

observablehq.com

Post reply on HN
Print view View original

31–40 of 99 posts

Re: WebAssembly Playground

#31

Post by pjmlp »

paulgb wrote: post #30
pjmlp wrote: post #23

Earlier quoted context omitted.

Which could have been done with WebAudio and WebGL/WebGPU as well, without the pain of dealing with WebAssembly tooling.

Surely you mean WebCodecs rather than WebGL/WebGPU? AFAIK no encoding primitives are exposed by WebGL/WebGPU. 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.

I really mean WebGL/WebGPU and using shaders instead of C and C++, while being GPU accelerated.

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.

Re: WebAssembly Playground

#32

Post by bennettbackward »

SeanAnderson wrote: post #11
thrdbndndn wrote: post #2

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

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"…

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/

Re: WebAssembly Playground

#33

Post by lukax »

thrdbndndn wrote: post #2

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

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

Re: WebAssembly Playground

#34

Post by paulgb »

pjmlp wrote: post #31
paulgb wrote: post #30

Earlier quoted context omitted.

Surely you mean WebCodecs rather than WebGL/WebGPU? AFAIK no encoding primitives are exposed by WebGL/WebGPU. 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.

I really mean WebGL/WebGPU and using shaders instead of C and C++, while being GPU accelerated. 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.

Oh interesting! I found this as well: https://jsmpeg.com/

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.

Re: WebAssembly Playground

#35

Post by politelemon »

vinnymac wrote: post #16
iamcreasy wrote: post #6

Earlier quoted context omitted.

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

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 JavaScri…

Allowing WASM to call various Web APIs should be interesting and open up more possibilities and applications, although I can see it becoming more of a security concern as well.

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?

Re: WebAssembly Playground

#36

Post by CryZe »

vinnymac wrote: post #16
iamcreasy wrote: post #6

Earlier quoted context omitted.

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

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 JavaScri…

This is no longer true, there's various high level types that WebAssembly can pass around, such as reference types (opaque objects from the outside world, i.e. JavaScript objects) and all the new GC types. So the only thing stopping you from calling into web APIs is importing them into the WebAssembly, which atm is indeed still a manual process (or automated with some codegen).

Re: WebAssembly Playground

#37

Post by singularity2001 »

thrdbndndn wrote: post #2

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

Re: WebAssembly Playground

#38

Post by singularity2001 »

CryZe wrote: post #36
vinnymac wrote: post #16

Earlier quoted context omitted.

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 JavaScri…

This is no longer true, there's various high level types that WebAssembly can pass around, such as reference types (opaque objects from the outside world, i.e. JavaScript objects) and all the new GC types. So the only thing stopping you from calling into web APIs is importing them into the WebAssembly, which atm is indeed still a manual process (or automated with some codegen).

As you said these objects are currently opaque and still need horrible glue code to transform to/from wasm/js.

Re: WebAssembly Playground

#39

Post by chubot »

thrdbndndn wrote: post #2

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

Re: WebAssembly Playground

#40

Post by n_plus_1_acc »

thrdbndndn wrote: post #2

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

lichess uses the stockfish chess engine compiled to wasm, for example
Post reply on HN