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.

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.

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.

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

I found the book The Art Of Web Assembly [1] to really help me understand it better. A lot of other books seem to focus on a specific part of the tool chain. This one shows you all of the examples in web assembly text language. While I wouldn’t want to write a program in it, reading it with the context provided by the author really helped me understand what is going on. It also helped me understand why so many things are the way they are in the current iteration of the WASM world.

[1]https://www.amazon.com/dp/1718501447

If it helps, I have a couple decades experience as a systems programmer and I find it hard to understand how to interface my code with JS. Web dev with its constantly shifting frameworks is baffling to me.

I found going through the AssemblyScript setup and tutorials really helped me understand WASM without first having to wrap my head around C++ or Rust toolchains. AssemblyScript is a TypeScript dialect that compiles to WASM instead of JavaScript: https://www.assemblyscript.org/

What I find really interesting about AssemblyScript is the potential for homographic code between JS and WASM. I'd prefer to see languages like AssemblyScript that are designed for WASM first, rather than shoe-horning existing languages like C++--and thus, their existing library ecosystems--into WASM. Yes, there is a lot of extant code that people are interested in porting, but that's not the end of the world and I'm not too keen on the bloat it creates or having to debug the teetering tower of tools that it represents if some impedence mismatch causes problems along the way.

With homographic AssemblyScript and TypeScript, I start to imagine a time when you can run an app on your phone, serialize the whole state of it, push it off to another user or your PC or something, and pick up where you left off. Maybe you'd do it for more compute power. Maybe you'd do it to share state on a collaboration. I don't know. But it's a fascinating idea that I'd really like to see one day.

I had a look at both WebAssembly and Rust a few months back, in the hope they could help me write some nice, fast graphics filters that I could then compile out and use via Wasm in a 2d canvas. Entirely do-able, but beyond my limits of understanding and patience.

Since then, I've stuck with what I know (Javascript) and branched instead into consuming Wasm written by others (in whatever language) on the frontend for my own experiments - for instance Rapier[1] which is a physics engine written in Rust, and some of the MediaPipe ML models[2].

[1] - Rapier getting started page - https://rapier.rs/docs/user_guides/javascript/getting_starte...

[2] - MediaPipe face mesh model getting started page - https://google.github.io/mediapipe/solutions/face_mesh#javas...

You are better off learning WebGL and Houdini for that.

isn't webassemly just a compile-target? Like JVM-bytecode or real x86 assembly?

If so, then you are not really supposed to understand web assembly. Just like x86 assembly it's just what your language, like rust, compiles to. If you want to understand it, then I suppose it's hard unless you have a background in systems programming since it's so low-level. It's the nature of the game and web-dev is quite removed from low-level coding.

I don't have an experience with web assembly, it's just how I understood the concept.

Webassembly is like a virtual machine without any standard library but permits custom embedders. As you could imagine that makes it limiting and is in part what things like WASI and Webassembly Components are trying to address.

Rust has probably the most batteries included, with explanation, of most of the languages that compile to WASM right now. It has a lot of tooling that takes some of the underlying pain out of interfacing with JS. There's even an online guide for it:

https://rustwasm.github.io/book/

You can use AssemblyScript instead of Rust

It is basically the same thing as JVM or CLR (specially in regards to the CLR), just with more marketing appeal.

I think that's one of the things that confuses people. WASM is, in some respects, very similar to ASM. In other respects, it's very similar to a language VM, but has a name that makes that non-obvious. Will likely get more confusing as they add things that normal ASM doesn't do, like GC, direct JS call interop, more data types, etc.

I think that what actually confuses people is presenting WASM as something completely new, without even briefly discussing all the kinds of approaches to polyglot bytecode formats since the early 1960's.

So those not versed into the matter fail to understand the overall picture as it isn't given to them.