React Advanced

React Advanced Conference 2022

Server-Side Rendering Using WebAssembly

Hello, everyone. I'm Shivai Lamber. I'm Wasim's ambassador and also a TensorFlow.js SIG and working group lead from India. Welcome to my talk at React Advanced. I'm presenting virtually from India. The title of my talk is server-side rendering using WebSIMP. So, let's get started. So, the first thing we'll talk about is how do we actually achieve server-side rendering? Now, the traditional ways is either to, let's say, use a React framework like NestJS that actually supports server-side rendering out of the box. Or if you are one of those engineers who would want to set up server-side rendering manually, you could create a fresh Redux store on every request that gets sent out and then get the state out of the store and perform the server-side rendering. Or another alternative way is also to actually set up an express server that can be used to serve the contents from the build directory as static files to your front end. So, first, before we move on to how you can achieve server-side rendering with WebAssembly, let's talk about WebAssembly a bit more. So, WebAssembly is a language that is neither related to web directly or related to the WebAssembly language itself. What it is, is really an efficient low-level bytecode that is highly performant and is portable, secure, and language-agnostic compilation-tact. So, that means you can basically take any of your highly performant programming languages like C++ or even scripting languages such as Python or Go and compile it into a WebAssembly bytecode that can be directly used. Now, why has it been so popular? It can basically reduce some of the disadvantages that we have in terms of performance, especially with JavaScript, and can overcome those performance limitations by using the more performant programming languages like C++ or Rust and converting them into WebAssembly and then running them on the browser alongside JavaScript. And now, WebAssembly is not just limited to the front end or the browser and finds a lot of different use cases in server-side and cloud applications as well. And what exactly is Wasmage? So, Wasmage is a lightweight WebAssembly runtime that is primarily focused on building a lot of cloud-native and edge-based applications. And Wasmage is currently CNCF, which is the Cloud Native Computing Foundation Sandbox Project. So, the question is that how can WebAssembly be used to actually implement the server-side rendering? So, Wasmage, as we mentioned, is the runtime for WebAssembly, especially for edge devices. The Wasmage JavaScript SDK runtime actually provides a lightweight and high-performance container which can run both JavaScript and also the React server-side functions on edge servers. So, let's say if you have very limited resources and very less computation power, then you can run these lightweight WebAssembly containers on edge applications and still be able to have performance functions being run very smoothly. And the Wasmage QuickJS is basically very similar to how V8 functions. It's a JavaScript engine. And the Wasmage QuickJS engine is able to actually render React app-based components on the server-side and then basically send that rendered HTML as a string to the browser. And it primarily supports both the static-side rendering and also the streaming rendering that's provided from the server-side. But the biggest question is that why should we use WebAssembly in the first place to implement server-side rendering? Because we already have such popular frameworks such as LinuxJS and also you can set it up manually with Node.js. There are primarily two different reasons I'd like to point out why WebAssembly is useful. Now, compared to the standard approach in which the V8 runs, it uses Node.js and a Linux-based environment, Wasmage and especially WebAssembly has a much smaller footprint in terms of the overall size and how quickly you can actually spin up a WebAssembly-based container. So, in terms of performance, it's a lot more faster and especially when you're working with very limited resources on an Edge application or an Edge device. And this does help with more improved load times and performance gains, especially if you're running your applications on the Edge. And secondly, the Wasmage also provides isolation and protection because of how WebAssembly manages memory by providing a sandbox layer around whatever application that you're using with WebAssembly. So, that means that the Wasmage implementation for server-side rendering is able to basically execute whatever code is being run in that sandbox environment that is the footfall for how WebAssembly actually works. And that's one of the biggest benefits of performance and both in terms of privacy as well. So, let's take a very quick glimpse into how you can actually enable server-side rendering with WebAssembly with a very simple Create React app that if you have already used React, you might have used the Create React app. So, the first thing is to basically install some of the dependencies. So, this includes installing a programming language which is Rust because we'll be basically compiling the Rust code into a Wasm that is a WebAssembly executable. Then we'll also use the Wasi, the WebAssembly system interface that allows you to basically interact with the server-side and the even networking components of your computer. And then we'll also install the Wasimage which is the runtime for WebAssembly, the CLI for that and the QuickJS Wasimage toolkit as well. So, we have provided those links on the slides. You can go through and install these separately. Now, once you have done that, we'll just go ahead and install a very simple React app using the NBX Create React app. And now, we actually come to the most important step which is actually converting our code into server-side rendering. So, primarily what we're going to be doing is that we're going to be using the Wasimage container which will be able to run our server-side rendering code and be able to actually run our React JavaScript. So, first let's create a new directory which will be server and within that we'll create a new file, index.js. Now, you can basically populate that content of that index.js by going to this file that I've created and you'll find that code over here. It's primarily just going ahead and running a simple Node.js app and this also is able to... it also has some components related to the WebAssembly where we are basically rendering the actual server, basically the code of the React.js code inside of our Node backend. So, I'll recommend you to go and check out this particular code base and once you have done that, once you have added this particular code to your index.js file, then we'll proceed. But, just to kind of answer what's happening behind the scenes. So, basically the server that we are creating right now which is the Node server, that is basically rendering the app component and instead of sending this app component to the frontend, what we're doing is instead we are sending that rendered HTML back to the browser. And, primarily if you see that in standard cases with React, the React DOM server rendered string is used to typically render the app into an HTML string. And, basically that's what we are sending to our browser in this case. So, basically now what we're doing is that the app's content is being injected into the div element with an ID of the root. And, now it's being sent back as an HTTP response to the web browser. Now, once you have created that index.js file, we'll go ahead and build and deploy our application with the help of rollup.js. Again, we have provided a config file for rollup in case you are interested to use that. Again, that is provided in the second gist which is over here, which is the rollup.config.js. This is responsible for not only going ahead and building but also deploying the server-side code that we have created inside of the index.js file. So, once we go ahead and deploy our code with the help of rollup.js, the last few things that are left is first of all adding some of the dependent packages into our package.json file. These are mostly related to the rollup package that we have just installed in our previous slide. And, the last thing that we have to do is updating our script section. So, this is primarily used to be able to actually run the Boss Image server from the Boss Image CLI that will help us to first take our Rust code and convert it into the WebAssembly bytecode. And then, actually this will serve the purpose of also taking your quick.js code which also invokes the webpack and the configuration file. And, this will be helped to serve our build output and serve that to our frontend. And finally, we'll just go ahead and run the following commands to first go ahead and build our application and then render the HTML string on the browser. And, finally, before we see what exactly takes place or what's the output, let's examine what is the actual change in the app before and after we have actually enabled the server-side rendering with the help of WebAssembly. Previously, the HTML source was simply just putting out the template with the server-side rendering placeholders. But now, once the server-side function is running on the server and we are fetching our HTML, the generated HTML string from the server and we are rendering it onto a browser, you can see that in the lower corner what you can see is that now we also get this data react root. Now, this is what is being fetched from our server that is rendering our static files and that's what is being rendered now on the browser. And that's how you will basically start to see it in live action once you start rendering it. So, what's more in terms of support for server-side rendering with WebAssembly? There is a current support for React 18, which is the latest version of React. And you can also actually create streaming applications because of the functionality that comes with WebAssembly. It allows you to actually create this kind of streaming applications because of the way in how WebAssembly actually loads itself on the browser. Instead of, let's say, a static JSON file, the WebAssembly bytecode basically comes under a streaming fashion and gets loaded into the browser in a streaming fashion. So, you can also create streaming applications. The one that we showed was a static application. With that, I'd like to conclude my talk. Thank you so much. In case you're interested to know more, you can connect with me on my Twitter, at TheThoudWeb. I keep posting a lot on WebAssembly and WebAssembly is a really futuristic technology and one of the technologies to look out for, especially today and in the next few years, especially for both applications on the front-end browser and also equally on the server-side and in cloud applications. With that in mind, thank you so much and I hope that you enjoy React Advanced. Thank you very much.


