Wasip1 did not specify sockets. Some implementations have made non-standard additions to add them, but sockets were not added to the standard until wasip2.

Sockets are officially specified in wasip1: https://wasi.dev/releases/wasi-p1

Notably, listen and connect are missing. But sockets themselves were in there.

No, the stack switching proposal is not used. Stack switching is a set of core Wasm opcodes that permit a guest to change its own stack. Instead of using opcodes inside the Wasm, the stackful async mode of the component model’s ABI calls out into the component model implementation where it can manipulate the stacks with special host powers - JSPI is sufficient on web engines to express this, and wasmtime manages guest stacks in memory.

When stack switching becomes available in all engines, it will be possible to implement this part of the component model in pure Wasm without host magic, e.g. web engines will be able to avoid the call out to JS to use JSPI.

Thank you, that's great to hear. I was worried it would be a long time before most runtimes could use WASIp3 if it required stack-switching.

Wasmtime implements a remote debugging server, so that you can debug guest programs with a recent build of LLDB. Set breakpoints based on the source language symbols, single-step through wasm opcodes, anything you'd expect: https://docs.wasmtime.dev/examples-debugging-guest.html

still useless. I had an idea to offload parts of my game core into wasm leaving only UI in the browser - I abandoned that idea when there was absolutely zero possibility for me to debug in browser what is wrong with my core. i just rewrote everything to TS (from rust)

There is a wat (s expression) syntax for the component model. The problem with the wat syntax for both Wasm and the component model is they’re a reflection of a binary format, and therefore are terrible for writing by hand. They’re designed to be written by tools, and the text format is just to help you understand the binary format.

I’ve written Wasm and component model wat extensively over the last decade to develop tests for Wasmtime, and even for an expert it’s a bad experience.

Wit syntax is easy to read and write by hand. There are high quality parsers that can transform it to and from the binary or wat format as needed, and code generators for a wide range of languages. It’s a way, way better experience in every way to deal with wit compared to the wat format.

Seconding this. Writing .wast files by hand is kind of fun as a novelty, but it's in no way something I'd want to maintain interfaces in.

Declarative interfaces via the WIT format are so much more readable in comparison; I'm really happy that's the direction we took for the component model.

Lots of context for this project on the Bytecode Alliance blog: https://bytecodealliance.org/articles/endive-and-the-next-ch...

Ah, looks like they will be packaging a Rust runtime on top, not as interesting as I thought.

the "redline" compiler is cranelift which is written in rust, but i think it's being compiled to Wasm first then JVM bytecode so it still works zero dependency. not sure if that will continue to be the case.

WebAssembly is a compiler target, not a human-authored language. There is exactly one audience of people for writing wat by hand: spec and tutorial authors and readers. Anyone actually developing an application they want to use will use a compiler to produce WebAssembly. Prove me wrong and write Roller Coaster Tycoon in raw wasm if you want, but having written and maintained wasm specs and toolchains for nearly a decade, I will never write any wat outside of a spec or tutorial.

There is exactly one case where I'd like to write "raw wat" (and for that matter "raw wasm bytecode"): I'd love to do something like the "bootstrappable builds" project for wasm, starting with a simple wat-to-bytecode parser/translator written in raw bytecode, then some tools wirtten in raw wat for bootstrapping into other languages. :)

Real programs, whether native JavaScript or in any other language that targets Wasm, have concurrency. Would you rather the component model exclude all concurrent programs, and fail to interact with concurrent JavaScript? The component model is meeting the web and programmers where they're at. Unless you're one of the few people implementing the low level bindings between components and guest or host languages, you don't have to ever read the CM spec or care about the minutae of how it gets implemented.

I was looking there because the high-level documentation doesn't seem detailed enough to understand how it works. Maybe some intermediate-level explanations are needed?

https://github.com/bytecodealliance/ComponentizeJS is a Bytecode Alliance project which can run JS in a SpiderMonkey-based runtime as a Wasm component

Wasm only gets additive changes - the binary format can't change in a way that breaks any previously existing programs, because that would break the Web. So, you just have to add more opcodes to your implementation.

Awesome, thanks!

Aside from code size the primary benefit on the Web is that the GC provided to wasm is the same one for the outer JavaScript engine, so an object from wasm can stay alive get collected based on whether JS keeps references to it. So it’s not really about providing a GC for a single wasm module (program), its about participating in one cooperatively with other programs.

now that would make a lot of sense, thanks