The State of React Tooling

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Slides
Rate this content

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.

This talk has been presented at React Day Berlin 2022, check out the latest edition of this React Conference.

FAQ

ReMotion is a framework that enables developers to create videos programmatically using React. It allows users to write components, animate them, and generate real MP4 videos. This framework is designed for creating applications that leverage programmatic video creation.

The main categories of JavaScript tools mentioned include transpilers, bundlers, runtimes, linters, test runners, type checkers, formatters, and package managers.

A transpiler converts a single file written in a syntax that cannot be run on a runtime or in a browser into something executable, while a bundler takes multiple transpiled files and combines them into one file.

For new projects, SWC and ESBuild are recommended as they are much faster and more stable compared to older transpilers like Babel. SWC is especially recommended as it is the default in Next.js and has significant industry support.

Sucrase is noted for its speed but it is not fully spec compliant and is deemed experimental. It might produce invalid JavaScript files if given invalid code. Additionally, it lacks a logo, which can impact its adoption and recognition in the community.

TypeScript is essential for generating .d.ts TypeScript definition files, making it the only viable option for libraries or back-end applications that require these definitions. It is highly recommended for such use cases.

Bunn is a new runtime that aims to be faster than Node and compatible with existing code. It seeks to allow developers to run their existing code faster without modifications. There is significant excitement and backing for Bunn, indicating potential for substantial impact.

Package managers manage dependencies and ensure consistent, reproducible project environments. Using multiple package managers in the same project is discouraged to avoid conflicts and bugs. Core Pack can help manage different package managers within a single project.

Jonny Burger
Jonny Burger
29 min
02 Dec, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
The Talk discusses over 20 JavaScript tools commonly used by developers, including transpilers and bundlers. It highlights the pros and cons of various tools such as Sucrase, Babel, SWC, and ESBuild. The importance of TypeScript, linters like eslint, and the emergence of new tools like Rome are also mentioned. The Talk delves into the future of JavaScript, the challenges of bundling UI libraries, and the corporate era of JavaScript libraries with the backing of companies.

1. Introduction to JavaScript Tools

Short description:

Hey Berlin! My name is Jonny Burger. I'm the maintainer of ReMotion, a framework for making videos in React. I'll be talking about over 20 JavaScript tools commonly used by developers, organized into different categories. Let's go through them and I'll give you my unbiased opinion. Babel, the original transpiler, is still a staple for React Native. SWC is the new default in Next.js and has industry support. ESBuild, the default in Vite, is fast and robust with great industry support.

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.

2. Sucrase: A Fast and Experimental Transpiler

Short description:

Sucrase is a less known transpiler that is written in TypeScript and is the fastest. However, it has some practical problems and is not fully spec compliant. It describes itself as experimental and fun, but it may produce invalid JavaScript files.

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.

3. Transpilers and Bundlers

Short description:

TypeScript can be used as a transpiler for generating .d.ts definition files. Frameworks or bundlers often make the decision of which transpiler to use. Webpack is the most popular bundler, but Rollup is faster and puts ES modules first. However, it lacks hot module replacement. Vite is a popular bundler that serves JavaScript files directly to the browser without bundling. Parcel is a more conservative bundler that aims to reduce configuration and provides fast defaults like the SWC transpiler. Snowpack is up next.

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.

4. JavaScript Tools Continued

Short description:

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.

5. JavaScript Tools and Type Checkers

Short description:

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.

QnA

JavaScript Tools and AI Takeover

Short description:

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

Short description:

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.

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.

Bundling UI Libraries and the Future of JavaScript

Short description:

In the future, bundling UI libraries may not be necessary. TypeScript can be used to transpile and ship the library to NPM. The question of why Denno hasn't taken off as expected is raised, highlighting the challenges of getting everything working and the lack of significant benefits. The possibility of standardizing different flavors of JavaScript, aligning with browser standards, is discussed. The problem of JavaScript fatigue has shifted from the client and runtime to the tooling side. Clear winners in the tooling space are currently the mature and battle-tested options. The importance of corporate sponsorship in projects is debated, with the backing of a company seen as increasing the chances of success.

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.

The Corporate Era of JavaScript Libraries

Short description:

Either you loose if nobody is using it or you loose if everybody is using it and you just get flooded in issues. In the last couple of years, we've entered a corporate era of web host sponsored JavaScript libraries. Do you ever mourn for the days when the little guy could affect the future in a more impactful way? Yes, anybody can still plant a seed. If you have good ideas and you build it, then... VerCell will hire you and you can get paid to do it. That can really happen to any builder here.

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.

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

Vite: Rethinking Frontend Tooling
JSNation Live 2021JSNation Live 2021
31 min
Vite: Rethinking Frontend Tooling
Top Content
Vite is a next-generation build tool that leverages native ES modules for improved performance. It eliminates the need for bundling and improves hot module replacement. Vite provides an opinionated default configuration while still allowing advanced customization through plugins. It is framework agnostic and can be used for React and other applications. Vite is being adopted by Next.js and Create React App, and integration with Nuxt 3 offers significant speed improvements.
A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.