The State of React Tooling

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.

And for that framework, I have to use a lot of different tools. There's so many tools out there and I'm 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. 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.

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 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.

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. 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 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. 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 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.

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.

Yeah, and if 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, you know, assume that a lot of the node dependencies are shimmed. So, you know, 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 pnpm. So if it worked 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. 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.

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 Denno 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, you know? 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 BAN is much more promising. For sure, and I think maybe I'll add my own question to this because one thing that Denno is doing as a business of course is they are an edge platform, right? Like, you know, they run the edge runtime. And then you have you know Cloudflare for example or Vercel which uses Cloudflare's edge runtime and they are just committed to just pure plain JavaScript, right? Like using browser standard JavaScript. Do you think that you know, these sort of like different flavors of JavaScript will slowly go away in favor of like browser standards? Or do you think that there is going to be a future for sort of transpilation forever? I hope that everything will standardize and that's all. I mean we have the browser, we have different browsers, Node, Deno, One, they all have slight differences. I think there's a working group called Winter CG 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, you know, 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 like maybe in a few years time, we could be slimming down the thing and it would be more obvious for, for example, a 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 refusing because they are just very battle-tested. And if new entries are coming, if somebody else is winning over the ones that are like very mature at the moment, they just need to have like, 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 like personally as a developer, how much do you put sort of weight on the kind of corporate sponsorship of projects? So for example, there was 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? Like, 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. 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 loose if nobody is using it or you loose if everybody is using it and you just get flooded in issues. I kind of feel like in the last couple of years we've entered this sort of corporate era of web host sponsored JavaScript libraries. You have VerCell, you have Gatsby, Netlify, all these companies. Do you ever mourn for the days of when the little guy could affect the future in a lot more impactful way, or do you think we're still there? Yes, I think anybody can still plant a seed. If you have good ideas and you build it, then... VerCell will hire you and then you can get paid to do it. Absolutely! And that can really happen to any builder here.