Introduction to WebAssembly Components

Re:Introduction to WebAssembly Components by tyingq on Friday December 17, 2021 @08:03AM (#29591554)

If you're coming from web dev, I would think of it as a "foreign function interface" from javascript. You're calling a function defined in some other language. Here's a function, in WAT format (Web Assembly Text), that returns the number 42:

  (module
    (func (result i32)
      (i32.const 42)
    )
    (export "testfunction" (func 0))
  )

Go to https://mbebenita.github.io/WasmExplorer/ and paste that in the middle box, then click assemble, then download, and you'll have a local file called "test.wasm".

Then, since you already do web dev, get that test.wasm file and a new page accessible from a local web server. The new page should have this in it:

   <script>
   // should log 42 to the console
   WebAssembly.instantiateStreaming(fetch('https://path/to/test.wasm')).then(prog => {
            console.log(prog.instance.exports.testfunction()); 
   });
   </script>

Everything else is facades, layers, and tools on top of that. But that should help clear up what's at the bottom from a web-dev/js perspective. And also what the "2 halves" are. One half being, in your case, that the Rust compiles down eventually to WASM that you host somewhere. The other half being that you need to be able to call into that generated code from your JS.

[ Parent | on HN ]

Re:Introduction to WebAssembly Components by TekMol on Friday December 17, 2021 @08:18AM (#29591676)

This pretty much summarizes what a clusterfuck WebAssembly is.

It should be possible to just paste the 6 wasm lines into a <script type=wasm> block. This is what made the web successful. Not having to have tooling to build things.

[ Parent | on HN ]

Re:Introduction to WebAssembly Components by todd3834 on Friday December 17, 2021 @09:12AM (#29592368)

I understand where you are coming from and something like you just mentioned would be a nice feature. However, it does seem worth mentioning that most people are not going to want to write code in web assembly text format. The current tooling exists so you can load binary data which wouldn’t embed well into a script tag. The primary use case is compiling code written in other languages that often have a runtime that comes with them. Because of that the payloads are often much larger than anything you would want in a script tag as well. There is also more to it than just loading a script. You get to have shared memory buffers and you have control over what to share between the JS and WASM env. This configuration is simplest with JS. It’s a very small amount of code to load WASM and configure these things.

If web assembly text format was just a more performant scripting language then I’d go with your proposal. Since it is meant to be a visual representation of WASM binary format and that binary code is more useful when it can be configured, I don’t mind the current implementation.

[ Parent | on HN ]

Re:Introduction to WebAssembly Components by pjmlp on Saturday December 18, 2021 @10:34AM (#29605181)

Somehow the formats that WebAssembly is deemed being better of, managed to do it via object tags or script source attributes, but naturally in HTML 5 everything is better except when not.

[ Parent | on HN ]

Re:Introduction to WebAssembly Components by tyingq on Friday December 17, 2021 @08:23AM (#29591729)

Yeah. You can use a base64 data uri, but that's not great either. There is a proposal for <script type="module">, but it looks untouched for several years: https://github.com/WebAssembly/proposals/issues/12

[ Parent | on HN ]