Emerging build tools such as Bun, ESBuild, SWC and Rome will transform how we work with React in the future. Let's take a look at their current state, look at what's needed to adopt them and predict how the landscape will evolve.
The State of React Tooling
AI Generated Video Summary
Hey Berlin! I hope you're all doing good. My name is Jonny Burger. I am from a place called Zurich, Switzerland, which means that I am able to understand the Germans, while the Germans are not able to understand me. So I'm very happy to have this superpower and be here in Berlin.
And my talk is going to be... wait, first let me tell you about the project that I'm doing. I'm the maintainer of ReMotion, which is a framework that allows you to make videos in React. So you can write the component, animate it, create real MP4 videos, and even create applications that leverage programmatic video.
I'm going to run through all the tools in 20 minutes to tell you a little bit about them and give you an unbiased opinion. It's going too fast. Okay, Babel, it is the original transpiler originally called 6to5. It has a good run for 10 years. It is the most flexible. It has the most transforms. But people have been complaining about its speed for some while. So new ones have come up in the meanwhile and I would not recommend that you use it for a new project except for React Native, where it is pretty much still a staple.
SWC is the Rust kid on the block, and it's the new default in Next.js. It has also big industry support behind it with Vercel that you have just heard about. So not much can go wrong if you use it. It is very stable and just much faster than Babel.
ESBuild is a transpiler that is written in Go and is the default in Vite. So if you use Vite, you are using ESBuild under the hood to bundle your production app. And Vite is also very fast and very robust. Has great industry support, especially because Vite uses it.
2. Sucrase: A Fast and Experimental Transpiler
3. Transpilers and Bundlers
TypeScript is also a transpiler, if you think about it, because it turns TS files into JS files. And I would not recommend it in a front-end stack to use it as a transpiler, for example, in webpack. But if you also need to generate .d.ts TypeScript definition files, you essentially need to use TypeScript because it is the only option.
So for libraries or back-end apps, I recommend you to use TypeScript as the transpiler. So, which one should you choose? It depends, but actually, oftentimes, you are not really able to choose. Your framework or your bundler is making that decision for you. So it's good to know what is out there. It's more like up to framework developers to decide which one is the right one.
Now, let's talk about the difference between a transpiler and a bundler. And while a transpiler converts a single file that in a syntax that cannot be run on a runtime or in a browser into something that can be run, the bundler takes a lot of the transpiled files and puts them into one. And the most popular one, let me again, I was a bit too fast. I'm trying to go fast. Webpack, of course, is the golden standard and is used in all major frameworks until Vite came up and now NexGIS is replacing it as well. But because of this and the vast amount of options that it has, it is, of course, much recommended.
Let's skip this one. TurboPack, the successor to Webpack, has massive backing from Vercel, but lacks installation instructions and comprehensive documentation. Dano, a faster and more secure runtime that supports TypeScript, has not gained significant adoption due to compatibility issues. However, Bunn, a new runtime, aims to be faster than Node and compatible, offering the potential to run existing code faster. In the realm of linters, eslint stands out with its extensive ruleset, including framework-specific presets. Notably, eslint will undergo a complete rewrite without TypeScript.
Let's skip this one. You might have heard about it but they deprecated it already and now they recommend Wheat.
Okay. TurboPack, there will be a talk at 2 p.m. that I recommend you to listen and check out. It will be the successor to Webpack created by the creator of Webpack and will have massive backing by Vercel on it. But there's no installation instructions and only 10 pages of documentation so let's call it a bunch of hype for now. But let's see what Tobias will have to say about it.
Okay. Let's move on to runtime. And there of course everybody is using Node.js. I think 99% of you are using Node.js. I would be very surprised. Millions of MPM modules is what allows us to build powerful things, billion dollar businesses because the ecosystem is so good. Now there's the new thing out, Dano, which I guess technically it is better, right? It's a bit faster, a bit more sane, a bit more secure and even supports TypeScript natively. But it's been a while since it came out, and I feel like the adoption has not really been so huge. And I think the reason for that is that the compatibility story is not very compelling. You do have to essentially rewrite or build up a new ecosystem from scratch. And even with the new NPM compatibility, I cannot just drop Node and all my 1,000 Node modules because there are some incompatibilities. What I am excited about instead is Bunn. Bunn is a new runtime, and the creator of Bunn will also give a talk on Monday, that is supposed to be faster than Node and compatible. So, essentially, they are trying to build a golden goose. We can run the codes that we have already written, but just faster. If they succeed with that mission, it will be massive and now there's some serious backing behind it and I really want Bunn to happen.
Moving on to linters, eslint, of course, is the most famous one because it has thousands of rules. We can check everything, check for many errors. I think I have like 300 lint rules in my project. And we can even create framework specific lint rules. So there's a next preset and I made a remotion preset to catch some common errors that the framework users make. What is interesting about eslint is that they have announced that they will completely rewrite it from scratch and they will not use TypeScript.
Very mad choice if you ask me and I'm scratching my head about that. But nonetheless of course eslint, it's a must use. Rome, a competitor written in Rust, is faster but has fewer rules. Multiple package managers can introduce bugs, so use core pack to specify the package manager for each project. TypeScript is highly recommended, and there's a new Rust-based type checker called STC. It's still in progress and lacks a logo. Prettier is a opinionated formatter for code, JSON, and markdown.
Very mad choice if you ask me and I'm scratching my head about that. But nonetheless of course eslint, it's a must use. And like each category, there is a competitor coming up that is written in Rust. It is called the Rome. Of course, it is much faster than eslint, but at the moment only has 80 rules. In the future, you will probably be able to alter rules, but they will all have to be written in Rust. And because it right now catches much less errors, I will only recommend it to you if you want less errors in your project.
All right, package managers, and here I don't have the time to argue about good and bad. Unfortunately, all package managers are very good, and I don't really care which one that you use. But what you should not do is use multiple package managers, because, in the same project, because then you will end up with multiple log files, and you might introduce subtle bugs. So of course, they made a manager for package managers called core pack, and it's now shipped alongside Node.js. You can run core pack enable in your project, and what it will allow you to do is to specify which package manager that project should use, and then it will hijack the commands and ensure that, for each project, the right package manager and the right version will be downloaded, and if you try to use a different package manager, then it will fail. So this is how we can prevent from multiple package managers interfering each others.
Type checkers have been a huge help for me, and, of course, TypeScript, the holy grail of our tools, has made us all so much more productive and really I feel spiritual when using TypeScript. It is so good. The only prayer that I have is that it could be a little bit faster. Of course, TypeScript is much recommended. And starting this thing called STC, it's like TSC, but Speedy Type Checker instead, very cheeky, written in Rust. One man, the author of SWC, has made it his mission to help our humanity by writing a faster TypeScript checker in Rust. I don't know if he will succeed. Currently, he is posting weekly progress updates on his blog. Right now, about half of the errors that should appear are actually appearing. And I guess to do the rest, that is the hardest part. So I cannot recommend it at the moment because it has no logo. How will a tool ever take off if it does not have a cool logo? So please someone make a logo for STC. Five second break. I needed four matters. Prettier. It has few options and is there for opinionated so that developers don't argue about semicolons or no semicolons. And I also use it to format my JSON and markdown.
So Rome comes in with the same philosophy but tries to be faster and offers error recovery. New tools need to be significantly better or faster to replace existing ones. Compatibility is important to leverage existing work. A new tool, ChatGPT from OpenAI, writes perfect code and makes other tools obsolete. Follow me on Twitter and check out ReMotion. Let's start the Q&A.
So it has a lot of language support but it's not so fast. So Rome comes in, again, with the same philosophy but it just tries to be faster which is, I guess, a good idea. And it also offers error recovery which means that if you try to format an invalid syntax, it might still work. So this is a feature that Prettier doesn't have and is pretty interesting.
So, what do all of these categories have in common? I think that if new tools want to come in and replace the ones that we are using so far, they need to be either significantly better or significantly faster. If you just make a incremental improvement, make it a little bit better but it's not a game changer, then we see that people are not willing to do migration work to get these little benefits. So it really has to be a game changer and compatibility is also very important. We see it in Deno, for example, or in the new lint which is fast but does have way fewer rules, we need to be able to leverage all the work that we have done so far in our ecosystem also in the new tool and not start from scratch.
All right. I had to speak faster because a late newcomer came in. Have you seen this? It's so good. It came out two days ago and I would almost consider it a new type of tool. I have asked ChatGPT from OpenAI to write a React component that promotes React Day Berlin. And you see it on Twitter all the time. It really is so good. It writes perfect code, perfectly formatted, no errors. Completely correct and therefore kind of makes all the tools I have mentioned so far completely obsolete. And even as developers, we will all have no job in no time. And, yeah, it feels bad that I've spent all this work and now this AI thing is taking over. So I should better leave the stage now. You can follow me here on Twitter and check out ReMotion as well, with which you can create videos programmatically. Thank you very much. Thank you very much, Johnny. Why don't you take a seat here at the Q&A booth and we'll get going with the questions. First of all, I have a personal question. What is your cardio training regime to be able to speak that fast for that long? I don't think I could do that. That was intense. I'm exhausted. I need an easier question. Alright, let's get going.
Cheese, Vite, Yarn, Flow, and jQuery
Let's go with a very easy one first. What's the best Swiss cheese and why is it raclette? Oh, raclette is very social. How ready is Vite for production? Is that something that you would use, for example, at Remotion? Is it time to abandon yarn? We have a time traveler from 2018 asking, what do you think of flow? Yeah, it did not even deserve a spot on the presentation, unfortunately. Oh, we have a time traveler from year 2008 asking, why didn't you mention jQuery? So, I could expand this into a two hour talk, so it was just about tools that you would use for React.
Let's go with a very easy one first. What's the best Swiss cheese and why is it raclette? Oh, raclette is very social. You can sit around the table and have melting cheese in the middle and just everybody has automatically a good time. I wish we had some here right now.
Alright, well, let's get into the serious questions. Let me see. How ready is Vite for production? Is that something that you would use, for example, at Remotion? Yeah, definitely. I think Vite also has some integration, some middleware that we could use to integrate it into our framework and I would say we are considering it. The ES module story makes it a bit more difficult for users and also, as I mentioned, it's just a front-end framework, so it's more like a replacement for Create React app, but less so for, for example, Next.js.
Nice. We have a time traveler from 2018 asking, what do you think of flow? Well, it's probably going to be the future. Yeah. We wouldn't recommend using flow today. Yeah, it did not even deserve a spot on the presentation, unfortunately. Yeah, I think it's one of those sad stories where I think I like for a conceptual level, they were more correct than TypeScript, but the developer experience isn't there. And developers care more about the experience than they do about correctness, I think. All right. Let me see. What else do we get here? Oh, we have a time traveler from year 2008 asking, why didn't you mention jQuery? So, I could expand this into a two hour talk, so it was just about tools that you would use for React. We are at React Day Berlin, and yeah, actually Astro is the new thing, but since it was React Day I was not mentioning that. Cool.
Let's see, best bundler and tools for UI kit libraries in 2023. So this is a time traveler from the future now. I would say TypeScript. I mean, if you are shipping a UI library, you don't necessarily have to bundle it, it just makes it harder to then change the sources, patch the node modules. So I would just transpile it with TypeScript and then ship that to NPM. Yeah.