 All right. Hello, everyone. Welcome to my talk today at the Immersing West Forum as part of the Open Source Summit North America. Well, my journey with Open Source sort of started back in 2019 when I attended my first international talk, International Conference at Open Source Summit Europe. That took place in Leon in 2019. And I mean, I really loved my experience over there. And I felt that, OK, I mean, I want to attend each and every developer conference. But of course, COVID struck. I got to be part of a lot of virtual conferences. And this happens to be my second Open Source Summit. But this time as speaker and not as an attendee. So I'm really excited for this. And it's really good to see so many people coming here. Of course, today's topic is going to be demystifying WebAssembly through the eyes of a big no. We have had a lot of WebAssembly talks, especially in this year and in the past couple of years. And this talk really sort of covers some of the misconceptions that people have. Because I, myself, have given a lot of different talks on WebAssembly. And I have had the experience of working on various spectrums within WebAssembly. But there are still these common questions and these common misconceptions that usually come to place whenever I talk about WebAssembly to someone who is not aware about this terminology. So this talk is really meant to sort of uncover some of those or sort of resolve some of those misconceptions. And also sort of look at WebAssembly from the eyes of a beginner so that for those folks who are not aware of WebAssembly, they can at least get some idea and can get excited about the wonderful world that we are living in. I mean, you probably might have already covered some of the talks that have taken place over here. But yeah, I mean, this sort of this thing of this as a refresher and something that you can take with you since we are at the last day of the conference. So something to take with you as we conclude today's open source summit in North America. With that in mind, I'll get started. Very quick introduction about myself. I'm Shwai. I'm a developer advocate or developer relations engineer at Millie Search, which is a Rust-based open source search engine. It's an alternative to Elastic Search. And I'm also contributed to Layer 5, which is the service mesh community, as part of the CNCF. And if you want to connect with me, you can connect with me on hard-develop. Now, moving on to the first misconception. And that is web assembly is a programming language. Well, I mean, if you sort of break down web assembly into two words, that's web and assembly. I mean, I'll come back to the web part later. But the initial one is assembly, right? A lot of times you'll attribute assembly as the assembly language. So if you look on a broader spectrum of how programming languages from high level to the machine code, they sort of work is that you probably use a high level language that gets, and you basically use a compiler to compile it to assembly language. And finally, you get to the byte code, which is essentially the machine level language that is what is the zeros and ones that interacts with your CPU and with your computer sources. But web assembly is not an assembly language. And it is not just for the web. And that's one of the misconceptions that we'll be coming on to later. Well, what web assembly is really is it's a efficient low level byte code. Now, of course, we'll sort of break it down for everyone, for those who are especially coming here for the first time and who are hearing out web assembly for the first time, that what exactly is this efficient low level byte code? And then using some more technical jargons over here, such as it is portable, it is language agnostic, it's a compilation target. So just think of it as this kind of a technology where it's not like a programming language. So I mean, all of you might be familiar with JavaScript, Rust, C++. So it's not that. It's not a programming language that you can actually write into and just go ahead and compile it. Think of it in this way that, of course, all of you might be aware of how machine language sort of looks like. It's a combination of zeros and ones. So that's what web assembly is more sort of near to. It's a low level byte code representation. That means the representation will be in the format of collections of zeros and ones. And it is really portable. What that means is that essentially how byte code, how this web assembly byte code works is that you can take multiple languages, for example, C++, C, Rust, right? And then you can compile them into this byte code. And that is the byte code that is the web assembly byte code. And how is it portable? That it can be used in multiple places. It can be used within the browser. It can be used as part of, let's say, a server. And you can use it across multiple devices. It's not just limited to your web browser. It can be used in edge devices. It can be used in server-side hardware. And that's what web assembly is all about. And of course, as we cover more and more in-depth regarding how web assembly is actually used in multiple places, we'll sort of get into the netties and gritties of how web assembly actually works. And coming to sort of understanding how web assembly architects sort of looks like. So think of it in this way that all of you must be aware of how stacks work, right? Stack is a data structure that sort of follows our first and first out representation. That means whenever you put or you insert something inside a stack, it's sort of whatever item is at the end, it will always come out at the end. Whatever is at the top will always come at the top. So that's how the memory management within web assembly module also works. But of course, coming to the technical jargons a bit later, we'll move to the next part. And this is what exactly web assembly sort of looks like. Instead of thinking of it as a very simple, easy to understand, C++, this is what a hello world in web assembly sort of looks like. It's a combination of digits, z's and ones, and of course, hexadecimal format that you can see over here. This is what web assembly truly represents. And of course, if you were thinking that, hey, I would want to write my own web assembly, you can see the complexity. Of course, it's not something that it's not impossible. But at the same time, you can see that it's much more easier to actually write your programs in a high level language like C++ or Java as compared to actually writing it in web assembly. One of the other ones, like the biggest misconceptions that people usually have is that they think that web assembly is actually a replacement for JavaScript, and it is actually faster than JavaScript. So coming back to the representation of why web assembly was started in the first place, so all of us know that JavaScript is a really great language. Today, JavaScript is one of the most popular languages, and especially when it comes to web browsers, I don't think so there is any language that is going to be replacing JavaScript for implementation. But it does come with its own set of limitations. One of the biggest ones is that whenever it comes to a more complex calculation, a lot of mathematical crunching, that's where the way is fundamentally how JavaScript works, it sort of fails in there. I mean, it's not impossible to do these large mathematical calculations, so things like doing machine learning inference, neural network inference, which essentially is a combination of huge matrices or doing things like video editing, which usually involves a lot of mathematics and number crunching. It's possible to do with JavaScript, but it's a very slow process, and that's where web assembly sort of comes into the picture. So the idea is that you can actually take your more highly-performant applications, programming languages like C++ or Rust, and then basically compile them into the web assembly. And essentially, you can think of web assembly as a compilation target. That means that you can take your highly-performant programming languages like C++ or Rust, and you can compile them into this web assembly bytecode or this web assembly executable. Because generally, how browsers work is that browsers usually allow you to actually run JavaScript. They do not allow you to run any other programming languages like C++ or Rust natively directly in the browser. Because usually, how JavaScript also works is that it actually works inside of a sandbox environment. So one of the other ways in which you can actually run Rust or C++-based languages inside of your web browser is with the help of web assembly. Because you essentially run web assembly executable inside of that same sandbox environment in which you're also running your JavaScript. And that's one of the ways in which you can actually utilize the power of programming languages like C++ or Rust. So what we are essentially doing is, and of course, I'll come to the fun bit a bit later, what essentially we are doing is that we are sort of off loading all of our highly-competitional tasks that usually involve a lot of like, you know, CPU utilization or a lot of number crunching to be actually handled by the web assembly. And we are just sort of using JavaScript along with the web assembly. So web assembly in itself is something that cannot do a lot on its own. It's a very low-level system. So it cannot even get resources such as the file resources or network resources on its own. You have to usually combine it with other languages like let's say JavaScript to actually truly utilize the power of web assembly. So that is why web assembly is not going to be replacing JavaScript anytime soon or at the same time, like you know, you cannot just run web assembly on the browser. You still need some kind of a language like JavaScript to actually invoke to be used on let's say the DOM, which essentially is the bare bones of how the modern browsers work. And actually, I mean today, this morning, I was just looking at some, like you know, to come up with some fun memes with web assembly because like a lot of times people, again this is made that web assembly can actually replace JavaScript. So one of these was like, you know, I mean traditional programmers who use C++, they're trying to hit, of course, I mean, we do not recommend violence, but yes, I mean, this is how generally people perceive web assembly, right? That they are gonna be hitting JavaScript out of the park and they're gonna be the rulers of the web. And of course, this one is really a fun one that people have ended their friendship with JavaScript and they are becoming best friends with web assembly. But of course, all of this is false. And essentially what is that, you know, web assembly and JavaScript are gate friends because they really work well together with each other because what really, what is really happening is that essentially you're like, and I'll come back to this particular side in a bit, but essentially what is happening is that you're offloading your major tasks or highly commercial tasks from JavaScript to web assembly and essentially, since like, you know, as I mentioned that web assembly itself cannot really do a lot, your institution, all of your web assembly calls are basically, whenever you're wanting to actually use a assembly, you're using JavaScript APIs to basically call your web assembly module and then utilize that to do all these highly inference activities. And this is how one of the ways in which you can actually use web assembly. So essentially, as I mentioned that you take your C++ code, source code, and there's like, you know, basically a format in which you can actually convert that into the web assembly bytecode or the web assembly module using something known as in scripting. And essentially, you're going to be using that with your HTML document. So essentially what you're doing is that you're going to be fetching your web assembly module inside of your JavaScript application and then you're going to be utilizing it with the help of JS APIs. And of course, I mean, that's just one of the ways. Of course, there are a lot of other ways in which you can actually use web assembly with your application. So you could also actually just like, you know, write a Rust application and then directly compile it into a web assembly target or you can use something like assembly script which is very similar to TypeScript that essentially converts directly into web assembly executable. But of course, one of the most widely used ones is essentially taking like, let's say a C++ application with them in scripting. And a really great example for this is FFMpeg. So if you're not aware of FFMpeg, it's a very popular like, you know, library that has been written in C++ for doing anything related to video editing. And so one of the examples is like, if you're dealing a lot with like, you know, video editing or you're like, let's say cropping, merging videos, you can essentially use that FFMpeg package that has been written in C++ and then put it over into a web browser to do a lot of these like, you know, web browsers. Today, there are a lot of different video editors that actually use the FFMpeg module, web assembly module to be able to do all things like, like, you know, being able to combine videos, merging videos together. So we have a lot of really powerful in browser video editors that are in use today. So these are some of the ways in which you can actually use web assembly instead of your web application. But of course, the biggest myth of all, right? That web assembly, because of the word, like, you know, web and assembly, web assembly is just for the web. And it's not true, right? Of course, if you have been attending some of these sessions that have taken place in this conference, you might be aware that web assembly today is being used not just in the web, but also in a server side on edge. And that's one of the biggest myths that people have, right? Of course, the other two myths that we covered, those are more sort of when you actually get into web assembly and you really understand what web assembly is. But this is probably the biggest misconception out of all of the ones that we have covered. And it sort of is, like, you know, a completely true that the way web assembly, like, you know, it is formulated. So the standards around web assembly sort of started back in 2015. And 2015 onwards, it sort of really picked up. Originally, the origins of web assembly sort of started from the assembly.asm files. And that is sort of the beginning of web assembly. And I think I was watching this one of these talks recently where they mentioned that, to be honest, like, you know, how web assembly really is, is that it is portable and it is native, right? So we should have probably called it web native. But of course, I mean, at that time, native word itself in tech was not formulated and coined. So I'm talking about, like, you know, 2019 when the CNCF and cloud native truly actually came into being. But yes, it is a bit misleading, but at the same time, like, you know, it's fun that we are now seeing the applications of web assembly not just in the browser. And that's where, like, you know, I mean, this particular definition does not stand true. That, of course, we know that it's efficient. It is a low-level bytecode, but it's not just for the web. In fact, it is also portable, right? Today, we can use web assembly on the server side, on the browser, on the edge, on IoT devices. And these are, of course, just some of the examples that we have today in the entire spectrum of web assembly. And, of course, the ecosystem sort of just goes on and on. So these are just some of the examples. So Crustlet is essentially a project that allows, so if you're aware about cubelets and Kubernetes, Crustlet is a project that allows for, like, in order you to run web assembly applications in Rust. Then we have cloud fair workers that allow for very easy management for, like, you know, CDNs and distributed networks. Then we have the Microsoft Flight Simulator. And a lot of different games today have been actually ported over from their native C++ or actually in Unity, directly to be used directly in web browsers with the help of web assembly. Then we have things like Adobe Lightroom. Actually, this happened to meet one of the folks who was working at Adobe within this conference and they actually gave a talk. So Adobe Lightroom on the browser actually uses web assembly. And Figma, of course, a lot of us who are web designers might be using Figma. That also uses, so all the UI components are written in React, but essentially all the things that it deals with whenever you are, like, creating a new design, all of them are using C++ behind the scenes and it uses some script in to actually with the help of web assembly to do all those heavy lifting tasks. And, of course, I mean, there are a lot of, so coming to some of the runtimes, right? So we're now moving from the browser to the server side and towards containers, right? So we are sort of moving away from the world of web browsers and now we're coming into the world of backend, into the world of servers and containers, right? So these are some of the really popular web assembly runtimes. So we have Wasm Time, we have Wasm Edge, and, of course, you can actually look at 20 plus different types of web assembly runtimes that allow you to actually run web assembly executables or web assembly models in the server side. And you can just follow this link on GitHub to see some of the other web assembly runtimes as well. And, of course, we have some dedicated web assembly platforms. We have folks from Wasm Cloud as well and Fermion as well over here, so thank you so much for attending this talk, which essentially are redefining the way in which applications are deployed and how you can actually use web assembly for things like platform as a service to very easily spin up and deploy applications having a really small runtime. And this is just one of the applications where you can actually use web assembly with Node.js. So, first of all, credits to second state for presenting this particular architecture. So what you can actually see over here is that the standard Node.js back in, or, I mean, the runtime usually like with V8, those are usually written in C++. And, of course, one of the issues that we probably, you might be aware of with Node.js specifically is that usually in most contexts, it is single threaded. Of course, you can make it multi-threaded as well, but very similar to how we describe the use of JavaScript and how you can actually help improve the performance of JavaScript with the use of, let's say, Rust. You can actually do similar things with on the backend side, on the server side as well. So essentially what you can do is you can offload all of your highly computational functions and tasks by like, let's say, writing them in Rust and having them and basically essentially compile them into this web assembly virtual machine, which provides you a very secure platform and a very secure environment in which you can actually execute your tasks. And you can sort of run this together with your Node.js application in order to really make your Node.js applications highly performant. And of course, coming into the world of containers, we know that Linux containers can be really large and can be really huge. And of course, when you have larger containers, they can actually have a really large spin, like, you know, I mean, startup time as well. They will take more time to boot up. But web assembly containers are usually from magnitude of one to 100 times smaller as compared to your standard Linux containers. So if you're actually planning to have some applications run on the edge, you can use the web assembly containers probably alongside your Linux containers as well. And you can sort of build those kind of applications to run really performant applications on the edge. Because usually, edge devices are usually very tightly bound in terms of the overall footprint in terms of like the competition and also the size of these IoT or edge devices. And I highly recommend all of you to sort of go through the state of web assembly article. This sort of covers where exactly web assembly is today in the entire spectrum of the ecosystem for web assembly in 2022. So I'll highly recommend to go through this with sort of covers which are the languages that like, you know, today are most popular when being used with the web assembly and especially from the distributed computing and from the IoT edge devices spectrum. So I'll highly recommend you to go through this article because today, like, you can not just use your standard highly competition languages like C++ or Rust that can be compiled into web assembly, but you can also use scripting languages like Python or even JavaScript that can actually be compiled into web assembly. Very recently during PyCon this year at the end of April, there's a huge announcement for PyScript, which essentially allows you to run Python on the browser with the help of web assembly. So these are some of the examples that you can see to really see how vast the ecosystem from the native browser to actually seeing applications within edge and like, you know, within the entire broad spectrum of containers and server side, you can actually see that and you can, this article is a really good one. Now we'll just go through some of the demos. Of course, we are sort of slightly running out of time. So we'll just cover some of the demos that like, you know, I've just come across and that sort of showcase the entire broad spectrum of how web assembly today is being utilized. So the first one is just running a simple web assembly file in the browser. So I'll just quickly go ahead and I will go to my VS code. Now over here, what we have is that if you can see the web, this particular VS code, I have three files. So the first one is the index.html. Essentially this is the file where we'll be calling our web assembly executable, our web assembly module. And you can see two things. One is the web assembly module itself which is ending with a dot wasm. And of course, you cannot see this because this is a large, like, you know, of course you saw that how the hello world, like, you know, example of how hello world in web assembly sort of looks like. But what you also see is a little more easier way of sort of representing the web assembly and that is the dot WAT file. It's sort of a text file that sort of, like, you know, covers what exactly is defined within your web assembly file. And it's a little more easier to sort of understand. So what we can see is that this example is sort of just giving an example for being able to print hello world. So it will sort of just print hello world from web assembly and this is what the function would be. The hello world will be the sort of the function that we will be initiating from this web assembly module. And essentially what we're doing is that we're going to be calling this within our index.html file. Over here you can see this particular function with this specific one, which is web assembly.initiate streaming. So the way that, like, you know, web assembly sort of works, especially when you're working with it on the browser is. So if you have probably worked with JSON files, right? So you must be knowing that whenever you're loading, like, let's say a JSON file inside of your web application, usually you have to wait until your entire JSON file has been imported and then you are actually able to use it. But the standard way in which web assembly sort of works is that it sort of works in a streaming format. That means that as you actually load your web assembly module inside of your application, it sort of gets compiled as it is, like, you know, getting inserted or it is getting fetched by your application. So you don't have to actually wait for your entire web assembly module to actually get, like, you know, get loaded. It sort of, it does it in parts. So as your fragments of your module get inside of your application or they are fetched, you can easily just use them inside of your application. So that's also one of the major benefits as compared to, like, let's say, JSON format with web assembly. So essentially what we're doing over here in the line number 26 is that we're initiating the streaming where we are actually fetching our web assembly module, which is the hello world wasm file, and we are importing that and then we are basically calling or we are initiating the hello world function that we have defined in our Watt file. And essentially what it do is that once we basically are, we have completed the initiating, we have loaded our web assembly module inside of our web application, we'll basically run this function and we'll be able to see the output. So I'll just quickly go ahead and also run this on a local, just give me one second, I'll just go and click on the live server. And we should see if I just open up from the inspect element, let me just quickly see because it's a little hard to see from here, or I'll just to control the command I. So command shift I guess. Oh, okay. This is better. So if I just open the inspect element, if I go to the console, you should see it saying hello world from web assembly. So essentially this is how, like, you know, we are essentially taking our web assembly module and then initiating it inside of our web application. Now, look at some of the other examples. I'll just quickly go over to the demo two and that is doing machine learning inference on the browser. So of course, a lot of you might be aware that machine learning, right? Of course, some of you might be aware that it's really mathematics at the, like at its core. So whether you're working with, like, you know, KNN algorithm or you're working with neural networks, essentially you're having a lot of mathematics. For example, neural networks, they are basically represented in large vectors in large matrices. So whenever you're doing any kind of machine learning inference, you're doing a lot of mathematical currency at its core. So that's why, like, you know, being able to actually do machine learning on the browser is something that is really powerful. And normally for web browser, like, you know, for web developers or for machine learning developers who want to actually let's say, like, you know, import, like, you know, like, let's say, machine learning into their web application, traditionally you would have to, like, let's say use a Django server or a Flux server, right? And then use that dedicated server. But today we have a lot of different machine learning libraries like TensorFlow.js which allow you to actually write your machine learning models directly in JavaScript. And you can actually preload some of your pre-existing models within JavaScript. And to be able to run these machine learning models on the browser, there are multiple backends that are supported. So some of the ones that you can actually use is like, you know, use your native CPU. Or you could use something like WebGL. You have WebAssembly as well as one of the supported backends that can be used alongside your browser. So essentially what you can do is that you can do your entire machine learning inference on the browser. So coming back to this example, this is essentially a TensorFlow.js model benchmark. So this is a tool that allows you to test multiple machine learning models. So the one that we are going to be using right now is going to be the mobile net. It's a very popular machine learning model to be able to do image inference. And over here what you'll see is that I can choose between different type of backends. So just to sort of showcase the example of how fast WebAssembly is in comparison to just using, like let's say if you were not having WebAssembly and you were just having, let's say, your native CPU to do machine learning inference on the browser. So just remember that we are doing this inference on the browser itself and we are not having a dedicated hardware or we're not having a dedicated server where we are doing our machine learning inference. So I just select the CPU and I will quickly just go ahead and test the connection. Just to sort of show you and run this benchmark. So essentially what it's doing is it is loading the machine learning model inside of your browser. And then it's running, basically it's running your machine learning inference 50 times and you'll essentially see the time it actually takes to do this competition just with the help of the CPU. So of course, since it's just using the native CPU of your system, so it will take some amount of time to actually do that inference. And then we'll see that result over here within this kernel section that probably should take some amount of time. But yeah, I mean, as we'll see that once we select WebAssembly as one of, so as you can see that the time it actually took was 512 milliseconds, right? To do the inference, just using the native CPU. Now if I choose the backend as WebAssembly and if I do this and I run this benchmark, right? So you can see that it is super quick. On the magnitude of more than, I guess, close to 50 times. Yeah, I mean, probably 50 times. And you can see that the inference time that it actually took. So essentially what, again, we are doing is that you're loading your machine learning model onto your browser. At the same time, you're also loading your WebAssembly executable, your Wasm module, and all the inference for the machine learning is being taken care by this WebAssembly executable. That is much more highly-performant than your native JavaScript. And that's what you can see over here in terms of the performance. And this is a really great example of how the performance can also look like in terms of how fast you can actually do that. And finally, the third example that I want to showcase is essentially being able to use WebAssembly as a function, as a service. That means that what we are doing is that your WebAssembly has been deployed onto a server, onto a serverless function, and we are using function as a service, or essentially AI as a service. So for example, for that demo, I'll just quickly go to this particular website. So this is a demonstration by a second state that is like in the team behind the Wasmets project. So as an example, what we are doing over here is that your entire machine learning inference will take place on a remote server where we have hosted our WebAssembly function. And essentially what we are doing over here is that there is a Node.js backend which communicates with a Rust function. And this Rust function is what is actually going to be doing the machine learning inference. And then that Rust function gets converted into the Wasm executable. And that's what then we communicate with our Node.js backend. So over here, I'll just quickly select a file and I just recently downloaded this hotdog. And I'll just click on classify. And as you can see, of course, it's just doing this inference right now. And very soon we should see, as you can see the output is a hotdog. And basically in terms of what's very high is essentially the confidence score of the machine learning model that it is able to rate this hotdog and it has a very high confidence score, probably greater than 85%. So this is an example where the inference of the machine learning is not being done on the browser. Instead, we are having it function as a service where the machine learning model or essentially the Rust code is being hosted as a function as a service in a service function. And it has nothing to do with being able to do machine learning inference on the browser. So let's say if you have a really large machine learning model, you could take that machine learning model, have it deploy a service function, and use WebAssembly as a service function, and invoke that call, let's say, with the help of a front end that you can see over here. So the idea overhead, what I'm trying to convey is, of course, this might sound to be a little more on really heavy on machine learning, but you can similarly do these things as well for any other highly conventional tasks that you might actually come across that involve a lot of mathematical currency numbers. And of course, this particular demonstration is to showcase that how you can actually use WebAssembly today on the server side, on using with containers. So these are just some of the examples that I just wanted to showcase. But yes, you can also just go through some of these resources. So of course, if you really want to get into the specifications for WebAssembly, you can visit the GitHub.com. Today, WebAssembly is not run by a single company. There's the bytecode alliance, which is being contributed by some of the largest companies in the world. And now WebAssembly is also supported by the W3C, which is the web consortium. And that's why WebAssembly today is not just on the web, but it's also beyond the web as well. And you can also just see some of these docs specifically for things like awesome WebAssembly that has a lot of really great resources that you can actually look at for anything related to WebAssembly. That's like some of the courses or some of the applications that have been built with the help of WebAssembly. But yeah, with that in mind, that sort of concludes my talk. Of course, there's a lot of information to be shared today in this session. But I hope that this sort of gives you a general idea about why WebAssembly today is so popular. And I mean, it's a technology that is not just on the browser. It's way beyond the browser as well. And that's why there are a lot of exciting times for WebAssembly, a lot of great things happening on the container side. Of course, we have the folks from Fermin as well who are using it and Wasm Cloud, who are basically revolutionizing how we basically create services on and very easily to spin up these services. So yeah, with that, I'll conclude my talk. And if you want to connect with me on Twitter, you can connect with me on HardLub. Now I'm more than happy to take up any questions. Thank you so much. OK, so that's a good question. So first of all, just to repeat the question, the question is that, is Polygot programming possible with WebAssembly? So interestingly, how you'll take WebAssembly executable is that you'll take one of your target languages, and you'll use WebAssembly as your compilation target. So normally, what will happen is that you'll have, of course, one language. For example, let's say Just Rust. And you can compile it into that WebAssembly byte code. But of course, if you have, let's say, multiple services that you're using inside of your application, inside of your entire framework that you're building, then of course, you can take multiple languages and compile them into the separate WebAssembly byte codes. So that way, it's possible in terms of supporting multiple languages. I'm really sorry I couldn't hear the question. Can we get a mic? OK, so I would say that top three players, it sort of also depends on whether you're like, so the question is, who are the top three players in terms of WebAssembly today? Well, I mean, I would like to sort of expand the question and sort of also speak in terms of for what particular type of application you're trying to use WebAssembly for. So in terms of you're looking at WebAssembly in terms of the browser. So I would say that companies like Figma, Adobe, they are utilizing WebAssembly to the full core to be able to support large highly conditional tasks like being able to do photo editing, video editing, or you are design editing using these tools. Now if you look at from the server side space, today we have a lot of companies like Formion, Wasm, Cosmonic, which are revolutionizing the vein which applications are deployed or they sort of spin up with the help of WebAssembly. So there are a wide spectrum of applications that today WebAssembly is being utilized in. And today a lot of game engines are also putting over their games into the browser with the help of WebAssembly. So there's a very easy way in which you can actually basically compile your, let's say your Unity application into WebAssembly, WebGL executable, and then run those. So a lot of exciting times within the space of WebAssembly, whether it's application related to machine learning, and even there are a lot of different companies like, let's say, especially in the decentralized space, writing smart contracts. Solana is also using WebAssembly as well. So in the Web3, in the crypto space, they are also using WebAssembly for, like, you know, using decentralized applications. Yeah, so first of all, thank you so much for the question. The question is that when would you try to decide when to actually use WebAssembly for running server side applications? Or instead of using, like, let's say a Docker container, when to actually use a WebAssembly container? So as I had described that, one of the biggest advantages for WebAssembly is that when we look at the standard way in which WebAssembly containers behave, they're having a much smaller blueprint in terms of both the memory and in terms of how quickly they can actually load. Now, so that's why when it comes to any kind of application when you're, like, let's say trying to run it on an edge device, or, like, let's say, on IoT, that's where you can actually use WebAssembly containers as compared to Linux containers. And also, another example that I'd like to give is with respect to, like, let's say, and this is a really good conclusion to this particular question, is that you can actually run your WebAssembly containers side by side with the help of, alongside your Linux containers as well. Because there are certain limitations when it comes to the WebAssembly containers, because as I mentioned that WebAssembly on its own cannot really do anything, right? And of course, the supported tool chains that are there with WebAssembly, those are somewhat limiting. But if you are able to run them alongside, like, let's say, the Docker containers as well, instead of, like, let's say, communities cluster, you can utilize those tool chains that are there prevalent with the Docker containers and use them alongside with your WebAssembly applications as well. So just a part of, like, let's say, your application which is being run on an edge device can be offloaded to your WebAssembly container, while the rest of the application can be run alongside that Docker container. So that's also one of the architects that you can actually follow to successfully run your applications on the server side. So the question is, what kind of CI CD tooling is available for WebAssembly? So it kind of depends in terms of just trying to understand the question in terms of, like... Okay, so essentially what you have is your WebAssembly module, right? At the end of the day, what you're doing is that you're taking your target languages, which are, like, let's say, C++ or Rust and you're compiling it into WebAssembly...