assemblyscript VS reference-types

This is probably the closest thing to that: https://www.assemblyscript.org/

We're going to write a fictional (and minimal!) firmware for our smart thermostat, let's assume we decided to use AssemblyScript (but it could have been in C, Rust, Go or any other supported language):

and have that just work without any JS "glue code". Maybe someday. I know they're working on the DOM APIs, but as you said, it's been slow going. Feels like priorities are elsewhere. Even CSS is moving forward with new features faster than WASM is (nesting and view transitions are awesome though).

(Btw when I said "separate runtime type checking" I didn't mean language-level; I was referring to the validation libraries that are required today since TS types obviously no longer exist after build. If it were a real static language, then of course you wouldn't need to do that because you can't store a bool in a string in the first place.)

[0]: https://www.assemblyscript.org/ (Porffor looks neat too. Wonder if it could be useful in plugin architectures? E.g. plugins can written in JS, and the program only needs a WASM interpreter. I'll bookmark it. Thanks.)

Built a platform flibbert.com where you can run code on ESP32 microcontrollers in AssemblyScript and TinyGo. It’s great for trying things out or learning without the usual setup hassle. Would love for people to try it and share feedback! (The project is on early stage, tested only on esp32-cam)

I get your point but one of the advantage of WASM is the compile step. It means that the WASM code will load and start running much faster because the browser gets a ready made binary to execute.

But yes, having the need for special tooling is a pain. My understanding is that AssemblyScript[0] allows to write code that look like Typescript and integrate well with the node ecosystem. Could be worth a look.

In case you start with a WAT file, there are ways to compile WAT to WASM in the browser[1].

[0] https://www.assemblyscript.org/

[1] https://webassembly.github.io/wabt/demo/wat2wasm/

I like your take but JavaScript was literally the assembly language of the web until WASM came along. There was no other language that TypeScript could compile to.

This train of thought lead me to discover AssemblyScript! https://www.assemblyscript.org/

Incidentally, it’s also what AssemblyScript uses: https://github.com/AssemblyScript/assemblyscript/blob/main/s...

> It could be an interesting use case for WASM if the problem of passing data into the WASM VM cheaply (perhaps by reference) can be solved.

WASM Reference Types should hopefully solve this. The WASM working group seems to have some good momentum - so I'm hopeful this (or a similar replacement spec) will land sooner rather than later.

https://github.com/WebAssembly/reference-types/blob/master/p...

AFAIK GC is irrelevant for "direct DOM access", you would rather want to hop into the following rabbit hole:

- reference types: https://github.com/WebAssembly/reference-types/blob/master/p...

- interface types (inactive): https://github.com/WebAssembly/interface-types/blob/main/pro...

- component model: https://github.com/WebAssembly/component-model

If this looks like a mess, that's because it is. Compared to that, the current solution to go through a Javascript shim doesn't look too bad IMHO.

[1]: https://github.com/WebAssembly/proposals

A glance of the overview and spec seems to indicate that WASM will provide some primitive data types, and any GC language can build their implementation on top of it. As I understand it, it's heavily based on Reference Types[3], which allows acting on host-provided types, and is already considered part of the spec [4]. It doesn't remove the need for the 5 different runtimes to have their own GC, but it lowers the bulk that the runtimes need to carry around, and offloads some of that onto the WASM runtime instead.

[3]: https://github.com/WebAssembly/reference-types/blob/master/p...

They've talked about interface types, and added reference types, which is a stepping stone toward the GC extension proposal, which would be a stepping stone toward manipulating the DOM from the WebAssembly side, but their official roadmap page is more short-term.

Nope, WASM reference types, it has nothing to do with .NET type system.

> And there's been talk of exposing the JS GC to wasm for a few years. Hopefully when that stuff lands, it'll get easier to marshal objects across the gap.

You don't need a Wasm GC to do this. If you only need js objects to pass on to, say, the host's function or check is null or not, then reference types that are opaque external references: https://github.com/WebAssembly/reference-types/blob/master/p...

You can even do many more things if you export `Reflect` to WebAssembly: https://github.com/AssemblyScript/assemblyscript/blob/main/t...

Reference Types are available almost everywhere already (In Safari will be available after 15.0): https://webassembly.org/roadmap

Re: GC -- yes, indeed, the whole business with safepoints arose from the need to support Wasm reference types as a backend for Wasmtime or Firefox. No safepoints are needed for Rust (or other C-like) code.

Reference Types,