Shivay Lamba

React Summit

React Summit 2022

Dear Client, I'm Leaving You

Liad Yosef

The Only Way to Eat an Elephant - Code Splitting With Server Side Rendering

Hi, my name is Lena and today I'm here to tell you about the only way to eat an elephant. You can probably remember it bit by bit. And I have one disclaimer to make. No, I do remember it's a React conference. But I will be telling my brief story of SSR code splitting and why you need to use them both using vanilla JS mostly. So it all started at the time when there was no React. Someone does remember these times and someone can't even believe that there was such time when there was no React. But that time all HTML pages were served as strings. You wouldn't believe that. But the whole content was a string served from servers and it looked something like this. One road for a whole HTML content and there were many of them as much as many roads you have. And actually everybody was happy that time. It was pretty straightforward actually until there they were not. And you can probably guess the reason. It was because of JavaScript. So it became too tedious to handle all the JavaScript, all DOM manipulation with jQuery, you know, with rendering tools like EGS, handlebars and many, many more in every server language. And also the server round trips made people suffer. And I can hardly tell you who suffered more, users or developers with all their JavaScript jQuery and handlebars. So JavaScript heroes came and they decided to have SPAs, single page applications. And they were imagining rendering content, all the content on the client side. And they decided that browser can handle navigation without going back to server. And they think, they thought it was cool. And also they decided they can do client side routing. Not because it is easy but because it is hard. But they can. And they changed the HTML because it became very small and shallow. And nothing actually was rendered on server anymore. Everything was rendered in client side with one of JavaScript frameworks. And there became more JavaScript. More tools to build it in one bundle. And more JavaScript problems to solve. More JavaScript conference to talk about these problems. And new monsters were born. Actually more JavaScript resulted in more, in bigger bundle sizes which resulted in worse performance. First rendering and everything else. And actually users became, started to suffer. And also business started to suffer. Because SEO was a problem. Crawlers can't read JavaScript. They need strings. So JavaScript heroes came back again and they decided to have SSR back. But this time was there the same JavaScript they wrote because it was so beautiful to throw it away. And they decided that the solution is to render this JavaScript they have to a string on server. And to have JavaScript function returning a string. So that was a good solution for SSR and it solved SEO problem. But it didn't solve bundle size problem, right? So they were using both the same JavaScript on client side and server side. So JavaScript heroes decided so that they need to come up with an idea of code splitting. And they did. They did this dynamic imports. Here you can see that there is one problem with this code. Not because it's not in React but because it's asynchronous. And it does solve the problem of a big JavaScript bundle. You can see that now the content not in one bundle but loads dynamically. But dynamic imports is for client side. And they can't be rendered on server side because server side needs to do it synchronously. So when the content, when your content depends on the route, meaning you need this content right away for client to see it, you can have code splitting both on server and client side. The only problem you need to solve is to decide on the environment you're in and to load it synchronously when you are not in client side environment and load it asynchronously when you are. So this is vanilla JS solution for this problem. And as much as I like vanilla JS, we all know it is, it doesn't scale. It solves the problem but it doesn't scale. But luckily we have React and library solution for it. And we have loadable components. And it is that easy with loadable components. As I wrote it in vanilla JS, all you need to do is have to feed this library information about all the chunks you have to ask it to render your content as a string on server side. And then loadable will decide as if by magic in what environment you are. And it will render your content server side and client side and with code splitting so you will not serve big bundles to your clients. So happily ever after, SSR codes was married to, SSR and code splitting were married to React and loadable components and our users are happy and our JS heroes ready for new monsters to conquer. Thank you. Thank you for coming.


Lena Zhukova

React Advanced Conference 2021

Gatsby v4's New Rendering Modes 

Sid Chatterjee

React Finland

React Finland 2021

SSR & SSG in NextJS

Nur Şah Ketene

React Summit Remote Edition

React Summit Remote Edition 2021

Next.js — The Hybrid Architecture (SSG/SSR) for Web Developer Modernization and Scaling React

Lee Robinson

#ssr