Beyond JavaScript: Unleashing the Power of WebAssembly for Faster Web Apps

Hey, everybody. My name is Nathan, and I am here today to talk about WebAssembly. Just a quick show of hands, I want to see who all here have heard about WebAssembly or know how WebAssembly works or what is the usefulness of WebAssembly. All right. The main reason I ask this question was because most of the developers I found out there either have not heard about WebAssembly or even if they have heard about WebAssembly, they are not really sure how to use it. They feel it's like a gimmick. So that's where I come into the picture.

Give a short 20 minute demo. We will see some real world applications. We will see how few other brands are doing it on their production apps. We will compare the scores on vanilla JavaScript on React with Rust WebAssembly. So let's jump right into it. So the problem is that the JavaScript was not built for performance. Over the last few years, JavaScript has seen a lot of improvements. The just in time compiler, the garbage collection, all of that has really made JavaScript a strong language.

But at the core, JavaScript was not made for performance. It was made for developer productivity. And when tasks like CPU intensive tasks like image processing or bulk data processing comes into the picture, JavaScript often struggles. We can have image optimization techniques, we can have lazy loading, memorization, code splitting, but all of those really help with IO related tasks, not CPU extensive tasks. And that is the exact gap that WebAssembly fills in or like we call it WASM. So that WASM is here to offload these CPU intensive tasks and really show you the performance of the CPU gains with the JavaScript as an.

Now, I know many of you would be having the same experience as this person that you have, you are hearing the WebAssembly for the very first time and not really sure from where to start. So be with me, I would be starting with very basics explaining what WebAssembly is, and then we will jump deeper into some practical demos to it.

So WebAssembly is a way to run fast, low level code in your browsers. JavaScript is a high level language. Now, what is the difference between a high level language and a low level language? So JavaScript doesn't give you a way to dynamically allocate a memory to a variable. On the other hand, languages like C, Rust, C++ gives you a dynamic way you can allocate the memory. Right.

So since you can allocate the memory yourself, you can more proficiently utilize the CPU, the raw power of CPU. The high level languages, like I said, JavaScript is meant for developer productivity misses out on this dynamic memory allocation. And that is where the WebAssembly comes in. It acts like a bridge between the web browser and the low level code. Using WebAssembly you can use C, C++, Rust, all of that onto your web browser. The web browser is not just limited to JavaScript anymore.

So WebAssembly does all the CPU heavy lifting work and the JavaScript takes care of user interactions and rendering components onto the user screen. And with that, it's the demo time. I know we have just talked about like two slides into the WebAssembly, but I want to give you a real taste.

Let's go to the web browser, see WebAssembly in action, see how it compares with vanilla JavaScript. Once we see and gauge the actual performance difference, then we would be able to relate to the code a lot better.

So let me switch to the browser. And let me run a tab. This is a very basic HTML file where you will see two buttons and both of the buttons will have a different page. Let me open both of them in separate tabs.

The first tab is with the vanilla JavaScript version and the second tab is with the Rust and Wasm version. On the first page, you will see an option to upload an image. Let's do that. I will upload an image of 6.5 MBs. This is the original image we uploaded, with clear colors. There is a process image button that, when clicked, applies predefined filters to the image. As soon as I initiate the processing, it starts, taking a few seconds to complete.

Now, in the second tab with Rust.html, I upload the same 6.5 MB image. Clicking on 'process image' shows instant processing. The output matches the one from the vanilla JavaScript file, but the processing time is significantly shorter. In Rust, it took only 638 milliseconds, less than a second, compared to the vanilla JavaScript's 6900 milliseconds, around six to seven seconds. Consider the impact for batch operations on multiple images or adding watermarks to numerous images.

It looks visibly different. We have applied sepia, soft glow, sharpness, and contrast tweaks, taking around 6900 milliseconds, roughly six to seven seconds. Now, in the second tab with Rust.html, uploading the same 6.5 MB image shows instantaneous processing, producing the same output as the vanilla JavaScript file but in 638 milliseconds, less than a second.

Consider the impact of this speed difference for batch operations on multiple images or adding watermarks. JavaScript would struggle with such CPU-intensive tasks compared to WebAssembly. Let's shift focus to code details. The HTML files for both vanilla and Rust highlight the difference in complexity, with Rust excelling in efficiency for image processing tasks.

WebAssembly shines in CPU-intensive tasks, offering a smoother user experience with faster processing times. Transitioning from iPhone applications to web-based platforms with multiple filter options and drag-and-choose features would be challenging with JavaScript. Visualizing the code in action provides developers with a more tangible understanding of the efficiency gains brought by using Rust and WebAssembly.

The output is exactly the similar what we got into the vanilla JavaScript file. The processing time is six, three, eight milliseconds. That is less than a second. In our vanilla JavaScript file, it was taking ten times longer to perform the same set of operations. And these are identical filters. There is no difference in the kind of filters which we have applied for both the sims.

Now think about if you wanted to do the same operation on 100 images. If you want to apply watermark on 1000 images or let me just switch to the PPT and see. This is our iPhone application. It allows users to choose among 15 plus filters within each filter the user can drag and choose the value from plus 100 to minus 100. And with the tap or slide of their finger, the user can see the visible difference on their screen right there. If we have to give this experience to the user on the web, it will be very struggling experience for JavaScript. So WebAssembly really shines in these CPU intensive tasks.

Now, we have spoken a lot, we have seen a demo, but we as developers don't really relate to the things unless we have seen the code. So now let's jump into the code data. I'm using visual code data. And let's look at the HTML file. So this is the home HTML where we had two buttons of vanilla HTML. And RUST if I open both the files. The vanilla file, as you can see, it's a pretty basic file which allows has a upload button, a process button. As soon as the user clicks on the process button, some processing starts. It is using vanilla.js file.

In the vanilla JavaScript file, you will see when the user clicks on upload image, there is some processing happening. But when the user clicks on the process image button, these are the filters which we are applying. Adjusting brightness, applying blur, adjusting contrast, pop color, soft glow, CPL, all of that. And all of these filters are nothing but some JavaScript methods. We are just tweaking the image data. We are changing individual pixels of the image and applying some specific predefined formulas on them. So when we want to apply blur to a particular image, we change each individual pixel of that particular image in a specific way so that the blur filter can be applied. And same is the case for all seven of these filters.

Now, let's look at the same experience inside our RUST files. In RUST.HTML, instead of using vanilla.js, we are using RUST.VASM.js. The RUST.VASM.js also has a very similar flow as in we have the event listeners, we have the image upload function, we have the process image method where we are applying all the filters. The only difference between this and the vanilla JavaScript was in our vanilla JavaScript file, all of those methods were defined within the file. These are JavaScript methods. Whereas in a RUST.VASM.js, all of these methods have been imported and these are imported from a package. These are coming from a RUST project. And I will show you how I added those RUST projects and where the WebAssembly comes in the picture. So that is the only key difference. Instead of defining these CPU intensive tasks in our JavaScript file, I used RUST based methods and use them to reduce the computation time.

This is our image filters folder where I have my RUST package. If I open the source, you will see a RUST file. This RUST file has exactly those seven filter methods. And these are doing the same set of formulas, which I mentioned that we are tweaking the pixels only in a RUST syntax now. So the functionality which we are implementing is identical, the only difference being the syntax for the RUST. The key thing which you will see is each method has a VASM bindgen on the top of it. So this is what allows RUST methods to be inside to be used inside a JavaScript file. We were able to import all of these seven methods because inside a RUST module, each of these methods has VASM bindgen written on top of it. In the package folder, you will see a VASM file, so whenever you build your RUST module, we will see the build commands as well. Whenever you build your RUST project, you will see a VASM file and some glue code. This VASM file is a binary coded file which cannot be opened inside our code editor.

This VASM file is a binary coded file which cannot be opened inside our code editor. But if we go to our project. Let me show you the next tab. If I reload, you will see in our network tab, this VASM file has been downloaded over the Internet and also the glue code, which I mentioned. This glue code is nothing but a way how we can connect JavaScript and RUST methods. Cool. So that was fun, we saw that how we were able to reduce the time by one to one tenth to do same type of operations. We also saw how we could do it using JavaScript and RUST.

Now to give you the overview again, JavaScript loads the VASM binary file we saw in our network tab, the JavaScript is loading the VASM file and this has been loaded. Why? Let me show you again this init method. So these seven methods are the methods which we defined, this init method is the VASM method, which is which is provided by VASM itself. So this initialize method is what initializes VASM and downloads the VASM package over the Internet. That is the very first step. Once we have done that, then there is a glue code, the VASM bind gen which I showed you in the code, that is the glue code. It acts as a bridge, it initializes the VASM module. It converts the JavaScript types into the VASM types and it allows from a RUST VASM.js file to call those methods.

When the JavaScript call these exported methods, the browser can then execute the VASM bytecode directly. And the same can be implemented in React as well. The only difference while implementing the same thing in React is you will have to use useEffectHook because we want to initialize it only during the first render. And the same init method will be used, which I just showed you that how we can import it. On useEffectInit, whenever the VASM file has been loaded, the binary file we set at state to true, set VASM ready to true so that we can understand and console the same thing. Now, we have seen that the performance gain was huge, 10x. But why? We understand that JavaScript is high level. We understand that VASM was low level. But what is the key principle that is taking place to see such a huge performance gap? So there are three main factors. The first one is JavaScript is a high level, dynamically typed language. Whereas VASM is ahead of time compilation. So what I mean by that is in JavaScript, it is dynamically typed and there is a just in time compiler which is constantly trying to optimize your code. It tries to deoptimize your code. There is garbage collection.

So the processing of the entire JavaScript code is quite huge and it takes some time. Whereas VASM, as it says, is ahead of time compilation. So at the time of compilation itself, the compiler can predict. What data types to expect, and it does not have to keep on re-optimizing your code, that saves quite a noticeable chunk of time. JavaScript variables are dynamic. For example, if you have done let a is equal to five and later you can say a is equal to a string, right? You can change the type, the data type in JavaScript and the just in time compiler has to constantly keep a track of this. But in VASM, since it is strongly typed. You cannot have this constant updation of data types and hence is a lot of data, a lot of time in the CPU optimization can be achieved with this.

And last but not the least, JavaScript objects live on garbage collection heap. So like I mentioned, since JavaScript is a high level language, we do not have the control when to allocate or deallocate the memory, the garbage collector of the JavaScript does that for us. Whereas in VASM it uses linear memory, let's see that in a short diagram. So as you can see in the JavaScript execution pipeline, the browser first parses the code, it tries to compile just in time, it tries to optimize it, then it tries to reoptimize if it understands that the variable types are changing, it tries to execute the code and at the later stage it tries to garbage collect to free up the memory.

In WebAssembly, as you can see, the pipeline is a lot simpler as a result, a lot faster as well. It just have to decode and since at the compilation time it knows and it's predictable, it does not have to constantly compile, constantly optimize and reoptimize the WebAssembly. So, well, if we are seeing such a huge gain, should I rewrite all my existing JavaScript applications in Rust? Well, I don't think so. There has been a recent trend that a lot of people are migrating their existing apps, JavaScript apps into Rust, but that is not the best approach. There are a few caveats, of course. So the first and the biggest caveat, the first biggest hurdle of VASM adoption is that you cannot directly access DOM from VASM.

Be it Rust, be it C, C++, since these are low-level languages, they do not understand HTML, they do not have access to window object or document object. So the JavaScript has to do that. JavaScript can offload CPU intensive tasks to VASM and the VASM can do that. But the DOM manipulation should only be done by JavaScript. That is the suggested way.

The second point would be about garbage collection. If we are having too many calls between JavaScript and VASM, there could be a clash that the JavaScript gets confused when to garbage collect the value and when not to garbage collect the value. And it can have adverse effect plus the binary size. If the binary size of your VASM file, which you showed in the network tab, if that increases, that can also add to the downloading time of the network tab. So that is not the best case as well. So only reduce the size, only use it wherever needed to get the performance boost that VASM promises to provide you.

Figma, eBay, all such big names have used and noticeably gain significant performance. These are a few links which you can try to view. I have added a few screenshots from Figma. So Figma was able to reduce their load time by 3x. You can see a few of the graphs as well. They were able to reduce their loading time on Firefox browser by 3x, and if you have used Figma on web, you will see how fluent their app is. They are quite heavily using VASM to achieve that native like experience. So if you want to use VASM in your projects, it's very simple.