React Without JavaScript?

Rate this content

If React runs on a server and no one is around to see it, does it still make a sound? In this talk, Fred explores the world of server-side optimizations: what's possible today and what does the future hold? Featuring a sneak peek at an exciting new, never-before-seen project from the Snowpack team to help you build faster sites with React!

26 min
14 May, 2021

Video Summary and Transcription

This is a talk about the language of web development and how it influences what we can build. It introduces Astro, a method for building faster websites with less client-side JavaScript. Astro brings together the power of JavaScript and the speed of HTML. It explains how to mix scripting and markup using a frontmatter script. Astro allows you to use React components in an Astro application, generating server-side markup. It offers opt-in interactivity with JavaScript and an HTML-first output.

Available in Español

1. The Language of Web Development

Short description:

This is a talk about the language of web development and how it influences what we can build. It gives an example of a conference talk by Pete Hunt, one of the creators of React, where he introduces React and its concepts to an audience unfamiliar with them.

Hi. My name is Fred Schott, and this is my talk, Astro, React without JavaScript. This is a talk about language. And I don't mean JavaScript versus PHP versus C++ versus Fortran. What I mean is the language of the mind. And really, the language of how we talk about web development, and how we think about web development, and how that influences what we can build as web developers.

You know, what's seen as easy versus what's seen as hard. What's straightforward versus what's very difficult. What's possible and what's impossible. All comes from the language that we speak about web development.

And to give you an example, what I'm talking about, I want to show a conference talk that I really love. This is probably my favorite talk of the last 20 years. Besides, obviously the infamous what talk, if you haven't seen it, it's a delight. Definitely recommend you giving that a quick Google when the conference is over. But what I want to talk about is this talk. This is Pete Hunt, one of the creators of React, talking about React. And really launching React.

Now, what you need to know about this talk is that it's taking place in 2013. And this is essentially everyone's first time seeing React. And so, the ideas that are being pitched here, you know, in 2020, these are ideas of components and render cycles and how we think about Front End development. It all sounds like exactly what we have come to understand as good best practices. But, to this audience, these concepts are very foreign. This is not an audience that speaks in components and JSX. This is an audience that is traditionally only ever thought in terms of MVC. That's Model View Controller. If you were lucky enough to have missed this part of web development, I will spare you the details. You didn't miss much of anything. But MVC was this idea of separating your code, and separating your concerns in such a way as to bring some clarity and cleanliness to your code base. Separating your concerns was the goal here. And so, when Facebook launched Components, it was essentially this idea of, you know, MVC isn't the answer.

2. React's Challenging Introduction

Short description:

Facebook's introduction of React was met with skepticism as it challenged established best practices in web development, particularly the MVC architecture. Many questioned why Facebook thought they could challenge the status quo and deviate from the widely accepted approach. The general response was that React's approach to web development did not align with the industry's thinking at the time.

You're separating these things, but you've coupled yourselves in all these different ways. Components is a much better idea. That was the React pitch. And that was met with what I would generally call snark. Snark, I think, is the technical definition for what that reception was like. Because, you know, I think this tweet can probably say it better than I could. The general thinking was that Facebook was throwing away established best practices. And, you know, who were they to do that, right? MVC is the best it will ever be. Who does Facebook think they are challenging the status quo? And to be fair, I'm adding a lot of emphasis that isn't really there in this tweet. As far as Twitter feedback goes, this is pretty polite and straightforward. But the general response was, you know, this isn't how we think about web development. What are you talking about?

3. Challenging the Language of Websites

Short description:

This talk presents a new way of thinking about websites and challenges the language used to describe them. It introduces Astro, a method for building faster websites with less client-side JavaScript.

It starts to say, no, no, no. React is it's just like MVC, it's the view of MVC. Well, sometimes it's the controller, and sometimes it's the model, and it's really just the view. And I even remember myself thinking, like, oh, it's the view. It's the view. Okay. Cool. Even though to say it's all three is exactly what he's saying. The model makes no sense. Pete, even it works with your stack. It works with backbone, and the developers in the audience go, yeah! Backbone! A technology that we'll keep using forever!

So, this is very much a talk of its time. It is someone thinking about web development the way we think about it today. Almost traveling back in time to 2013 to try to explain this using a language and an architecture that we today see as outdated. And so, this talk today that I'm going to give, I want to do something similar. I want to, and, you know, I'll say we've seen some great talks from other web frameworks today. All amazing projects, Next.js, Gatsby, Remix, Blitz, Redwood, you know, this has been a conference full of different ways to build your site. All great projects. Fantastic stuff. But we're wrapping up the conference, we're kind of at the end, so I want to throw you all a curveball. I want to challenge everyone a bit. I want to present a way to build websites that actually challenges the way that we think about websites. I want to actually challenge the language that we use to describe what is a website today in 2020. And I'm no Pete Hunt. This is not React. I have a little bit more hubris or humility than to say that. But this is a new way of thinking about websites, and we're really excited about what it unlocks. I'm going to borrow a bit from Pete Hunt. Give it five minutes, and I think you're going to like what we've been working on. This talk is a presentation on Astro, which is a way to build faster websites with less client-side JavaScript. And everyone says they're fast.

4. Astro: Faster and Easier Web Development

Short description:

Astro is a server rendered React components that are faster and easier to use than traditional methods. It simplifies the process of building websites by using Astro files, which are a super set of HTML. With Astro, you can create fast-loading sites that outperform frameworks with perfect scores. The goal is to be so fast that you can't be measured. This talk highlights the importance of HTML in web development.

And everyone says they're fast. Everyone says they're performant. All buzzwords. If you're looking for something a bit more click-baby, Astro is server rendered React components, but better. Got your attention now.

And you might be saying, what are you talking about? The React team has been working on server rendered React components for years. It's incredibly difficult. Suspense, concurrent mode, all of these things are coming together, but it's a huge lift. What are you talking about that you've figured this out? And this is exactly what I'm getting out about language. In some ways of thinking, it's very difficult. With Astro, it's very easy.

So, before we get into the demo, I want to just throw a quick little snippet at you. Astro is all about building your site with Astro files. It's essentially a super set of HTML. This is valid Astro as well. A lot like how JSX is to JavaScript. Astro is to HTML. But this is the foundation of every site. So, you can see this kind of pages index.Astro, that's essentially your index home page of your website that you're building. It's basic HTML as its base. And if you know HTML or even if you know JSX, then you already know Astro. And to build Astro's home page,, I essentially threw together some static pages, HTML, threw an SVG on there, and measured it. And got a site so fast, so fast it was unmeasurable on Lighthouse. So, all these frameworks with their perfect score 100s and all green, that's not cool anymore. What I found that's really cool, zeros. Be so fast that you can't be measured. That's the new goal. Gauntlet thrown down. But that's what I want to get out here a bit. Is this idea of HTML.

5. Astro vs. JavaScript Applications

Short description:

Astro compares JavaScript applications with HTML websites. JavaScript applications, like Next.js, Gatsby, Blitz, and Redwood, offer power and control with data loading, fetching, and routing. However, they are complex and require optimization for performance. HTML websites, like Eleventy and Hugo, are traditionally lower powered and content-focused. Adding interactivity to HTML websites often requires setting up additional tools.

And really the idea of how Astro compares to other frameworks that exist today. And the way I would frame it is JavaScript applications vs. HTML websites. JavaScript applications are what you're building with most of the frameworks that exist today. That's Next.js, Gatsby, Blitz, Redwood. All of those. They're all about building your site as a JavaScript application. And there's a lot of good reasons to do this.

JavaScript applications are powerful. They're super expressive. You can do data loading, you can do data fetching. You can do routing. And all of these different ways to build a site in a really nice language for power and control. But they're complex. Next.js and all of these frameworks essentially exist to give you different hooks to make your site faster than the traditional here's an entire application to the user, which is the traditional SBA model. So, you can build a JavaScript application and send it to the user. You could use something like Next which will render it on a server. It's all about optimizing that story because performance can be such a challenge. When you built one big application and now you want to ship it to the user on maybe a lower-powered device or a shakier internet connection, that can be really challenging to get right, which is why SSR, SSG, all these different optimizations are really important in the world of JavaScript applications.

And you might say, you know, that's if you think the distinction doesn't really make sense, that's almost what I'm getting at here is that we are so synonymous today with JavaScript applications and websites being the same thing. And there's good reason for that. You know, if you think about what an HTML website is, it's probably something a lot more lower powered. An Eleventy or a Hugo, it's really content focused, markdown, static generation of HTML, is a pretty low powered idea or at least it traditionally has been. What they end up having to do is say, yeah, JavaScript is this kind of other thing that we don't touch. We're HTML. You want to add React, go do it yourself. So Snowpax website, one of the projects I work on, we built that with Eleventy. It's great. It's quick, but the second you need interactivity, you're off setting up your own thing, which we have a Snowpack plugin for. It's great.

6. Astro: Combining JavaScript Power and HTML Speed

Short description:

Astro brings together the power of JavaScript and the speed of HTML. It allows you to build fast websites with minimal JavaScript. Astro is a combination of the performance story of 11ty and the power of Next.js. It provides a seamless development environment and file-based routing system.

It brings a modern DevFlow to a static HTML site, but you definitely feel the sense that you've thrown two tools together. It's not the seamless dev environment that a Next.js would give you.

But that idea of making it difficult to add JavaScript is kind of the gift and the curse of something like Eleventy. When we launched the Snowpack doc site, the new rebuild back in December, I got something that made my whole month, a message from Alex Russell saying I did a good job with performance. Now, if you know Alex Russell on Twitter, this is unheard of. This is a shooting star on the 4th of May. I don't even know what that means. This was big and got me very happy.

As I'm putting this talk together, I see that, well, he didn't say it was that good. He said it pretty fast. For Alex, I'll take it. That's a pretty high praise. What was interesting is he went on to say how did you do this? Obviously, performance, it's so good to see people treating performance so seriously. We were kind of shocked because we hadn't really cared about performance. Not that we were being disrespectful to our users. We built a site and shipped it and it was fast. It was a really kind of cut and dry story. It was interesting because so much of my life has been spent being really careful performance. Here we were building a site that was fast by default. No JavaScript payload, HTML, CSS, and a few SVGs and images. That was it. And so this experience really shaped how we saw web development as a team and what Astro really is, is a chance to try to bring these two different ideas together.

The power of JavaScript, the expressiveness, and the kind of control that you have over what you build, but with the speed of something that's much more HTML first. No JavaScript sent to the client unless you explicitly want it to be. So the performance story of an 11d mixed with the power of a Next.js, that's what Astro is today. So what does that mean? Let's jump into a demo. What you have here is a pretty standard Astro site. You've got some static assets in a public directory and our main building blocks here in an Astro directory, components, layouts which we'll get to, but you'll spend the most time here in pages. These are the pages of your site, essentially a file-based routing system. And we said at the top any Astro file is a super set on top of HTML.

7. HTML as Foundation for Dynamic Pages

Short description:

This part introduces the concept of using HTML as the foundation for building dynamic web pages. It explains how to mix scripting and markup using a frontmatter script, similar to Svelte or Vue's single file components. The example demonstrates combining markup and JavaScript to create dynamic content. It also introduces the use of components, such as common head and a hero image, to enhance the HTML structure. The common head component is explained, including its ability to bundle common meta properties and the use of props to inject values into the component. TypeScript is also mentioned in passing.

So what we have here is essentially just HTML. Valid HTML, it's pretty static. Let's run this with npm start. That's going to spin up the Astro dev server and you can see this running here in the browser.

Now, we talked about wanting to make HTML more dynamic, kind of give it the power of JavaScript in terms of expressing yourself and what you can do, but keeping that HTML-first document structure in terms of what you're building, the language of what you create. So the way we do that is with something called a frontmatter script. This is really similar to Svelte or Vue if you've used their concept of a single file component. Here we're going to do something similar to start mixing the idea of scripting and markup.

So here we'll just define an idea of a title, and it'll be AstroDemo. We'll get a little exclamation mark for fun. And just like JSX you can combine markup and JavaScript. So here we can use title in the value here, we can use it as an attribute, or we can use it again here as a value of actual content on the page. If we refresh that you see it's updated with a new title exclamation mark and all.

But we want to go further, we want to keep bringing more kind of modern component concepts into how you render this page. So let's actually think in components, let's bring some components into this HTML. We'll bring in two to start. One is something we'll call common head. And I got to spell that right, components.commonhead.astronaut, commonhead.astronaut. And the other is a hero image. Let's get a nice kind of hero image on the page. We'll start with that, we'll just kind of add that here.

And common head is actually going to be a component that that takes care of all of these meta properties. So if you have many sites, many or sorry, many pages on your site, you don't want to keep repeating yourself over and over again, we can use a component like this to bundle up some common head items and tags for you to use across multiple pages. Now common head is interesting in that it actually takes props. So it's an astrofile, it's a snippet of HTML that we're going to inject into the site, but it's going to take the title prop as we'll see in a second. You can see it doing that using again, a Svelte concept of actually defining your props as exported values. So here we've exported title to show that it is a prop. And then we can use that in the snippet of HTML that we're going to inject into your site. So again, really similar concepts to the react and Svelte we're borrowing from a lot of different kind of really good ideas that we've seen in the community before us. Also you might note, if you have a good eye, there is TypeScript in here.

8. Astro: TypeScript, Reusability, and Data Fetching

Short description:

We support TypeScript in your front matter by default. Let's save and refresh the page to see the hero image. We have a reusable DOM component. The snippet includes a Pokedex example, demonstrating the JSX-like syntax and data fetching at build time. Astro allows you to use top level await for server rendering, resulting in fully static HTML.

We support TypeScript in your front matter by default. So feel free to mix and match there. Let's save this and refresh the page. And you'll see the hero image also showed up. So we have a actual DOM component that we've reused. Yeah, we could go out and have many, but let's keep it to one, that's respectable.

Now for the rest of this, I'll show a couple more kind of cool snippets. The first one is a Pokedex. What good tech demo doesn't include Pokemon? Now there's a cool, there's a couple of cool things I want to show off in the snippet. The first is that when we say we have this JSX-like syntax, we really mean it. You can see here a full JavaScript expression mixing astro syntax and JavaScript together. So just like the JSX we're used to in React, we are going to use this expression to actually render multiple components on the page. Here, we're going to actually show a Pokemon sprite for the first three Pokemon in the Pokédex. Oh, and we got to use it first. Pokemon lookup. And let's add a little bit of display flex just to get those all on the page. Look at that.

So if you don't know Pokemon, the whole idea of a Pokédex, none of that's important. We're just what we're doing here is having some fun with Pokemon and generating three little sprites here, three little images. What's cool about this component though, is that we're actually bringing in the idea of data fetching. So we don't ship with every Pokemon known to man. We actually have data fetching here, actually fetching at build time and making an API call. Not only do we have that support via fetch, but we also have top level await. So the idea of this ever affecting the user, it's fully build time. You get to use top level await as a part of your server rendering and the user never sees it. So there's not really a huge user performance concern here because this all gets rendered to static HTML at the end of the day. We can see that in the network panel here. I'll refresh and no JavaScript on the page, all static HTML. So that's a really cool idea of how you can express yourself with the server HTML based language called Astro in ways that are, you'd be much more limited to if you're using a front end framework like React or Svelte where you can't just throw a top level await in because a user would see it. In this world, we're fully server rendered.

9. Using React Components in Astro

Short description:

We can use React components in an Astro application, generating server-side markup. This allows us to mix Astro as an HTML language and React as a JavaScript framework. It's not limited to React; other frameworks like Preact are also supported.

So we don't actually have those concerns. We're a little more free to express ourselves in this way without the boilerplate.

I'll grab one more little demo snippet to show off here. And that is this idea of giving away the fun part, an emoji picker. This is not just any emoji picker. Let's add our import up here. You might have seen this in the components directory if you were looking for it. This is not an Astra file. This is a JSX file. This is a React component.

I said at the top in the talk, right, we have done server rendered components. What does that mean? That means we're letting you use React in your Astra application. We have here a React component. It's using another npm package. It's using some CSS. And this is all generating server side markup. We're going to render this component server side. Here we have three of them. Let's refresh the page. And look at that. We have just mixed. Actually, I'll do that. So, you can see yourself. We've just mixed Astro as an HTML language and React as a JavaScript framework. But we rendered them all server side. All generating HTML at the end of the day. So, you can do this with any framework. It's React Summit. We'll use React. But Preact is also supported.

10. Astro: Opt-in Interactivity with JavaScript

Short description:

Anything that renders to HTML can be used on the server this way. The user sees no JavaScript in their final payload. The idea is to make interactivity in JavaScript opt-in at a component level. By adding a modifier, like 'idle', to a component written in a framework like React or pre-actors, you can generate code to hydrate the component on the page, making it fully interactive on the client. Astro also offers the 'visible' modifier, which only hydrates components when they become visible on the screen. This approach helps reduce the amount of JavaScript sent to the user and allows for partial hydration, mixing static HTML and client-side JavaScript on a component-by-component basis.

Anything that renders to HTML can be used on the server this way. The user sees no JavaScript in their final payload.

Now, some things you actually might want to be dynamic. For example, these are meant to be clickable. And we have them generating random emoji, but nothing happens when I click. So, it's this idea of you actually want some functionality. We're not saying get rid of all JavaScript on the page. But the stance that we take is that interactivity in JavaScript should be opt in, not at a site level or a page level, but at a component by component level.

So, what we have here is the idea of taking a component written in a framework like React or pre-actors. And actually adding a modifier here to promote it to the client. Let's say we'll do idle here. What this does is actually generates not just the placeholder, but actual, you'll see here, code to hydrate this component on the page. So, now we actually have a fully interactive component. All working on the client. And you'll see here in the network panel, an actual networks trace, which shows like this actually loading. It's actually running on the browser. This is dev. So, we're being a little more aggressive in the Javascript we send in production. This would be bundled and minimized and tree shaken.

Another cool thing here is the idea of visible. If you spell it right, visible. And this actually, I'll do it here. As you scroll down, it'll only be when you get to the actual component that it takes that cost and actually hydrates those components. So, if something's below the fold, you would actually never even pay the price to load that until you actually interact with it and see it on your screen. There's a ton more cool stuff like this in Astro that I just don't have time to show you. We haven't even gotten to mark down how scope styling works by default. All of this stuff is about helping you build a site that is as little JavaScript and as little kind of weight that has to get sent to the user as possible. The superpower of Astro is something called partial hydration. This is that ability you saw to mix static HTML and client-side JavaScript on a component-by-component basis. So by default, everything you build with Astro is 100% HTML.

11. Astro: Opt-in Hydration and HTML-First Output

Short description:

Zero client-side JavaScript by default. Opt into individual components for hydration. Astro is a modern way to build faster websites with an HTML-first output. It allows you to use React on the server or the client, or both. Opting into individual components for hydration is the superpower of partial hydration and the backbone of Astro. Check out for an early preview.

Zero client-side JavaScript by default. But you then have the ability to optionally go in and hydrate individual components that need them. So some sort of image carousel or something with interactivity, maybe client-side data fetching. You can opt into that on a component-by-component level.

This is something that we get for free because we've actually changed the way we think about what you're building. It's not one big JavaScript application that you build with Astro, you're actually building a website, a website that follows something called islands architecture.

So this was a term coined by Jason Miller of Preact and Google fame. And it's all about thinking of your website not as one big application, but as a series of components on the page, some of them statically rendered zero client side weight, but others can then be hydrated individually almost as isolated islands from each other.

So instead of one big application, you have many small, almost mini applications, mini React components rendering individually and isolated from each other. So not blocking each other, smaller components kinda hydrate themselves much faster, while maybe a slower larger one takes a little bit. They're all isolated from each other and hydrate as progressively as they load.

This is something that we get for free by thinking in this way. This idea of islands and components and an actual HTML-first output. That's the superpower of Astro.

So to recap, Astro is a modern way to build faster websites. By default, everything you build with Astro serves zero client-side JavaScript by default. Everything is HTML-based and HTML-focused, but with the ability to opt-in to different components for client-side rendering. So you can use React on the server, you can use it on the client, you can do both. You can mix it into your markdown. You can do all these things on a component-by-component basis that are really difficult to do in other frameworks.

And that idea of opting into individual components for hydration instead of sending down an entire application, that is a superpower of partial hydration that is at the backbone of what Astro is all about.

So one of the downsides of recording this talk so much farther in advance is I actually don't know what the state of this project will be when you watch this video. I can't commit to anything right now but what I will say is check out for an early preview of what we're working on. We can't wait to get this out into your hands and to see what you build with this new way to build websites using partial hydration and react components on the server. Hope you've enjoyed this talk.

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

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.
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
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 Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
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. 
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.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
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 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
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 Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
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 Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
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.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
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.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
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