Supercharging React Apps with WASM

Rate this content

WASM has taken over the web-development scene in the past few years. It is a language that can be run by the web platform alongside with Javascript. Being treated as a target language, a variety of low-level, statically-typed languages such as C++ and Rust can be compiled to WASM. Thus, a variety of complex, computationally intense applications can now be tackled through readily available web applications. Demos of 2 such applications are shown in the presentation and a side-to-side comparison is done next to JS code.

25 min
02 Jun, 2023

AI Generated Video Summary

WebAssembly is a fast, secure, and portable technology that challenges JavaScript's dominance on the web. It allows for the use of legacy code and expands the scope of functions that can be performed on various devices. WebAssembly can be used for image processing and machine learning, and it has potential applications in UI component libraries. Startups are already incorporating WebAssembly into their web applications, and optimization and performance are key advantages of this technology.

1. Introduction to WebAssembly

Short description:

Today, I'm going to be talking about supercharging React applications with WebAssembly. I'll introduce myself, discuss what WebAssembly is, how it works, and why you should care about it. We'll also explore its design philosophy and its compatibility with JavaScript. Stay tuned for some exciting applications with React.

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.

2. Benefits of WebAssembly and JavaScript Execution

Short description:

WebAssembly is fast, secure, and ultra-portable, challenging JavaScript's monopoly on the web. It can be written in source languages like C++, Go, or Rust and compiled ahead of time for near-native execution speed. The Wasm binary is secure and lacks certain concepts like file systems and ports. It is the industry standard and can run on different device architectures. When writing code, it is sent to the compiler, which supports Wasm as a target. The Wasm binary package is then run alongside JavaScript, CSS, and HTML in the browser. The browser's compiler transforms the Wasm package into machine code, allowing it to interact with web APIs. JavaScript, on the other hand, can be run on various environments.

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.

3. JavaScript vs WebAssembly

Short description:

WebAssembly eliminates the intermediate steps and directly compiles optimized machine code. This is the main difference between WebAssembly and the traditional JavaScript process. Image processing demos involve computationally intensive processes.

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.

4. Image Processing and Machine Learning

Short description:

To solve the problem of image processing, you can either use a client-server architecture with a REST API layer, which introduces latency, or you can use WebAssembly to embed the image processing code in the client. I used the Wasm library called Photon, written in Rust, to simplify the implementation. For the second demo, I used a machine learning technique called linear regression to predict stock prices. I used both an npm package and a custom Wasm package written in Rust for this application.

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.

5. Advantages of WebAssembly

Short description:

WebAssembly offers the advantage of using legacy code, such as C++ and Rust libraries, which are already built for scientific applications. It allows the reuse of legacy code in client-side applications. WebAssembly is also portable, enabling the use of languages other than JavaScript and targeting different architectures. Additionally, it expands the scope of functions that can be performed with smart CDNs, making complex tasks accessible on various devices.

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.


Choosing WebAssembly over JavaScript

Short description:

If you have a lot of legacy code in your company or if you're trying to migrate to the web, WebAssembly is a great option. It's not difficult to pour over your code.

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.

WebAssembly for UI Component Library

Short description:

Can WebAssembly be used for sharing a centralized UI component library in projects written in different languages? The disadvantage of WebAssembly is the lack of APIs to access the DOM, limiting its capabilities in that area. However, WebAssembly is still in development, and there is much more to come. While WebAssembly does not have direct access to the DOM, it can indirectly access it through JavaScript.

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.

Examples of WASM in the wild

Short description:

Web applications are utilizing WebAssembly (WASM) in various ways. Startups are incorporating Rust libraries, especially cryptographic ones, directly into their web applications. AutoCAD, previously limited to client-side use, is now accessible on the web. Another notable example is Figma. These advancements in WASM allow for more accessibility and usage of large-scale applications.

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.

Optimization and Performance in WebAssembly

Short description:

When using WebAssembly, you don't have the optimization, deoptimization cycles. The performance is already quite fast, especially with languages like C++ or Rust that don't have a garbage collector.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
Vue.js London Live 2021Vue.js London Live 2021
8 min
Utilising Rust from Vue with WebAssembly
Rust is a new language for writing high-performance code, that can be compiled to WebAssembly, and run within the browser. In this talk you will be taken through how you can integrate Rust, within a Vue application, in a way that's painless and easy. With examples on how to interact with Rust from JavaScript, and some of the gotchas to be aware of.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn