React via Rust and Rescript: Why and How?

So, hello! I'm here with probably the weirdest talk to talk about Rust and Rescript, a kind of camel-like language in the React community, but I have a very interesting topic, I hope, but do not feel like it will be something practical that we will do tomorrow. It's just out of curiosity what you can do. This is very interesting, though.

I do stuff, pretty much as I described. I do stuff in Rust. I'm a full-time Rust engineer right now, but as well, I've been doing a lot of React. This is one thing that I leveled down. Maybe you've seen my Twitter thread on how I made 200 lines of code assembly HTTP server on Twitter. If you like stuff like that, subscribe to me. I would like to do more of this stuff. I do a lot of React, and here is Material.UI, so I am still second one, top second person on Material.UI by amount of commits. I did a lot of React, and I still use React with TypeScript in a more general way, but besides that, I do work on Rust framework for three years already.

It's a Rust framework. Please don't run away. It's a Rust framework for video generation. If you heard about Remotion, it's basically the same thing but in a usable performance, but besides of Rust rendering on CPU and GPU stuff, it does have preview that works in React. So when you type something, it just works in almost a web page, and then you have hot reload. You type your code in Rust, and you have a video preview running smoothly in your web page. Also, it can run in WASM and render videos in browser, so we have even a real use case for it. So I built OneDayApp, which is really used, and it's a tool for running AI, like WhisperAI, in the browser locally. You just throw it a video. It transcribes the video, and then you can edit it, play subtitles to the phone, and then render the video right in the browser. It uses my framework. It uses Rust, React, and Rescript, and it's not something really nerdy. People are really using this app. It's open source. It's free. It's no sign-up, so people are really using it. It's analytics. So we render roughly 2,000 videos per month, and generally speaking, even more, because it's just analytics.

It could be blocked by the browser, so maybe more. So it's a real product, which is working, and it has 0.14% of codebase written in TypeScript and JavaScript. So everything else is in Rust and Rescript, even in React site.

Besides that, it's not something really nerdy. It has capability of running 120 FPS rendering, video real-time rendering. When you render video, it renders subtitles in 120 FPS, and it has a really usable performance. It works, and this performance is actually without any SSG, SSR, so it doesn't use Next. So it's just pure good old client-side React applications that works very greatly. It works in Google Indexing and so on and so forth. So basically, I feel like all of the stakes about React is being not performing enough. The unit disappearing compiler is more of a skill issue.

But what I really love about React is one single thing. I really love that React, despite of all of the other frameworks, it is just JavaScript. What do I mean? I mean that when you write React, you basically just write JavaScript. You don't have to write some weird specific syntax that will be compiled by some other framework. You don't write any kind of weird string templates. You just write JavaScript. You can even do it without JSX. As you probably know, JSX is compiling into some just function calls. Right now it's just Ash, but it used to be React Create Element.

And basically, it looks something like that. You don't need to read this code. But what it brings for me is that I can write something in a different language that will compile into the thing. And today, in modern languages, it's pretty easy to write things that look like JSX and then compile it into JavaScript and make it usable. And it has its own performance benefits and some code correctness benefits. And it's all about my talk. So I will try to prove you that writing JavaScript and React in different languages is not really that weird and marginal as you might think of. And it has its own real, real use case. So why am I not using TypeScript? I know that this is maybe I'm using take or bold take for JavaScript conference. I definitely think that TypeScript is not the best language in the world.

It is definitely the best way to type JavaScript that we have. And I appreciate strongly in style and type. Okay. It should say have. It might be an issue of my slides. Sorry.

Generally speaking, I really like TypeScript. So in Material.UI I actually brought TypeScript in Material.UI. I wrote the first component in TypeScript in Material.UI back in 2018. And I wrote pretty long generics. My generics are pretty long. But there is a problem with TypeScript. And there's a problem that it's still JavaScript. JavaScript itself is a pretty messy and pretty strange language which allows you to do a lot of weird stuff and a lot of things in a different ways.

So if let's take this quick example. So generally speaking, you just want to write this component that I described you, you add some kind of rendering state that you upload a file, then you have transcription state. Okay. Then in a few days you come back and you need now to add progress of transcription, progress of model loading for your AI application. Now you need to also render a state problem. And it looks like totally separate state. Okay. That's okay. Then you come back because sometimes you need to really rush and now you have specific state for subscription and progress because you have specific state for not edited subtitles and edited subtitles because if a feature of resizing them and you cannot resize them when user completely edited them because you lose the prescription type stamps per word. So now it looks weird. Then you just leave it and in a few days it becomes something like this with a thousand of new states which are terrible, which are weird. And you might say it's my skill issue. I would agree. So it's definitely skill issue. But the problem with the skill issue is that when I use TypeScript, when I use React, I get all of the type safety. Okay.

It's not really sound, but it has a type safety, but it doesn't lead me to the success, to the correct and working code. And this is the problem because with the modern pipelines, the way people write React code, it's very fast. They don't get back.

So in that case, I could get back, refactor it, bring some state management, bring some state machinic, state or something else to make it better. And it will be better, but it requires a real mental force to do that. And some, and very often, companies doesn't have money, doesn't have time to do this.

So here is why I really love Rescript. Please raise your hand if you have ever heard about something in Rescript, or tried it. Quite a few. Okay. Now raise your hand if you have never heard about it. Oh, shit. Okay. Okay.

So Rescript is an interesting language. It's a totally weird language. But you can see it's a Rescript component. So it's a functional language, which is based on OCaml. And I will return to it quickly. But basically you can see that it looks very much like React component. It says React component. It says some function. You use some states. You have some JSX. And it does look like a real React component. It has some types. And it compiles into a real working React component. Which is nice. So you can see one interesting thing here is a specific variant type, which is basically discriminated union in TypeScript. And it allows you to...

The first time, it's called algebraic data types in fancy functional languages. But it allows you to have this type represented in a few options. And then you have a... Like, you know, it's out of this world. It's super usable pattern matching, which allows you to match on the different status and get, like, load in percent and you write percent. And pretty much what do you do with ifs in discriminated union stuff. But it's very usable.

So let me get back to it. And I'll show you the state of that package. Like, it's a real state of that platform that I tried to replicate with useStateHell. So you can see that here my state manager is working based on only useReducer. So it's native reducer in React. Plus the action being a variant. And state being a variant. Because we just transfer it between different states. All of my code is very concise. And it's very correct. Because my pattern matching forces me to correctly handle all of the possible cases. I can add additional words. I will show you later. And it allows me to just have a very clean transition. And very correct one. Plus it keeps my code really readable.

So here is a reducer of my component. And I will stay a little bit later on this. For a bit longer. Because it's really beautiful. It's like 39 lines of code. But it holds the whole logic of this player. I'll show you.

So here is the player. Which does have the text. So it goes... It selects the new queue. It doesn't do lookup every time. So you can quickly move between it. You can change the volume. You can do everything you can do with real video. But it works. And all the state management is working natively in the language with one single reducer. Based on the pattern matching.

So a beautiful thing on the top that you can say something like... If the action is abort for render, we just stop any play in this thing. But then we say... With any action, if play state is not stopped for render... If stopped for render, we just don't do anything. This is giant logic. Which is very hard sometimes to represent if you just do imperative updates.

Then you have something like update... Specific update of new frame if your timestamp is out of the range of video. Then you have specific different handlers for sick and the new frame. Because when you do new frame, it's basically next frame by the time in. It can lookup the same... So it can just do the next cue from the list. Because they are always ordered.

And when you sick specifically, we need to always lookup it. So this is also handled. We have a play state, we have pause state, we have volume state. And basically, that's it. And this logic is clean like anything.

I can write it down. In TypeScript, it will be a giant function. Totally unreadable. And in order to bring something like that, I need to keep another dependency. And it will always be something that somebody needs to learn. Somebody needs to understand. So this is actually built into the language. And this is really nice. I will get back to this one.

And besides of that, it's really interesting that Rescript is basically React done right. It's not just something that somebody invented because they want to have a camel in front of it. No, it's actually not. It's historically the way React should look like. I will prove you that.

So if you know the story of React, it was created by Jordan Walk, which created the first version of React in the language called standard ML. It wasn't JavaScript. It wasn't JavaScript. In Facebook, they basically adopted and rewritten it from the standard ML stuff into JavaScript. They came out with the Flux architecture, which is basically based on actions and reducers everywhere. And now we use it as a type script. But at the same time, in Facebook, they've been working on a separate syntax for a camel and a separate compiler for a camel with support for JSX that will produce everything in a better place, right? And then the team that had been working on this in Facebook left and started working on Rescript and tried to make it usable by type script programmers.

And what's fun though, that a camel and standard ML is basically the same language family. So what does it mean? It means that the way Rescript looks, it's the way the original author of React designed to be using like. So one proof. So in OCaml and in Rescript, all of the variables are immutable by default. And they have a concept of references, which you can mutate, and they have specific syntax for that. Reminds you of something? It's React refs. It's basically the same concept that came up into React later on with our use refs. We just use it everywhere. But OCaml all of this time has a specific syntax for that because it's a limitation of OCaml to have the immutable variables everywhere.

And it's a limitation of React to all of the variables to be mutable. And this is really fun because it makes you think of React totally different. It makes you think more correctly of React. Even JSX. The JSX in this component is first, in this language, is first class supported. So you can perfectly fine write your React, your Tailwind, your fancy stuff. And you can see here that this is a props. And the props is basically just a labeled argument, like in all the other languages. Functions can have labeled arguments. But in JavaScript, we don't have them. That's why we use props with an object.

But in Rescript, you just use labeled arguments. And what's fun though, notice that I say that this is a strongly typed sound language, so you can't have a type error in runtime. You can't bypass this type checker. If you write all your types correctly, the types will be right. I mean, if you type something as any, which is now possible, it will have an issue. But if you type everything correctly, it will be sound. And you can see that there is no type annotations. And this is a very specific feature of ML language families, which allows you to infer the type of the label based on how you use it.

So notice that I use React string to render it inside the span. So it's basically text in span. But now the compiler knows the label is a string and you don't need to type it anyway. So you just write it down, and all the types are inferred automatically. And one more little detail. Like you can see a 71 line is highlighted. I'm not sure if you can see it. But the onclick here looks like a boolean, which doesn't look like a boolean. Which is interesting. Because in JavaScript and React, we use JSX to be shorthand for a boolean variable. So onclick true.

But in fact, just think about it. How often do you use boolean variables and how often do you spread variables down? Much more often you spread variables down. So in JavaScript they basically decided to swap this thing. And this is now spreading the onclick down to the button, inferring all the types. And you can do this for every spread variable. And you just need to write equals true for boolean variables. And it's so handy. I really use it now in a normal TypeScript React. This is really nice. I really love that it's really consistent.

So just take a look at this canvas work and stuff. So everything is pure. Everything looks literally the same. You have a cityX arrow everywhere. Which is really nice. Even setFieldStyle looks like a function. But in fact, in real JavaScript, it doesn't function. It's all different. And it happens to be with every JavaScript API. It's a total mess. It's totally different. There is a bazillion ways to do one single thing. But in fact, it could be all functions. Which looks much more concise.

And you can't like face a situation when another JavaScript... Like some Java developer came into your codebase and started doing these factories. Abstract factories everywhere. And you can't move it back. Which is really, really beautiful, I think. The question is, should we use it all? Why if it's so good? Why nobody is using it? Why nobody has heard about it? It's a valid question.

I agree. This makes sense. Because it's not a heaven. So it doesn't have type definitions for libraries. It has some issues even with native JavaScript bindings. So generally, you can use a lot of things in a script. But when you touch an other world, you need to write type definitions. Even though ChowGPT does it pretty well. It's pretty annoying.

The question... Should we use it? I will answer... Why I'm talking about it? I will answer in the very end of the presentation. But it is a very beautiful language if you want to understand the origins of React and write better React code. Okay. So if we can use RISC-Script, maybe we can use Rust. Because I'm a Rust engineer. It's a Rust and RISC-Script topic. So I say that I use Wasm. I use React. I use SVG. What? It's a total mess. I know I'm going very quickly, generally speaking. By the way, how many people have worked with Wasm before? Okay. Yeah. Not that many people.

So Wasm is a way to compile any language, like C or Rust, into WebAssembly and then execute it in the browser using specific runtime. Which is much more optimized than JavaScript for different algorithms. So with WebAssembly, I can do things like that. I can do realtime audio analyzation, render it in realtime. I can do more stuff.

Like notice this is SVG. And notice that there is a text wrap. If you have ever worked with SVG on a decent level, you know that SVGs doesn't support text wrapping. And because of Wasm, we can actually investigate the style of the font, get the exact width of every character, and build the text wrapping ourself. And do the audio analyzation in runtime in every render for every frame. Smooth it. And it works in 120 FPS in my machine. And it renders on React. Which is fun.

So here is an interesting thing. Why it renders on React? This is a frames API. It's in Rust. But I wouldn't spend a lot of your time here. You can just see... Does it remind you of something? Yeah, it's basically inspired of GS6 in JavaScript. And I really love the way React is declaratively defining the components. So in my framework, I try to do the same thing. But it's in Rust. And it's GSX in Rust. And now I want to draw this GSX into the React world. Which is really nice.

Why would I use React instead of writing it down in a GPU and have a separate environment? There are three reasons. First, this thing works in a browser. So I want to have a browser be able to render them. Second one. Browsers are crazy good at rendering SVGs. Third one. And the most important one. Is DevTools. So browsers have amazing DevTools.

It's a little bit worse for SVGs, but it's still pretty nice. You can inspect your elements, you can work with them. But yeah, I can do something else. I can avoid using React here and just... I have this SVG implementation in Rust. I can do this with Dangerously Sudden HTML or just render HTML. But the problem that I really don't like, I hate it, that if you update it with, like, string manipulation, just as out of HTML, it doesn't work, it doesn't update, it doesn't keep the structure of SVG. So you can't understand what is changing right now. And this is really annoying when you work on this specific thing. When you use this as DevTools, plus it's very slow. That's why React was invented for.

So I thought, if I can take my Rust code and generate somehow the React thing that I can And this was a really interesting experiment and I think it went pretty well. So in my Rust code, this thing that you've seen is macro, which generates basically a tree. The same thing at virtual DOM, but it generates this tree, which is an actual DOM. It doesn't have virtual DOM because I render this directly into the SVG, so I don't need to use a browser. So I write the native SVG renderer. So I have a DOM already, which is inlined in my Rust code like this after compilation. And now I want to give it to React preview application and render SVG in a fast React way and do it with SVG. And basically I came up with a very interesting thing, which is possible, and which is very interesting.

So basically what I'm doing, it's a Rust code, but there is nothing complicated. You can see that I have some structs, attributes, and element, which renders attribute id and value. So it's basically a React virtual DOM kind of like thing. Then I have the binding into createElement from this Rust application. And then whenever I want to render some element into the React world, I basically create with this binding to createElement. I create React element in Rust. So my player asks for my wasm.runtime for a new frame. My wasm.runtime knows, so it has some Rust logic, it knows which render tree it will be rendering. It converts them into React elements, gives it back to the preview application, and now we render the pure React elements. And this is crazy. So first of all, this solved this problem.

So right now, Rust renders React elements on this page runtime, and you can see that the DOM is updated accordingly, and it's really fast. It solves all the performance problems. So all the demos are running on my MacBook in 120 FPS with no problems. It works in React, so I can do crazy things. I can do really crazy things with it.

So besides realtime audio analyzation, I can do a very crazy thing. Like for instance, one of the demos have a real engine, physics engine, running inside Rust world, generating React elements for SVGs for every frame of this preview, and then rendering them through React in 120 FPS, which is really, really fun. It works, and it's super performant, and I really, really love it. So I can do this on Canvas, but I even cannot do this on Canvas, because the Canvas SVG render is very slow, and doing this through the DOM element runs in 60 FPS. So it's basically four time x performance by using React from Rust. And this is really nice. This is one of those performance optimizations that you can came up with if you learn new languages.

So basically, the point of my talk would be something like that. If you're trying to learn something new, if you're trying to get out of this little bubble of JavaScript world, and being fixed in JavaScript world, try to look in some functional programs, try to look in C, so you will be a better engineer. And if you are coming here, you probably want to be a better engineer. So it's just a fun way to try it out. If you want to be a better type script, a better correct engineer, you can try some which compiles to React, so you don't need to leave the React page to learn something new.

Thank you. And, yeah. For listening to me and watching my photographs. Thank you very much. And we don't actually know which some questions are about, so it's going to be a fun guessing game. For example, this first question, do you have source maps working? No. No. So the question, this is the problem, yes. Source maps are not even a standard, it's just a thing that Webpack invented. It's not a standard. What are you trying to get it? It's like, it doesn't work, and it's okay. It will work, likely, I think. I've been talking to one of the core contributors to your script, and they want to bring it in, but it's not yet. It is actually being standardized right now, source map. Yes, it is in progress of standardizing, yes. But it's not yet. It's in stage 3, I think.

Before we get into that standardization process, I'm going to summarize a whole bunch of questions. There was basically a series of questions that are to do with, well, it seems like a lot of the benefit of rescripts comes out of variant pattern matching. And so, let's say that TypeScript gets good variant pattern matching, does that basically solve the problem, or is there something else in rescript that you think is going to be key? So, I'm not, yeah, sorry for interrupting you. I'm not saying that pattern matching solved the problem. What makes TypeScript bad language? Well, it's the same thing. It tries to be on top of JavaScript. And JavaScript is a very broad language.

And JavaScript is a very broad language. You can write classes. You can write something else. And if there's a question, why don't you use reducer in this case? Because nobody is using use reducer. Everybody uses use state. Nobody leverages use reducer because they just get used to TypeScript being TypeScript, and they just do this, how is it called, imperative stuff, and it's how things are done. And when you have a built-in into language, very easy and very declarative way of handling your states, you will automatically try, you will automatically write code better. And if you just learn this, you will then use reducer initially, and then you'll just like, it solves the problem. But it's just a way of being like, you know, getting out of the bounds and learning something new basically.

Interesting. Your argument is basically that you could pretty much do a lot of this stuff in TypeScript, but people just don't because it doesn't guide you to the pit of success. Yes, exactly. Something like that. And generally speaking, it's just very fun and very fun to write code in a different language. And generally speaking, it's some language. So if you write a real application code in it, you will have much fewer bugs. Just because it has much more correctness and limits you in a specific order.

So yeah. All right, nice. I'm going to do a quick one because I think this was half answered already with the source maps question. But it's like, are you able to debug re-script directly in DevTools? Sure, yes. Yeah. So it outputs pretty readable code. So you don't really need source maps because it's not something like ABC or something like that. It's totally readable code. It's JavaScript and usually committed as a JavaScript way into the source control. So it's readable code. You can actually use it. So it can generate, by the way, TypeScript binding. So you can use from TypeScript your re-script component if you want to, because re-script can generate TypeScript definitions for its component because it's sound and TypeScript is not. Nice.

Okay, cool. Well, let's spend the remaining time talking about the Rust Wasm set of things. So the real-time rendering using Wasm, is it done with GLSL shaders or something? Or are you doing all of the actual DOM on the React side? Yeah. So I showed it maybe it was before the actual demo because I needed DevTools. So I needed to render in a DOM because it makes no sense to use browser to render it in a GLSL because I want to leverage the actual DevTools. It's more of the dev development time thing that renders it. So you leverage the actual browser DevTools to debug it. Nice.

And can you talk a bit more about the performance issues between SVG and Canvas and why you went for SVG over Canvas? So performance. So my original implementation uses SVG because it is. So this thing I've been talking about is kind of like DevTools for my framework. My framework uses SVG as a first-class instance because it works in SVG, it renders SVG in Rust, because I think SVG is a great format to define vector graphics and it's pretty readable. If you think SVG is just this path, it's not. It has text, it has primitive shapes, images, and all of this stuff, which is really nice to render videos. So I use SVGs and that's why my preview is also based on SVGs, can be based on a Canvas. Nice.

All right. So tying into one of the earlier talks on this track, we had basically a sort of demo of the React Server Components payload format, the so-called React flights format. I don't know if you're familiar with that, but somebody has a question here. Is that couldn't you use that payload format as the kind of interop you could stream changes from your sort of Rust WASM code into under the dump site? Yeah, probably yes. I didn't actually play around with it, but likely yes because you have a payload that you can stream. It's actually the same thing, but in this case, I manage all of the ticker and all of the actual player timings in the React world, but if you stream it, you will need to manage it from the Rust world, from the WASM world, and WASM is kind of limited in that. But it's probably possible. It's worse to play around with it. It would be nice. Nice.

Well, yeah, it's PR's welcome type of thing. Sure. Speaking of which, do you have an example beginner project if someone wants to give this a go? Do you have examples, demos, open source stuff? The thing that I showed, this open source tool, is open source for managing subtitles. So it is in Rescript and for frames also. It's using it for frames. It's on GitHub. It's open source. So it doesn't have much of a code base, but it's just an example. So you just play around with it if you want. Nice.

Okay, well, there were a few more questions, but I think what we can do is that we can leave those for the in-person room. But we do this thing here at this stage where we give one of these mugs to your favorite question. And out of the questions that I asked you, was one of them above the others? I mean, generally speaking, I feel like very, yeah. So probably rendering with VGSL and Canvas over SVGs, it's a pretty deep question. Nice. So whoever asked that question, feel free to come over here and grab a mug afterwards. And if you do have more questions, there's going to be the speaker Q&A booth in the main hall over there. you can also, I believe, zoom into those. Okay. So, yeah, let's give Dimitri one more round of applause. Thanks. Thanks.