Supercharging React Apps with WASM

Of course, like Nataniel said, it's my first time and of course my laptop has to die and I was supposed to show a few demos, but I'll improvise. Anyway, so today, thanks for making it and I'm going to be talking about supercharging React applications with WebAssembly.

Now, but first, let me introduce myself a bit. My name is Mukun, I'm from the south of India. I'm a software engineer based in the Netherlands in Oortek. Previously, I worked as a backend developer, mostly function as a scientific programmer, but slowly I started making my transition into the front-end world. Well, which was a quite an interesting experience. I have a unique perspective to see all these different technologies sharing the limelight, right? Along the way, I discovered Wasm or WebAssembly. I'm going to just call Wasm because it's much easier.

And it was quite intriguing to me, being a backend developer, by trade, you can say. So let's look at the agenda. I'm going to be talking about what Wasm is. I'm going to be talking about how it actually works. And maybe we can do a short comparison with JavaScript. And I'm going to be talking about why you should care about Wasm, right? Why you should care about this new sort of, well, relatively new technology. And then I'm also going to be, well, I'm not going to be showing the demo, of course, but I'm going to be making a few applications with react. Maybe in the speaker's booth, you can actually see the application up and running.

So what is Wasm, or what is WebAssembly? It is a low-level compiler target, which was introduced by W3C. As you can see, the uglier the logo, the more serious the organization is. I actually thought the laughter was going to come, but it's good. You're a good audience. W3C introduced it in 2015, in collaboration with Google, Microsoft, Apple, Mozilla, all the regular targets. Keep in mind I said a compiler target, a low-level target. This means it's not intended to be written directly by a human, but it's meant as a compiler target from source languages like Go, C++, and Rust. There are other languages that are joining soon as well. And they can be all converted to WebAssembly. Now the design philosophy of WebAssembly is to make it as backward compatible as possible. So it must work with the existing web technologies, and so it does. So that is the design philosophy for it to not compete with JavaScript, but to work alongside with JavaScript.

So why should you care about WASM or WebAssembly? You might think, oh, this is just another technology.

It's probably going to be a fad. I'm not going to invest my time in learning it. But I'm going to tell you that it's a bit more interesting, and I will tell you why. There are three reasons. First one, zoom! Well, yeah, it worked better in my head. But it's really fast. But then you also see a tiny asterisk in the bottom, terms and condition. When I say it's really fast, it's really fast in terms of execution speed, which means, since we're talking about source languages like C++, or Go, or Rust, we're talking about statically compiled languages, we're talking about compiling ahead of time, right? So execution-wise, it's set to run at near-native speeds.

Second one is extremely secure. Well, because the binaries, the Wasm binary itself is being run by the web VM, it is rather secure, and there are some concepts like file systems and port that just doesn't exist in Wasm. So it is secure in that terms. And the third one is, it is ultra-portable. It is the industry standard. Now, this might be a controversial opinion, but I will have to tell you that JavaScript has no longer the monopoly over the web. It has officially been, well, it has to share the limelight with the Wasm target, which has other source languages joining in the queue. So that's how portable it is. It can also be run across different device architectures or processor architectures. And, yeah, that's how the portability shines in WebAssembly.

So let's take a deeper look on what really happens beneath the surface. When you have, well, a bunch of C++ code or source languages, well, you have a bunch of code that you don't understand, you send it over to the compiler and most of the compilers, well, most of the compilers based on LLVM support the target being as Wasm. Now, if you remember, I did say that it can be written down in a WAT format and it has assembly in its name. So you can imagine you need to, if you're a genius and if you're crazy, you can also control all the execution and the memory allocation. But then if you're dumb, if you're sane and if you're normal, like me, you just write it in a source language, right? You take this Wasm binary package and then you send it over to the browser and the browser just runs it alongside with all the other great languages that you already know, which is JavaScript, CSS, and HTML. Let's take a deeper look at how this process happens when the browser receives the Wasm package, right? In terms of JavaScript compilation, you can consider it equivalent to the intermediate representation. When the browser receives the Wasm package, it uses the compiler, well the engine's compiler to transform it into a machine code and then this sort of machine code can interact with the rest of your web application to a layer of, well, this layer is just the web APIs. So that's how it is run within the VM. So you might have a question. I've been talking about a lot of Wasm and how it is compiled and how it is run. How does JavaScript do it? Maybe this is already quite familiar to you and maybe also oversimplified, but I'll go through it very fast anyway. So JavaScript can be run on different environments as you know.

It could be client, browser base, it could be node, it could be other environments as well. And it has an engine behind it. Or the engine is responsible for compiling JavaScript code. It has different parts that it uses to compile this code.

So you take this really crappy, bloated JavaScript code that I write, for instance. And then you send it over to the parser and the parser will take care of just scanning through the code, looking for syntax errors. Then you have the abstract syntax tree, which is AST. Well I'm sure, which is fine, because the previous talk was all about AST, so maybe I don't have to explain everything to you. This particular data structure is very suitable to be converted to the final stage, which is just machine code. This is then sent over to the interpreter.

The interpreter does a few interesting things. This is where the whole just-in-time compilation comes in. I apologize for oversimplifying this process, but to keep it brief, the interpreter throws out two different outputs. You have the non-optimized machine code and you have the optimized machine code. In order to get it running as soon as possible, the interpreter spits out this bytecode, which is, of course, from the name. You can imagine it's not optimized, so it's slower than the performance results that it could achieve. But then during runtime, it also sends out profiling data or heuristics to the compiler or to the profiler. It would send more information to the compiler to spit out optimized machine code. This runs orders of magnitude faster than the bytecode, for instance. But then here, if the heuristic or the assumption goes wrong somewhere, then there's this de-optimization process that takes place. And this is the main difference between this process and what WebAssembly does.

So keep this image in mind. How does this compare, or how does this contrast to WebAssembly? And then boom, you only have the equally crappy, but optimized wasm package that you initially compiled from a source language, and then you send it directly right over to the compiler. You see that all of the intermediate steps, all of the fluff, so to say, is not present, and then the compiler takes care of it, and spits out optimized machine code. And the keyword is optimized machine code, because we're talking about statically compiled languages. Here you don't see a process of optimization and de-optimization going on. And that is the primary difference between the two processes, in my opinion.

This is where I was supposed to show you a demo, but I'll just go through the basics of the demo and what it's supposed to represent. One of the demos that I created in my computer, which exists in my computer, it uses image processing techniques. Image processing, if you know, it involves a lot of computationally intensive process.

You need very highly optimized code to carry out any sort of image processing. But then, so you need very optimized code, which means, well, you typically don't use JavaScript to create very optimized performance code in terms of scientific computing. So the problem statement is that you have simple image processing techniques that you have to carry out. You have gradations. It could be converting the image to grayscale. It could be adding or changing color channels of the image. So you have this problem statement, how would you solve it? How would you base your software architecture?

One way is immediately, we can think of client and server type of architecture, where you build different services, you have your front-end separately and then you have your back-end separately, and you can let them interact over a channel, for instance, HTTP, and then you can build a REST API layer on top of your back-end to communicate, to expose your back-end. This is completely fine. This is quite standardized and it's used in production in a lot of places, and then you also see these layers, but then in my opinion, with each layers, you sort of introduce latency and you sort of increase the response time. But I'm looking for rapid response. I'm looking for click of a button, I get my process image back. But that's just, well, you could try to achieve it but there is a sort of limitation posed by that communication channel and also the response time taken by the back-end.

The second thing that you could do or the second approach that you could take is use WebAssembly. Here I sort of take this back-end that you see, it could be written in any framework or any language. Typically, image processing is quite popular with C++, but in this demo that I made in my computer, which is in my computer, I made it using Rust. So you take that back-end and then you sort of quote unquote embed it in your client and then that way you sort of, well, you remove that particular arrow mark, which typically represents the HTTP layer of communication. You have it all in your browser, right? So, if I go back to the slide, now I'm going to be, well, obviously following the second approach, I will take the client-side approach and then I'll also take the out of the box, I already have the package, I don't have to worry about the implementation. Well, implementation approach. I used Wasm library called Photon, it is completely written in Rust, all credit goes to the author, Sylvia O'Dwyer, but then she also did the courtesy of creating a Wasm package out of it, so that all I need to do is just import the Wasm package and then use the functions for my image processing needs. So it's as simple as that. Here I was going to go through the demo, I was going to show you the different image processing, let's just imagine it in your head that it's happening and then maybe I can show you outside of the room. So the second way is of course the Wasm way. Here you see that it is as simple as importing the Wasm package and then for instance if you want to apply a Gaussian blur, which is something that you would do to process the image, you could just call the function and you could get the processed image as an output.

The second demo is, well the demo or the application that I made, is uses a machine learning technique and it's, well if you know about machine learning, it uses a lot of linear algebra, a lot of mathematical optimization. Again very computationally intensive process, right? So in this application I tried to predict the target using a target variable, using multiple features. I used a data set where there are different stocks, well I used the data set where there's a stock of the company over a span of a year and I predicted using different features which is like opening price, closing price, minimum price and maximum price. I do this via a linear regression, if there's any data scientists in this room please don't kill me because this is a terrible way to predict stocks. So, in this application I used two different framers of course. I used an npm install package, believe it or not it was quite difficult to find a suitable package that would give me, or that would allow me to carry out linear regression. And then I also use a wasn't package which I've written using Rust, but don't worry I also use the Data Science Package in Rust to do this.

And the results were quite interesting. When I tested it out with 100 data points, the results were lopsided, because I timed the functions, I timed the model fitting functions and when I used only 100 data points, it appeared that the wasm package was completely outperformed by the npm install package. And there are a few reasons for this, because when you talk about wasm, it's not just that you get a very nice execution speed, but then you also have all this other overhead, because if you remember I told you that the wasm package needs a JavaScript blue code and it can only interact with the rest of the web application using APIs. That is the overhead that usually takes place when you use wasm packages. But then, a nice thing is that if I increase or if I tweak the dataset, maybe increase the density of the data points from, let's say, 100 points to 20,000 points, now I see comparable results. I see the execution times are very comparable to that of JavaScript. Now the point is, I don't want to, well, I cannot prove it conclusively because I can't show the demo, but the point is that I don't want to say that wasm completely outperforms and destroys JavaScript. But the point I'm trying to make is you can already use the wealth of libraries that C++ offers, Rust offers, which dwarfs the NPM landscape when you're talking about scientific applications. So there's a real upside of using mature libraries, libraries that are already built for you. So maybe don't reinvent the wheel.

So to reiterate, why would you use WebAssembly? Why would you care about it? The most important advantage that I foresee is that you can use legacy code. You can reuse legacy code. An example in the industry is that eBay used legacy C++ code to implement barcode scanning feature in their web application. So that's a very good example, right? Because you have something that you can use it in your client-side applications, but not for your web applications. There are multiple examples of this sort when you see Google Earth, when you look at AutoCAD. All of those legacy applications have been ported over to the web application world. And the second one is it is portable. Again controversial opinion. JavaScript is not the only language that you can write for the web. Now there are other languages as well. And then you can target it for different architectures, for ARM architectures, for x86 architecture. And the last one is edge computing. With the introduction of WASM you can actually increase the scope of the functions that you can carry out with smart CDNs. And this is very important because there are a lot of very complex functions that were previously only delegated for high performance or very expensive data centers. But now they can be also performed by a variety of devices. And that I think is a very nice achievement. So these are the advantages and that's all for now. And I'll be happy to take any questions. And thanks for listening. I was impressed, let me tell you that.

That was, A, an intense topic to delve into, like you are so brave. And the fact that you handled it like a pro, amazing. I am going to quickly grab the Q&A, which I completely forgot about to get. If you've got questions coming in, let's see. All right. We've got the first question, which is, when should a developer choose WASM, W-A-S-M, over JavaScript and vice versa? When would you choose? Like I said, if you have a lot of legacy code in your company, and if you're trying to, well, use it as a black box model, black box software, then it's great. If you're trying to migrate to the web, it's a great option to use WebAssembly, and it's also not that difficult to pour over your code. Awesome, nice. Now, I know some people are maybe going to one of the other talks real quick. Do you mind just keeping your voices down so the people who are asking questions can get their answers? Thank you so much.

All right. Awesome. We've got another one coming in from someone else who is anonymous. Would WASM be good to use for sharing a centralized UI component library in projects written in different languages? So have an essentialized UI component library with components built in different languages? That's a good question. Although, I'm not quite sure if you can build full-fledged components using WebAssembly. Because that's one of the very big disadvantages of WebAssembly is that it doesn't really have any APIs to access the DOM. And that way, you're sort of limited in that area. But then, of course, it's still very much in development. Yeah. So much more to come. So much more to come. And also, do you have access to the DOM with WASM? Can you write? I guess this is actually a very, very similar question, right? Do you have access to the DOM, or do you need to call it through JavaScript? Well, you don't have access to the DOM directly. And of course, yeah, you have indirect access to JavaScript. Yeah, that makes sense. As I was asking the question, I could hear it.

What are the examples of WASM in the wild? I know you talked about maybe Google Earth and a few others. Are there any other notable examples? There are a lot of startups that are using Rust libraries, especially cryptographic libraries, directly in their web applications. I think that is a very interesting field. And yeah, AutoCAD is an engineering application that was typically only client-side. And now, it's available for the web. I love it. I love seeing some of these really, really big things that were very heavy almost, being able to be more open for more people to use and access. Also, one more notable example is Figma, which also uses didn't know that. Today I learned. Today I learned.

OK, another question for anonymous. Since we're skipping the optimization step using WASM, we would lose runtime optimizations then? Or are we just skipping the initial optimization? I'm not sure which optimization that should that the quite if I remember correctly. On your side, you had the one with all of the different steps, and then the code was not optimized first. And then it was right, optimize and reoptimize. But now in the next one, when you showed are we skipping that optimization step? I'm trying to interpret the question. Sorry. Are we skipping that initial one or are we still doing runtime optimization? Well, like I mentioned, you don't really have the optimization, deoptimization cycles. But it also depends on the source language that you use. If you use, for instance, C++ or Rust, it is already quite fast and they don't feature sort of like a garbage collector. So the performance is quite fast to begin with. And that's that's the main reason you don't need deoptimization step.