Supercharging React Apps with WASM

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more

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.

This talk has been presented at React Summit 2023, check out the latest edition of this React Conference.

Watch video on a separate page

FAQ

WebAssembly (Wasm) is a low-level compiler target introduced by the W3C in 2015, designed to be a compilation target for source languages like Go, C++, and Rust. It aims to work alongside existing web technologies such as JavaScript, enhancing performance without replacing them.

Developers should care about WebAssembly because it offers significant performance improvements, enhanced security, and portability across different device architectures. It allows for the use of more powerful programming languages within web environments, potentially improving application capabilities and efficiency.

No, WebAssembly cannot access the DOM directly. It needs to interact with the DOM indirectly through JavaScript, which can limit its ability to manage user interface components directly.

WebAssembly is designed to execute at near-native speeds because it is a compilation target for statically compiled languages. This allows it to perform faster than JavaScript, especially in applications requiring intensive computation, such as image processing or scientific simulations.

Practical applications of WebAssembly include high-performance web applications like Google Earth and AutoCAD, cryptographic operations in security-focused apps, and complex image processing tasks directly in the browser. It's also used in platforms like Figma for design and editing purposes.

Debugging WebAssembly applications in the browser is currently challenging and not as mature as debugging JavaScript. Developers often need to rely on running and debugging the source code locally in the original programming language, like Rust or C++, before compiling it to WebAssembly.

Integrating WebAssembly with existing web technologies requires some setup, especially in handling interactions between WebAssembly modules and JavaScript code. However, it is designed to be backward compatible and work seamlessly with current web standards, making integration feasible with some technical effort.

WebAssembly enhances security by running in a sandboxed execution environment within the browser, similar to JavaScript. This isolation helps prevent malicious actions and access to the underlying system, contributing to safer web applications.

Mukkund Sunjii
Mukkund Sunjii
25 min
02 Jun, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
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.

QnA

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

A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
Utilising Rust from Vue with WebAssembly
Vue.js London Live 2021Vue.js London Live 2021
8 min
Utilising Rust from Vue with WebAssembly
Top Content
In this Talk, the speaker demonstrates how to use Rust with WebAssembly in a Vue.js project. They explain that WebAssembly is a binary format that allows for high-performance code and less memory usage in the browser. The speaker shows how to build a Rust example using the WasmPack tool and integrate it into a Vue template. They also demonstrate how to call Rust code from a Vue component and deploy the resulting package to npm for easy sharing and consumption.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
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 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
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 Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
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.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
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.