The State of React Tooling

Rate this content
Bookmark
Slides

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.

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.

Available in Español

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 new build tool that intends to provide a leaner, faster, and more friction-less workflow for building modern web apps. This talk will dive into the project's background, rationale, technical details and design decisions: what problem does it solve, what makes it fast, and how does it fit into the JS tooling landscape.
A Guide to React Rendering Behavior
React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into 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 new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
Using useEffect Effectively
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
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 🤐)
Concurrent Rendering Adventures in React 18
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
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.
React, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
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.
Web3 Workshop - Building Your First Dapp
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
Nader Dabit
Nader Dabit
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
Designing Effective Tests With React Testing Library
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Top Content
Featured Workshop
Josh Justice
Josh Justice
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn