The State of React Tooling


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.



Hey Berlin, I hope you are 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. And for that framework, I have to use a lot of different tools. There are so many tools out there and I am so confused. And if just somebody could help me navigate, somebody unbiased, tell me what all these tools are for, because a new one is coming out every week, well, I got you. And these are over 20 javascript tools that developers use commonly and I have organized them into transpilers, bundlers, runtimes, linters, test runners, type checkers, formatters, and package managers. I know that's a lot and we need to acknowledge that it does not make sense that one knows all the tools at once. But I think in general, you should use one tool from each category. 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, 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, so 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're 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 and I can also recommend you to use it. Now let's go into one that is a bit less known. It's called Sucrase which is actually the fastest transpiler. And it is written in typescript, so you'd think it is slower than the compilers that are written in Go or in rust. But no, actually it does not matter and it compiles very fast. But it also has some problems that prohibit me from recommending it to you. It does not have as its goal to be fully spec compliant, rather practical. It describes itself as experimental and fun which does really sound fun. And one interesting thing about it is that if you throw invalid code at it, it might just spit out an invalid javascript file which is not what you might want. And also it has no logo really as a javascript tool, so I cannot recommend it unfortunately. 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 while 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 next.js is replacing it as well. But because of this and the vast amount of options that it has, it is, of course, much recommended. Okay. I landed on the right slide on Rollup, which puts ES modules first, so very modern and also much faster. But the thing is it does not support hot module replacement. So in development, you could not just save it and have your react component update. And therefore, I would not recommend you to use it standalone. However, it is a very essential part of vite. vite is a very popular bundler nowadays, which during development does not do any bundling but rather does something called unbundling. It just serves all the javascript files straight into the browser without doing anything and that only works because it embraces ES modules. As you know, we are not yet ready completely as a javascript ecosystem to use ES modules only. So there is some friction to be expected when you are using vite or Rollup. There's also Parcel, which is a bit more conservative, stays close to the ideas of webpack, those that work, but embraces or, like, wants you to use less configuration, wants you to make it easier to use a bundler. And it has some very good fast defaults like the SWC transpiler, which out of the box, haha, makes it faster than webpack. It is not very popular, I guess, because it's not, like, leap miles ahead of webpack and people are afraid to migrate, but I'm definitely recommended. Next up is Snowpack. Let's skip this one. You might have heard about it, but they deprecated it already and now they recommend vite. 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 ten 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, otherwise 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, deno, which I guess technically it is better, right? It is 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 MPM 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. And like each category, there is a competitor coming up that is written in rust. It is called the Rome. And 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 auto-rule, but they will also have to be written in rust. And because it's 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. Obviously, 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. It's called Corepack, and it's now shipped alongside node.js. You can run Corepack 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 high check 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 other's. 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 there's this thing called STC. It's like TSC, but speedy type checker instead. Very cheeky, written in rust. John Mann, the author of the SWC, has made it its 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 need it. Formatter is prettier. It has few options, and is there for opinionated so that developers don't argue about semicolons or no semicolons. I also use it to format my JSON and markdown. 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. 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 Linter, which is fast but does have very few 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 chat GPT 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 that I've 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, Jonny. Why don't you take a seat here in 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. All right. Let's get going. Let's start 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. All right. 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. I would say we are considering it. The ES module story makes it a bit more difficult for users. And also, I should mention, 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. Yeah. So I may inject there, I'm using vite currently, actively. And the only problem really is library authors who aren't supporting standard javascript. So for example, if you use aws, a lot of the aws Amplify client libraries are basically just webpack script. They assumed a lot of the node dependencies are shimmed. So if we use vite and we complain to library authors, I think we can all be in a better place soon. All right. Is it time to abandon yarn? So this V2 thing, I must admit, is a bit, was a bit funky, but, you know, I think if it does not work out for you, it is relatively easy to just switch to PMPM. So if it works for you, keep it. And if not, there are other tools that you can relatively easily adapt. So I don't see it as like too big of a problem. Nice. Time Traveler from 2018 asking, what do you think of Flow? Well, it's probably going to be the future. Yeah. 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, you know, 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 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. Okay, here's a little bit of a... Wait, did I... I lost the question. There was a really saucy question about why do you think deno hasn't taken off as much as maybe some people would have hoped? I've tried it and it's just hard to get everything working. Even if a slim project, you at least have hundreds of npm modules and something always does not work. Everything has to work, has to be 100% ideal for us to adopt deno, but it's just not the reality. And I also think that it is not enough of a game changer to warrant us to invest all the time into migrating it. And I think BUN is much more promising. For sure. And I think maybe I'll add my own question to this, because one thing that deno is doing as a business, of course, is they are a edge platform. They run the edge runtime. And then you have cloudflare, for example, or Vercel, which uses cloudflare's edge runtime, and they are just committed to just pure, plain javascript, like using browser standard javascript. Do you think that the sort of different flavors of javascript will slowly go away in favor of browser standards? Or do you think that there is going to be a future for transpilation forever? I hope that everything will standardize and that all... I mean, we have the browser, we have different browsers, Node, deno, BUN. They all have slight differences. I think there's a working group called WinterCG, which is trying to align that so that hopefully there will be more and more standardization in the future and we will not have such big interoperability problems. Yeah. I think with all these tools... I'm just asking my own questions now. I'm sorry. I don't care about what you want. One of the things that we used to talk a lot about in the past was this idea of javascript fatigue, right? And we've kind of moved... It used to be on the client. It used to be on the runtime. It used to be which framework you use. But now it seems like that problem has moved to the tooling side. Do you see any clear winners emerging where maybe in a few years' time we could be slimming down the thing and it would be more obvious for a, for example, web developer to choose just the one standard and not think about it? I think for now just the boring ones, even if they are slow, are winning and are worth using because they are just very battle-tested. And if new entries are coming, if somebody else is winning over the ones that are very mature at the moment, they just need to have clear compatibility and have tangible benefits over what we are using right now. So I don't see it changing too much. And how much would you personally, as a developer, how much do you put weight on the corporate sponsorship of projects? So for example, there were multiple Vercel projects, but STC, for example, is not an official Vercel project. It's just the guy from Vercel writing it, right? Like does it matter to you where do these projects come from or do you just go in the merits of the project itself? I think this is a very important point. How much backing is there behind it? And yeah, if just a single guy is trying to reimplement typescript, I see less of a chance of it being successful than if a company pays engineers to do something big. Yeah, that's true. It's an interesting one because in open source we've always had this credo of like everybody starts from the same level. Anybody can create the best tool for the future, but it is harder to maintain something if you don't have millions of dollars of investment behind it. But I think the reality now is that just having an open source project and building does not scale. Either you lose by if nobody is using it or you lose by everybody is using it and you just get flooded in issues. But do you ever feel like, you know, I kind of feel like we've in the last couple of years, we've entered this sort of corporate era of sort of like web host sponsored javascript libraries. You have gatsby, Netlify, all of these companies. Do you ever mourn for the days of like when the little guy could affect the future in a lot more impactful way? Or do you think we're still there? Yeah, I think anybody can still plant a seed. If you have good ideas and you build it, then... Veracell will hire you and then you can get paid to do it. Absolutely. And that can really happen to any builder here. Nice. Okay, let's do a couple more questions from the audience. So monorepo workflows like NX or Lerna, any recommendations when in that environment regarding build tools? Yeah, there are also multiple options out there. NX, Lerna and Turbo repo. Personally, I use the Turbo repo. Greatest marketing, you know, I'm just a sucker for that. And previously I used Lerna, but it did not have like this caching that Turbo repo does. And now I use Turbo repo. Don't know much about NX, unfortunately. Cool. And then last question, we have about 20 seconds left on the clock. What about the future of Remotion? You haven't taken a lot of time to pitch your ware, so why don't you tell us what you're building and... Yeah, so with Remotion, we so far have mostly focused on allowing it for react developers to create videos programmatically. The thing that was not so good so far is that it was very hard. You really had to be an expert react engineers, expert react engineer to make something compelling. But now we just want to create more templates, presets, higher level abstractions. You can imagine it's like transitions, special effects, higher order components that you can put into Remotion to make it easier to create these videos programmatically now that the viability has been shown. And we also want to give you tools to build apps that can create videos. So like a web app, and then a user can drag in a video, and you will have a timeline, and they can edit a video in your web app. And MP4 is being rendered out very hard, and we want to make that more easy. Wonderful. I love the project. Thank you so much for being here. Thanks for... This was your first conference talk, I hear. It was, yeah. Can we have a big hand for Johnny? Thanks. Thank you.
29 min
02 Dec, 2022

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

Workshops on related topic