Hello. Happy Fozdam. My name is Ilya Baryshnikov. Okay. My name is Ilya Baryshnikov. A few words about me. I'm a curator of Avi.

I work at Align Technology, and I use Rust and WebAssembly at work. If you go and check Avi, you can find a number of crates, like with the description and so on. If you know a nice crate and it's not presented there, you can just leave an issue or a kind of a suggestion.

It would be very useful. Ah, so it would be a talk mostly about Wasn't Bunch. So what is it, and why is it useful? Why do we need it? Actually, we can compile Rust to WebAssembly just using plain Rust C or cargo build.

Here's an example of building WebAssembly module just using plain Rust C. But in this case, we have to do all the memory management on our own. Like here, we have at first to allocate the memory and send the pointer back to JavaScript.

Then we have to set the memory from JavaScript, because JavaScript and WebAssembly have different memories. We have to copy data from JavaScript memory to WebAssembly memory. And then we call our computation, where we construct the slice from raw parts and so on. So just, we have to do it on our own using plain Rust C.

And it's a way to compile. We use CDI-lib, maybe. It's just a dynamical library when using the target. And when calling from JavaScript, it looks like this. So at first, we need to fetch and instantiate our WebAssembly module.

Then we have to access our experts. Then allocate in memory. And now we have a pointer. Then we have a view into this memory. And as you can see, we divide each pointer by four, because the view is offset in 32 array

and pointer is in bytes. So we have to do all of this on our own. Then when we set the memory, we basically copy the array from JavaScript memory to WebAssembly memory. And then finally, we can do our computation. And the function names,

they are all in a snake case, like in Rust. We are not used to this in JavaScript, so it looks a bit strange. Then we can do the same again in Wasm-Byndjian. Using the CDI lib again, just adding the dependency.

And Wasm-Byndjian does all of this for us. It just manages, takes the memory management and so on and generates JavaScript for us. And we can annotate our functions to have a correct camel case JavaScript names.

Everything looks cool. So it's just our Rust. Function without any unsafe or extern. But it's unsafe inside, it's just a wrapper. And then from JavaScript, we just import it. And like any other JavaScript function,

we pass data again, like we used to do, and receive the results. Well, that's just the point of Wasm-Byndjian. It just does a lot of work for us. Then what about std web? There is really, there was a crate,

just created before Wasm-Byndjian, and a lot of libraries written using std web. And after Wasm-Byndjian was created and became more mainstream, people started to suggest, like, let's rewrite this library from std web to Wasm-Byndjian.

But what if instead we could just build them together and just use both of them without writing anything? And it was a suggestion to do this. It required to make some changes to Wasm-Byndjian itself.

One of the most noticeable change was JS snippets. As JavaScript is a modern assembly, we can have inline JavaScript in our Rust. Seriously, I'm not kidding, it's just...

So here, we write JavaScript and we annotate it. It's like the corresponding Rust function. We connect them, like, with JS name and so on. And then we call JavaScript from our Rust. That's it.

So it was the addition to Wasm-Byndjian, which helped to build a part of std web on top of Wasm-Byndjian. And luckily, the initial support of limited interoperability. So expect not everything would work perfectly,

but at least up to a certain point, it would work. It was released, and I think it's a big deal. Then, just another big point, like when we are writing Rust for web,

just it would be hard to write everything on our own. We have to use libraries. It would be really nice. So when you just grab a library and compile it, and everything is fine, it's great. And this year, there was a number of libraries which got WebAssembly support, or improved,

for example, Chrono, or recently there was a release of Winit which got WebAssembly support using both std web or Wasm-Byndjian. You can choose which one. And Rand improved some, fixed some issues.

And a lot of other crates. I guess JFixRS got WebAssembly support this year. So about Rayon, there was a nice addition which allows you to handle threads spawning on your own.

And you can even use, with a bit of luck, you can use Rayon inside of the browser. Then it was a really big feature when Async8 landed in unstable Rust.

And when it comes to WebAssembly, we have to connect JavaScript promises with Rust features. And the create Wasm-Byndjian features does this for us. So it provides interoperability, and it is a distant executor.

So it's a Rust executor built on top of JavaScript promises. And let's check an example. At first we need to define some JavaScript function which will return a promise, like this.

And then we annotate our function, the first line. It means that this function will run when we just initialize the model.

So it's just like a main. And then we can get the promise from JavaScript when calling delayed answer. And just future can convert promise to future. So we convert the promise to future,

and then await on it, resolving it to result. And after this, we can just log the message. And from JavaScript side, it looks like this. We just called init, and what was written in Wasm-Byndjian start,

everything would run, and all the Async stuff. So you can just have Async await in Wasm-Byndjian and use it on stable, and everything works. And so it's really cool.

Then there were a lot of talks about WebAssembly going outside of the browser. And we do have a number of runtimes supporting WebAssembly. So it's not only browser, but any arbitrary just runtime which can run it.

And cargo-wasi is kind of similar to Wasm pack. So Wasm pack creates a package for you, like NPM package, or just a package which you can run with JavaScript.

And cargo-wasi creates a package which you can run in standalone runtime. For example, in Wasm time or any other. So it also supports building and running. So you can cargo-wasi run or something like this. And it's really nice to,

also there was, well, the things before, they are kind of more related to Rust or to Interop. But this one is an extension of a specification. Multi-value is,

if I understand it correct, it is not supported by all browsers yet. But, well, if runtime supports it, you can use it. But you still have to build Rust. And here is a great article by Nick Fitzgerald,

where he writes about implementing multi-value in Wasm bindgen and a number of other tools. And it is prerequisite for interface types. Because at the moment we can return only numbers

from WebAssembly or accept only numbers. And if we want to pass an array, for example, in the browser, we have to copy it to WebAssembly memory and pass the pointers. So interface types would allow us to pass arrays or strings. It's just a definition of memory layout.

And multi-value is a prerequisite for it. And so the support of multi-value was added to Wasm bindgen and read more in this article. And to summarize, we got better interoperability,

more libraries supporting compiling to WebAssembly. We can now use async-await with Rust in a browser. And we have more runtimes and better support with cargo-wise and new features like multi-value.

And really a lot of bug fixes were made with a number of different tools and crates and so on. Well, I guess that's all. And if you want more information, I posted all the examples from the talk to GitHub.

You can check them and run on your own, like play with it. Or also the links are here. So that's it. Thanks. Yeah, questions?

Okay. You mentioned that Wasm bindgen features comes with its own executor. Can you clarify if you can mix JavaScript-based features with Rust features? Okay, the question is that Wasm bindgen features comes with its own executor,

so can we mix the JavaScript promises with Rust features? Yes, we definitely can. So the executor does poll, poll, poll until the feature is ready. And here the poll is done using callback to JavaScript.

So we need just a way to not block, to leave the runtime, to do a next tick. For example, if we are not using a feature, if we have to wait, we need a mechanism to wait. So this waiting thing is done using promises.

In particularly, we have wait, I think, atomic. Wait, I think it's a proposal. There is also a polyfill. So just in short, yes, we can use both of them

and interoperate. Next. Thank you very much. Thanks.