WASM 2.0

Unfortunately, despite being "enabled", Rust+LLVM don't take advantage of this because of ABI compatibility mess. I don't know whether the story on Clang's side is similar.

https://github.com/WebAssembly/flexible-vectors

  const MIN_U32 = 0;
  const MAX_U32 = 2 ** 32 - 1;
  
  function u32(v) {
    if (v < MIN_U32 || v > MAX_U32) {
      throw Error(`Value out of range for u32: ${v}`);
    }
  
    return leb128(v);
  }

  subtype U32 is Interfaces.Unsigned_64 range 0 .. 2 ** 32 - 1;

  type U32 is mod 2 ** 32;

  First  : constant U32 := U32'First; -- = 0
  Last   : constant U32 := U32'Last;  -- = 2 ** 32 - 1
  Range_ : constant U32 := U32'Range; -- Range 0 .. 2**32 - 1

https://github.com/mcuking/Awesome-WebAssembly-Applications

https://github.com/WebAssembly/flexible-vectors

> the Wasm Community and Working Groups had reached consensus and finished the specification in early 2022. All major implementations have been shipping 2.0 for even longer.

> In a future post we will take a look at Wasm 3.0, which is already around the corner at this point!

Features in 3.0 presumably also being mostly implemented already, some maybe just kept behind feature flags.

if the host provides the guest wasm module via imports a function to create and run from an array of bytes then it can be done today (if I understand you correctly).

Here's some related content: https://github.com/pdubroy/til/blob/main/wasm/2024-02-22-Run...

https://github.com/pannous/wasp

[1] https://github.com/speced/bikeshed

with the component model's wit you get higher level types like enums, option, result and generics: https://component-model.bytecodealliance.org/design/wit.html

> WebAssembly provides no ambient access to the computing environment in which code is executed. Any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking functions provided by the embedder and imported into a WebAssembly module.

more info here:

- https://webassembly.org/docs/security/

- https://www.w3.org/TR/wasm-core-1/#design-goals%E2%91%A0

For the sandbox it's hard to say, lets just say for most considerations they can be treated as "as safe" as the other.

But many vulnerabilities had been in APIs interacting with external resources, I/O etc.And currently in the browser that in general goes through JS, so some would say JS is more secure.

But it's not that a WASM engine can't provide such APIs to WASM without going through JS (e.g. see WASI) and weather it's WASM or JS they semantically only have access to this APIs through their engine which can guard/filter/limit/etc. the APIs however it wants (i.e. you can't call the systems libc function directly or anything like that).

So in general I would say the question if one is "safer" then the other is meaningless.

Especially if we compare a custom JS only vs. WASM only sandbox which doesn't have DOM and all the old JS browser APIs. Through with this APIs you could say WASM is slightly more save.

There are also some other interesting considerations like e.g. in JS you have eval (and DOM to do eval in a roundabout way) but then in WASM you have memory safety issues (depending on the source language, through due to WASM design they are much much less abusable then in native C, but they still can involve vulnerabilities leading to affecting program behavior in a way which can be a security issue, e.g. overflow overwriting a "valid" flag or similar).

Anyway if asked "in general" I think there is no meaningful answer outside of treat it as the same.

But if you have specific use-cases/needs things might differ.

Emscripten is very bloated, but it's the best option from what I can tell.

I lost a whole day of a 3 day game jam to a weird Emscripten bug. It ended up being that adding a member to a class blew up the whole thing.

The alternative (and the only option, if you want it to be as light as possible) is to do the bindings yourself, which is fun, depending on how much your concept of fun involves JavaScript, and having half your code in a different programming language.

I'm told the Rust situation is pretty nice, although my attempt didn't get anywhere — apparently I tried to use it in exactly the opposite way that it was intended.

I had a pretty nice time with Odin. Someone put raylib wasm bindings for Odin on GitHub, and it worked really well for me.

(Odin syntax is really nice, but you don't realize just how nice, until you port your game to another language!)

Zig was cool, but a bit pedantic for a jam, and a bit unstable (kept finding out of date docs). Didn't see much in the way of game libs, but I was able to ship a Zig game with WASM-4.

I ended up switching to TS, which I'm not happy with, but since you (usually) need JS anyway, the benefit of having a single language, and a reliable toolchain, is very high, especially under time pressure. The "my language is nice" benefits do not in my experience outweigh the rest of the pain.

As far as I know, "2.0" is just a marketing term batching several extensions standardized since 1.0 (and simplifying feature queries "are extensions X,Y,Z supported" to "is 2.0 supported"), not unlike what Vulkan does with their extensions.

https://www.youtube.com/@wasmio

According to those, likely to replace containers and likely to be integreated in more and more systesms.

It seems like it's exploding in populartity and usage because it solves some very real problems.

Not having the JS GC randomly pausing your process unpredictably.

Sandboxing untrusted code, i.e. you sell a SaaS and you also want clients to be able to run untrusted plugins from a marketplace.

That's how asm.js was conceived. You can compile other languages to a subset of JS that is super JIT-friendly and performs stupidly well.

I think WASM came to be due to a desire to run that resulting code in a heavily sandboxed environment, with much more limited access to certain APIs than the rest of your JavaScript code.

Unrelated, but it's not clear to me why you're getting downvoted. Your point sounded genuine and didn't look like flamewar bait.

Not a hater, though it's fun to run Doom in a browser tab... just can't see any business value in 99% of its ecosystem, especially with the drift away from web (the only niche where it made sense).