 So, hi everyone, my name is Nemanja and I'll be talking today about WebAssembly and especially for enterprise developers. So we'll see what that means and how you can use WebAssembly in your next project. So first question is actually what is WebAssembly or known as BASM? So let's see the definition. It says that the WebAssembly is a binary instruction format for a stack-based virtual machine. And when you see that definition, you guys are probably like, oh, what does that mean? You know, it sounds very confusing. I don't know what it is. So let's see a very kind of simplified explanation for WebAssembly. So let's compare it actually to JS because they run together in the browser, so we want to see how they compare and why it's one better than the other. So when you have some JS code, right, and when this loads in your browser, it's picked up by the browser engine. And the browser engine then actually needs to, first of all, parse your code, then it needs to compile it, and then it's executed on your CPU. So as I said, this is very simplified. There are also a lot of intermediary steps, but broadly, this is what happens in your browser when you load some JavaScript files. And how does WebAssembly compare to that? So when you load WebAssembly into your browser engine, it immediately executes. So why is that? Well, I kind of go back to the same definition here, but I've highlighted the binary instruction. WebAssembly is a binary format, and this means that it's actually already pre-compiled, parsed, and everything, and it's just ready to run in your browser. So what do we get by this? What are some benefits from WebAssembly? Well, first of all, as you saw, it's very efficient because we already pre-compiled this stuff, and this also means that it's very fast because the browser itself doesn't have to do all these steps of parsing, compiling, and all those things. You can just immediately run. When I say portable, I really mean that it's portable because WebAssembly is not a format which is only built by the browser. It can also run in Node, and it can also run in some other environment as well. And one of the good things about WebAssembly is that it works seamlessly with Web. So there is no additional cost that you need to pay in order to run WebAssembly. Once you compile it, you can just run in the browser. And some of the use cases of WebAssembly, and I'm pretty sure that a lot of you already heard about WebAssembly because it's already here for a few years, and usually when we talk about WebAssembly, we hear some kind of use cases for facial recognition, you know, video games. It's a very, I think, quite a lot of usage in video games for WebAssembly, virtual reality or some sort of image or video optimization, et cetera. But you know, I kind of have a problem with that because I think a lot of us, well, most of the developers don't get to work in our day-to-day basis with these technologies or video games or maybe some kind of AR, VR processing and stuff like that. And a lot of us actually work in enterprise. So then you ask yourself a question, well, should I know WebAssembly and should I learn this and can it be also useful in my day-to-day job? And hopefully this talk will convince you that the answer to this question is yes. And where can we actually use WebAssembly in enterprise? So some of the stuff that are mentioned here is data processing is a very common use case, I would say. File and file transfer, file processing and file transfer, it's also very common to use WebAssembly. And today we will be covering the three first points. Some of the other stuff that I kind of have in mind is, for example, sorting or when you have some critical performance optimization, you can actually leverage WebAssembly to improve overall performance or responsiveness of your application. So let's maybe not to talk too much about the theory, let's see some things in practice and how this is going to look like. So here I have some kind of a very simple web app and we will quickly show what this does. So as I mentioned, we're going to talk today about data processing and file processing. And as many of you know, Excel is a go-to tool in small but also big corporations, Excel and CSP files, I think it's very common and I think all of us kind of once, at least once in our careers encountered this. So here I have two Excel files, let's just quickly glance at the data, how it looks like and what are we going to do with this data. So here I have some kind of dummy data, but this is actually a sales record. And I think there are 100,000 records in this CSP file. So you can see here we have some kind of a country items, date of disorder, unit cost and all these things. So what are we going to do in this app is we will be focusing on three columns. That's country, item type and unit sold. So one of the common tasks in any kind of data processing application is to summarize data. You see we have a lot of records here, but for example, let's say that the business wants to know how many clothes have been sold per country or something like that. So today we are going to focus actually exactly on that, we are going to take one item type, for example, clothes and then try to summarize how many units have been sold by country. So let's see that. We mentioned clothes, right? You want to know what happens with clothes. And here in this web app, I have a few sections here which we'll also cover, but there are also here a few buttons which do some things. Since I'm comparing Rust and JS, we are going to take, load this file, process it and summarize data and show it in a bar chart. So let's start with JS and see how much time do we need to process the CSV for 100,000 records. So if I load it here and we get a bar chart and for example, we can see that a lot of clothes are sold in UIA. Of course, this is dummy data, but I think this part is actually the most important one. It's a performance core table and we can see that it took for this task in JavaScript, it took a bit less than a second. So overall, I would say that that's good for 100,000 records, but let's see Rust. Let's see how Rust compares to JavaScript for the same task. So we are doing the same thing here. And again, you see that I have the same data here, however, we can see that Rust kind of is almost twice, twice, two times slower than JavaScript. So what happened? You guys are probably wondering like this guy just five minutes ago, he said that WebAssembly is super fast and efficient, but JavaScript kicked ass with this file processing. Well, today we are also going to learn some lessons about WebAssembly. Well actually there will be only two lessons, but they are very important and I really want you guys to try to remember them because if you are working with WebAssembly, there are some things that you need to be aware of the way how you design your applications. So first lesson is WebAssembly only understands numbers. So what does that actually mean? Let's go a little bit deeper here. I will quickly switch to the code so that you guys can see what happens in there as well. So let's compare it here. So on the left side we have some Rust code and on the right side we have some JS code. So essentially I kind of do the same thing in the beginning. I use this PAPA, PAPA is a CSV parsing library. So I just load the file, use it in this PAPA parse library to parse the CSV and then here I for example pass in my data to the WebAssembly. So this is the part, the WebAssembly part. For the JS I also do the same thing, I parse the file and then I'm using D3 library to do all this summarization and then show it in the chart afterwards. So the important aspect here is this PAPA parse. The thing that is passed to the WebAssembly is actually an array of JavaScript object. So just keep that in mind. So let's see what happens there actually and why WebAssembly didn't perform well. So as I said, WebAssembly only understands number but I just said that when I load the file I parse it and then I send it to an array of JavaScript objects. So what happens in the meantime? There is this library which is called VASM bind gen and this library is kind of generates a boilerplate code for you. So as you saw in my code I still work with JavaScript objects, I still work with something that's familiar, I never turn these things into numbers. That's what actually VASM bind gen does for me, automatically generates this code which does the translation part. So what happens here exactly is when I have this array of JS objects the first thing that happens to these objects they are stringified. So we turn them into string first. And then this string is turned into a number. And then as I said remember lesson number one, WebAssembly can only understand numbers. Then we can pass it down to the WebAssembly. And then we turn these numbers into a Rust struct. Struct is stands for structure and maybe people who are coming from Java or C sharp world it's actually something like a class. So we turn this into something that's familiar to Rust. Then we do our processing and we turn the result back to the JS. So as you saw a lot of things are going on there. But of course I wouldn't be talking here today if I would think that WebAssembly is poor in performance. So let's see if we can improve on this. So here I have a Rust take two and I'm still doing the same thing. So we'll see later what's changed. But I will again load this file and let's see, well that was quite snappier. And as you can see here it hit the number one in our charts. So 400 milliseconds for processing this. So what did I change actually? Let's go back to the code and let's see in the code what happened here. So one of the things now that is different from previous, if you remember, I did the CSV parsing in JavaScript before passing it to the WebAssembly. But now I say, okay, well Rust also has a CSV processing libraries. Why wouldn't I leverage this and do the CSV parsing in this processing inside of the WebAssembly? And this is actually what I do. I just load the file here and then I send the text, the string to the WebAssembly. So let me go back to the presentation and show you how that works. So actually now we see that I've kind of already eliminated one step before I had to turn these JS objects into a string and then the string into a number and then I can do my processing. But now I'm doing it, I'm taking a different approach here. So I immediately load this text, this CSV file as a text, then Vasan Bajan will turn it into a number for me. I pass it to WebAssembly and now this, I added some new steps to my WebAssembly model. I use Rust already has libraries for CSV parsing and I do this processing inside of the module. Again I transform it into something that it's familiar to Rust, execute and return. And you actually saw that this has a huge implication on my speed of the speed of my application. But there is also, if you saw here in my web app, I actually have a third option as well. So can we even take this further, can we even further improve this performance? Let's see what happens and let's see how it compares to the previous approaches. Again, same thing, I'm loading the CSV file and sending it to my WebAssembly module. And you can see that it just got faster, now it's 200 milliseconds. So what do I do differently in this third approach? Well, as mentioned, maybe show it first in the presentation and see. So I said, very important lesson again guys, WebAssembly only understands numbers. And instead of me first of all converting these JS objects or maybe loading the file as a string, I immediately load it as bytes as numbers. And of course this, I can immediately send it to WebAssembly, turn these bytes into some values that I can work with, execute the code and return it. So if you look back at the code, same thing happens, right? But if you look at our Rust code, and these are the three functions that I call here. So funny thing is if you look at it, this first function here, this is the least performant one, but it has the least amount of code, only two lines, but it performs very bad as we saw. And then this middle one, a bit more code, but still performs better. And then actually here, the third one, it has most lines of code, but I think these 10 slides of code are really, really worth it. And if we see our JS part of this application, here we can see when we load the file, file is actually in JavaScript loaded as something known as Blob, and Blob exposes a method, which is known as an array buffer, which is actually just binary numbers. And then this is something that you can pass down to your WebAssembly module. So jumping back to the presentation, lesson number one as we saw, and I kind of rephrased it here, whenever you can talk with WebAssembly in numbers, because as we saw, it really impacts the performance of your WebAssembly module. So lesson number two doesn't have to do exactly with how you load your data or process it. It's actually more on the way how you design your application. So I called it don't cross the JavaScript Watson border often, but what does that actually mean? What do I mean by that? Well, the thing is because of technical reasons, JavaScript has its own memory, and WebAssembly has its own memory. And JS memory can actually read and write into the WebAssembly memory, but the other way around it's not possible. So WebAssembly doesn't have access to JS memory. And when you want to do something, like for example, in my case, I wanted to process some records, some file, or any type of data. I first needed to load this into the WebAssembly module. So this is what I mean crossing the border. Every time when you want to process something, every time when you want to send data to WebAssembly module, this means crossing the border. And as we saw, if you're setting, for example, objects, you are going to pay a big price for this. Think of it as a pay toll on a bridge. Every time when you want to cross the bridge, you need to pay the toll. And it's the same here. And one of the approaches, well, of course, that doesn't mean that we still have to copy over the data to the WebAssembly memory. Of course, we need something to work with. But a good rule of thumb here is that when you want to do this, copy the data once and then keep it in WebAssembly memory and do your computation there and just return the result. Just return back the result. And I think that's a very kind of good pattern to have in mind when building Web applications that run on WebAssembly modules. So those are the two examples. I fortunately have to be cautious of time. So I want to have, if you look at my app there, I have a third example for compression. The code will be shared afterwards so you guys can look in that into more detail. But just to brief what happens here is the second use case, as we mentioned, is in enterprise, there's a lot of files. So if we want to process these files, usually we sometimes need to send them over to the server. And compression can be very useful. Of course, we all know for compression, but in most of the Web application, it goes from the server to the client. So for example, Gzip or broadly, we send some asset, Gzip over the network, the browser decompresses this, and then we can load the application. But with WebAssembly, we actually now have a different, we can make this approach working two ways. We can actually compress some stuff on the Web app itself, send it over to the network, and then decompress it on the server. This actually gives us the benefit of, first of all, saving some bandwidth for the user, because we are decompressing this file, and also it can improve significantly the responsiveness and the user experience. Because for example, if you are running on a poor network, or your upload is not the greatest, and if you need to upload a 20 megabyte file, this can actually take a significant time. So WebAssembly can help you there and decrease this. So there is an example in the repo. If you guys are interested, have a look afterwards and see if you can use this in your next project. So what are the some actually benefits of using WebAssembly in enterprise? As you guys saw it before, it's very fast. If done properly, it can significantly improve performance of your application. The other thing is, I think a lot of people the focus on WebAssembly is actually performance. When people talk about WebAssembly, it's performance performance. But there is this other thing, which I think it's very important and doesn't have enough attention. Actually, this can save your server costs. Why? Because the whole thing, all this processing that we just did, they are done on the client inside the browser. So this means that you don't have to upload the file, send it over to the server, and then, for example, pay some money to AWS to store this file to process it and then return the result. Basically, you eliminate this step completely and you actually use the CPU from the user's machine or a phone. It can significantly save you some costs. Third benefit is it works offline. And for example, if you sometimes, like in these scenarios where we need to process some file or do something, we can still do it offline. And then, for example, when we have a network connection, then we can send the results to the server. It really depends on your use case and the type of application that you have. Another great thing is that we can use the libraries that are provided by Rust and C community. So Rust is a great language and C, I mean, of course, we all know C, it's been around for decades now. And some of the problems have been already solved in these communities, in these languages, maybe not in JavaScript, right? But you can still leverage these libraries and these problem-solving skills and you can use them out of the box in your web application. And one benefit, today we have TypeScript, which kind of gets close to being a statically typed language, but I still think it's not the same compared to something like Rust. So, for example, if you sometimes missed having a statically typed language in your day-to-day work, you can use, for example, Rust to build some WebAssembly modules and use them in your web applications. And from my experience with working with WebAssembly for some time now is the state. It's, I think it's good, as you guys saw, we can already use these things in our application. It's there, it's already been around for a few years. And there are a lot of tools in it, but one of the things that I kind of, my experience is that the tools are still not there. For example, you saw this Watson-Bindgen library, which does tons of work for you. But however, if you have some kind of specific use cases or something is not working, it can happen that you need to go a bit deeper or maybe check the GitHub issues or maybe check the source code of the library to try to find something that works. And also, I think developers coming from the JavaScript of web development workflows, I think we're a little bit spoiled with this React and all these things, for example, because you have the create, react, tab, CLI, all these CLIs and you just run one, two commands and everything is magically generated for you. WebAssembly Rust has similar tools, but I still think it's not one, two commands. Sometimes you need to do a bit more and you need to do a bit more pumping to get it working. But the tools are there and I think they are ready for production because there are numerous cases of companies that have leveraged WebAssembly in their production environments. For example, if anyone is familiar with Figma, the tool for design systems, they actually use WebAssembly for their web application. The second point that I would like to raise is that as we saw from the two lessons that I mentioned, you need to be very careful how you plan and design your code because this can have an impact. And as you saw, if you're unsure, what are you doing? If you're just passing objects around, you will pay the penalty and this will not turn out well. So you need to take into the consideration what kind of data do you have, what's being transferred between JavaScript of WebAssembly and take that into consideration when building your web applications. And the third point, which it's kind of a double-edged sword, I would say, learning Rust. As you saw, I did this in Rust and I have been learning Rust more or less for one and a half years now, sometimes more, sometimes I haven't done anything in a few months. And Rust is an awesome language. And if you look at some surveys, for example, on Stack Overflow, you will see that it's the most beloved language at the moment. And there is actually a reason for this. Once you start working with Rust, you will realize that. But there is also a steep learning curve to Rust because I know other languages. And sometimes when you get in touch with a new language or trying to learn a new language, you can easily, for example, replicate some stuff. So, for example, if you know Python, you can replicate some stuff if you're starting to learn Java or JavaScript or something like that. But with Rust, I think this replication level was quite low because Rust is hard and it really forces you. But I think this is the only language that I have used so far which forces you to think more about your code and about the design of your application because it's a statically compiled language and it's quite frustrating a lot of times that your code will not compile and just show errors. The compiler is very strict. But I think once you compile your code, actually, these errors that you saw actually are forcing you to restructure your application because when you look at your code and you say, oh, okay, maybe I can restructure this differently or maybe I don't need to pass these things around. Maybe I could do it differently. And then once you compile, you are guaranteed that your code, you have a very, very strong security that your code will run properly. And in general, I would recommend everyone but just keep in mind that if you want to go in this direction, you have to invest sometimes into learning Rust. Go is also able to compile to WebAssembly and of course, if you know C from before, you can also use this to build your WebAssembly modules. So after these 25 minutes, I would say, you are maybe probably wondering, like, should I still learn WebAssembly? Well, if you weren't convinced by this, I can again reiterate and say, well, yes, you should learn WebAssembly. I think it's a nice addition to your toolkit and you can use this for some specific problems, maybe smaller scale problems, but it can still be very beneficial for you to write better web applications. So one of the reasons why I think you should learn it as well is what also comes in the future. So WebAssembly, you have to understand, it's very new. I think it started in 2015 by Mozilla. Mozilla is the main driver behind this, but now actually Rust has their own foundation and they are building this independently from all other major browsers. And WebAssembly is constantly being improved. So one of the things that it's going to land, I think, soon is multi-threading. So this actually gives us even more power in our hands. We will be able to use multiple threads to run our applications and maybe to do even more serious computations in the browser. Interface types, I think this is a very interesting thing because it essentially means that the example that I showed that WebAssembly only talks in numbers, this is about to change with the interface types. So we won't have this boilerplate code anymore. We won't need these intermediate libraries that do the translation from JavaScript objects to numbers, for example. This will be already kind of hard-coded inside of the WebAssembly itself. So you will be just able to pass your JavaScript objects to your WebAssembly module and this translation will be done automatically inside. Memory improvements. I talked about JavaScript and WebAssembly having two separate memories. This is also going to change in the future. I don't think they will merge these memories, but I think WebAssembly memory will have more responsibilities and it will be easier for these two memories to interact with each other. And one of the things that I think it's going to make WebAssembly, let's say, more broadly accepted is portability from other languages. What does that mean? So in the beginning, we only had C and Rust. So these two languages, you can write code in these two languages and you can compile them to WebAssembly. As I said, WebAssembly is a binary format. So now you can use these three languages to compile to WebAssembly, but there are some projects currently are going which will allow other languages to also compile to WebAssembly. So for example, Java. Java is a very popular language. I think a lot of people know it and I think this kind of introduction step to WebAssembly is going to be much smaller. The footprint is going to be much smaller because you will be able to write your own language, your language that you are familiar with and then just compile it to WebAssembly and it will magically run inside your browser. And with the interface types as well, it will be possible to, for example, write one WebAssembly in Java, another WebAssembly in, let's say, Rust. And these WebAssemblies will be able to communicate with each other without any knowledge of Java, Rust. There will be great portability between them. And what I think will also happen is that some of the JS frameworks or libraries will move some heavy computations into the WebAssembly. So an example of this can be React. So if you know React and the virtual DOM how this works, I think it's a heavy computation and to determine such things, what changes on the page, it's quite heavy and I think some of these stuff will be moved into the WebAssembly. So do the heavy computation there and then, for example, return the result and as soon you can actually already access DOM from WebAssembly, but I think in the future this accessibility to DOM will be even easier. So I would say great times ahead. If you're still thinking about it, don't think twice and maybe start spending some time learning WebAssembly. So that will be all from me. My name is Nemanja. I've worked for this company called Tsukya for a few years already. So if somebody's actually looking for a job, I think we are hiring at the moment. So you can approach me if you are interested. And if you would like to know more in general about WebAssembly or anything related to web, reach out to me, drop an email. GitHub, this web application that we saw is available on GitHub. I will share the link. And yeah, thank you for listening. Hopefully talk to you guys soon. Any questions? Yeah, I did. I actually am looking for a job and I did apply to your company, I think, but I didn't hear back from them. Anyway, that's besides the point. My question for you is, can I use it to do Rust to do RESTful APIs and all that? Will that be a performance improvement over WebSockets in JavaScript? Or how would that pan out? Good question. So the WebAssembly module doesn't have access to all the APIs that are provided by the browser. So I think for HTTP, I don't think it's provided to the WebAssembly module, but if you know about Fetch, JavaScript Fetch, you can call Fetch from WebAssembly and you can make your REST call. To be honest, this doesn't, I don't think it's an improvement because you will still make this request, right? But sometimes you will be maybe able to save this. You don't need to cross the border between the JavaScript and WebAssembly. So it is possible, but I think in the future, it's going to be even more easier to make these web requests and do your processing in the WebAssembly module. Yeah, if you have to go from JavaScript to Rust to JavaScript back, it doesn't make any sense at all. It depends on your use case, right? If you need to use this data afterwards in your JavaScript, for example, to show it on the screen or something like that, then it doesn't make sense to keep it in the WebAssembly. So you can just transfer it, do the computation and return the results and then just continue processing in JavaScript. I would say it really depends on your use case and what kind of problem are you trying to solve. Correct, yeah, thanks. You said we could use some existing C software from the C community or the Rust community and convert it into Wasm. I'm just thinking, so if we had a C program, we wanted to use it in Wasm, would we also need the source code to all of the libraries so we can compile it all at the same time? No, actually, I can quickly show you that, how that works. So for example, I only have one Rust file here and this is where all my code lies. And here on the top, you see that for example, I import some libraries. So I don't know, Flate to compression, this is a compression library that I used and it's available in Rust. And Rust has something, it's called cargo tumble. Cargo is a package manager for Rust applications I mean, we are all familiar with MPM. Cargo is the same thing basically. Well, I think much better version because it handles dependencies much better. But here you just declare your dependencies, right? And for example, you see here, I use the CSV library for the processing of my file and I use this Flate to compression library and cargo will, when you compile your Rust code, it will pull it down and it will compile all the things for you. So you don't have to go to the source code or do any additional stuff there. Okay, that's great. Thank you. When you said Wasm deals only with numbers, I guess you mean it deals with bytes. Is it like a 64 bytes language? Sorry, 64 bytes. Oh, good question. I'm not sure, but I can actually show you what kind of a boilerplate code happens, what kind of a boilerplate code is generated by the Wasm binding library. So you can see here, for example, they work a lot of with pointers and all this stuff. So they put it on the stack and then here, for example, we take from the memory. So this code here is automatically generated. I'm not sure. I can check for you, but I'm not sure of what kind of bytes are we talking about. Okay. But it saves you a lot of time because you don't have to instantiate the memory. And for example, you see here, people who know C, malloc, it means memory allocation allocate. So some of the stuff it's already done for us. But I think in the future, this will also disappear. It will be completely hidden from a replication. Any more questions? This doesn't look like C at all. If I write in C, it'll compile to Rust or something. Or it'll compile to a... No, no, this here that you see is a JS file. So this is JavaScript. So it doesn't have to do with C. So this code is loaded by JavaScript and the JavaScript is the part which does this translation from a JavaScript object to a number. And then the number is passed to the WebAssembly module. So this is still JavaScript, no C whatsoever. So is this a library we're looking at now? Or compiled code? No, this is compiled code. So if I show you my Rust code, I show you my Rust code. The only thing that you need to do, for example, here I have a class which is called SalesRecordStore. And I just need to annotate it with this Wasm-Bindgen. So Wasm-Bindgen is the library which automatically generated this code and it will be handled by me. And then in my JS code, for example, here, you can see that I instantiate. So I call my module, I import it. And then I instantiate this class and then I can call any method on this class, basically. So if I go back to Rust, you can see here that this is the new, it's essentially like a constructor. And here you can see my methods. And since the class is annotated with Wasm-Bindgen, all this code here will be automatically generated for us. So we don't have to do anything. It does a lot of heavy lifting. And I think it's quite a relief for development. Okay, so this compiled file is then the bridge from JavaScript to Wasm. Is everything in here? Or is it just making the bridge? This is just the bridge. It's just making the bridge. Okay, thank you. But even your Rust code doesn't look like C++, like Imple and all that. This is not C++, it's not C. No, I just mentioned you can do stuff in C, but I don't have any C libraries here. So this whole project is specifically written in Rust. And I would advise to use Rust compared to C because Rust is, first of all, statically typed and does a much better job at memory handling and all these things. So if you can use Rust compared to C. So use case for C is only if you have an existing code in C and then you want to use it in your JavaScript application. But if you're writing new code, I would suggest Rust or maybe Go as languages. Thanks. And this is actually, you can see one of the pattern that I mentioned without crossing the border too often. You can see when I instantiate my class here, I have like a private property of sales records. So this is where I store my data. And when I load it, I just stored it in this variable. And then actually I have a separate method which I haven't exposed. Well, actually I did, sorry, I'm lying. I did expose it, but this method doesn't take data. It just takes the item type and then iterates over that data and does the summarization of it. So you can keep your stuff in your WebAssembly memory and then do processing on top of it. The three ways you pass the data in your tests. You passed a JSON string, then you tried passing a plain string, and then you passed a binary, just a binary data. And then you say in the future, we might be able, there'll be interface types, we might be able to pass structured data across. Do you think that, that seems like the ideal way to me because you probably have your data structured in JavaScript already and you'd like to pass it over structured. Do you think that will be fast or maybe even faster because there won't be any pausing after it's been passed? Well, good question, whatever it will be faster because you still need to convert the objects into numbers somehow, right? The thing is, I think this translation will still happen, but I think if it's done on the WebAssembly side, that probably it's going to be way optimized or maybe they will, I'm not sure about the implementation of this, but maybe they will add some magic code in the browser engines or in the WebAssembly itself, which will make this translation faster. So now we really need to think about this. And you see here, for example, this is something, it's a JS value, right? It's not an, in my JavaScript code, this is an array of JS objects, but here it's a JS value. This is just the type which is provided by the WebAssembly library. So it's kind of a generic value, let's say, and then Watson-Bindgen will know what happens here and it will be, in this line here, it will be able to turn my objects into a vector on an array of my REST kind of a structure here. Okay. But if you can, especially with files, as you saw, passing the array buffer here, when you read the file directly, and it will just make your lives easier. And anytime, actually, when you can pass numbers, do that because it's much more performant. And actually, I forgot to mention that this scales very nice because in the first file, we had like 100,000 records. So if I process a file with million records, it just gets faster. So this other file that I just loaded now, it has one million records. And you can see, for example, here, it only takes two seconds. And with JavaScript, I think it's around 9, 10 seconds to make this work. So WebAssembly, it's made for big problems, I would say, but still, you can use it for smaller optimizations as well. You mentioned that the only use case for using C is you have some existing code, right? So how well Rust versus Go, do you have any advice on that? Good question. I haven't used Go. I am not familiar with the language itself. Go is also new. I know some people here, I think in Singapore in general, Go, I think it's very famous with some startups. So I spoke with some people that, for example, migrated from Java to Go. And one of the biggest problems that they have, they say that there are not a lot of available libraries. So for example, let's say, I don't know, I'm making up now, but data handling or, for example, the CSV processing or some problems that have been already solved in these more popular languages are not there in Go. And then you end up, you have to write your own stuff. So I think Go is still new. Rust has been around for some quite some time. And I think the benefit of Rust compared to Go would be that a lot of C programmers are actually now migrating to Rust. So Rust is not only used, it's actually more used in, for example, embedded software and building something closer to the hardware. And because of this and because of the big community and take a lot of libraries from C have been ported over to Rust. So I don't know much about Go, but I would say because of these things that I've kind of heard from other people, I think maybe Rust would be more appropriate for these libraries. And also you cannot use all libraries. So, for example, WebAssembly can access file system yet. So if you want to load a file from file system, you cannot do this. So the entry point needs to be you pass it in the numbers or in some kind of other format, but you cannot read the file directly from the file system. I was going to say in terms of languages, you can also use C-sharp because on the .NET world you also have the opportunity of using WebAssembly with Blazor. Correct. That's also true. Microsoft has a Blazor framework. I'm also not familiar, haven't used it, but I know about it. So I think it's also, as I said, I think it's going to be even more broader in the future when you start writing Java and then compile it to WebAssembly. So I think then again, it's going to pick up and people that are familiar with their comfortable in their language can use it to immediately compile to WebAssembly. But JavaScript, oh sorry, Java compiles to, I mean, it needs Java runtime, JVM, right? How is that going to, I mean, it's going to be very heavy. Yeah, good one, good one. I know there are projects currently that are doing this, so maybe they will eliminate this part or kind of make the footprint of the JVM smaller. Not sure, but there is an ongoing work for this. I think the one with the C-sharp, the .NET one, the runtime there is about 617K, just to give a, I know that world there, that's how large their runtime is. Oh, that's, yeah. And they are using, I think, the core runtime, the .NET core. .NET core, yes. Okay, yeah. So as you can see, it's still, you know, possible, but let's see how it unfolds. So obviously this web module, VASM is downloaded, you know, like if I go browse to a site which actually uses it, it'll be downloaded and then used and then discarded. Correct, and it's not discarded, it's just as any other file that you sent over the network. So if you can see here on the left side, you have this .VASM file. So this is actually the binary code. Let's see what happens if I open it like this. Yeah, it's not, it cannot be loaded normally, but this is the web assembly format. And this file, you send it to the browser. And if you see it here actually in my web app, and you can check out the code later for more details, but we also need to load this module on the beginning. So here this is where the loading of the module happens, and it's a promise and you need to wait for the promise to resolve. And then once the module is loaded, you're good to go. I mean, it behaves just as any other assets that you would send over from the server. Okay, more questions. Could you also do a progressive web app, the PWA? So you effectively had like an installed app using a web assembly? Okay, I mean, I'm familiar with progressive web apps, but I don't know about the usage of web assembly in these. So for my understanding, I mean, the progressive web ads introduce the service work leverage on this to make the caching easier and all this stuff. But I'm not sure how it relates to web assembly and what will be the use cases. I'm just thinking since it's just a, basically it's a manifest and also the worker one, as you said, you in theory could actually build a web application which would be installable, which had a part of it, which is using web assembly. Oh, I mean, yes, I think it's a two different technologies and two different problems, right? You can, for example, this app, you can make it a PWA and installable. And I don't think it's related to web assembly in general. You can or you cannot use the web assembly in your progressive app. I don't think they're related or need to work without one another. I think they're completely... No, they're not related, but you could use them together. That was what I meant. Oh, yeah, yeah, for sure. I think there are no limitations. So the limitations here are only, for example, you cannot use, as mentioned, old APIs provided by the browser like file system. And the limitation can be, for example, if the library that you want is not available in Rust. So for example, one of the things that I know, Rust poor is and sees better would be image processing libraries. So if you need to compress image or do some kind of image manipulation, I think Rust is limited in that sense. It has some things, but C is way better in that area. I wonder if you could write a game in C and, you know, possible theoretically, right? You don't have to wonder that these things already exist. So if you go Googling, I think you will find at least a lot of examples on this. So there are literally cases, for example, I know Adobe because a lot of their software, I don't know if it's Photoshop or one of these tools that it's used for, you know, graphics and design, a lot of big portion of it, it's written in C. And they were one of the first kind of big consumers of WebAssembly maybe like two, three years ago, even they worked closely with Google to implement this in the browsers. So they literally took their C code and just compiled it to WebAssembly. And on top of that, they just built a UI, a web UI, right, in JavaScript and React, I think, and under the hood, they were reusing their existing code so they could already use it out of the box. So video games or anything or any code that you have written already in C, there is a great likelihood that you can already compile it to WebAssembly and use it in your web app. So we can have a web app with no JavaScript at all anymore. That's actually kind of one of the topics that people are saying, oh, WebAssembly is going to, you know, replace JavaScript, but I don't think this is going to happen because I think they solve kind of different problems. There are actually some frameworks, React like frameworks, where you can write your HTML and all this stuff inside of Rust, and this will be then generated as a web app. But I think, I'm not sure if this is smart enough. I think what JavaScript or web does very good is this separation of concern where you have your HTML and this presentational layer is kind of separated from the other things. And I think the tools around this are far better than in Rust. So I only see the kind of a future where these two things will cooperate. So you will do the heavy stuff in your WebAssembly. And I think most of the stuff will still remain in JavaScript. Yeah, it'll be interesting writing DOM manipulation in C. Yeah, let's see. I know C, by the way. I live in breed C and C++. I used to do C, but I think if I was to do something at that level now, I would probably try Rust because I hear Rust is the new C. All right. Yep, I fully recommend Rust. Beautiful language. I said it's a bit harder to learn, but there are some good tools and I think their community is very good. And for sure, guys, you can use this to learn it. I will share the link to the web app in the chat. So you guys can have a look. I mean, if you guys have any questions about this, just reach out to me and I'm always willing to discuss. Okay, Nermanya, thanks a lot for your talk and for answering all our questions.