The Dawning of a New Age for Fullstack React

Rate this content

New fullstack frameworks like Blitz.js and RedwoodJS are ushering us into a new era for fullstack development. They are mixing old concepts and ideas with cutting edge technologies to make fullstack developers more productive than ever. Watch this talk to go on a journey through time and get excited about what lies ahead.

34 min
14 May, 2021

Video Summary and Transcription

React has evolved over the years, introducing breakthroughs like the declarative component model and React hooks. Create React App and Next.js abstracted away webpack config and routing, improving developer productivity. GraphQL backend as a service platforms made it easy to set up a backend without extensive knowledge. Blitz.js and Redwood.js are game-changing batteries included frameworks for full stack React development. They aim to make backend development easier for front end developers and optimize full stack productivity.

Available in Español

1. The Evolution of React

Short description:

Let's go back to the beginning of React in 2013, when it was first announced. Despite initial skepticism, React brought breakthroughs in building and maintaining complex user interfaces, as well as introducing the declarative component model. In 2015, React released ESX class support and GraphQL was introduced as an answer to limitations with REST APIs.

Hello, everyone. Let's begin by going back in time and taking a look at the first stage of full-stack React. The journey begins in 2013, the year in which React did not even exist, that is, until May 29, 2013 when React was first announced at JSConf US. This means that next month React will be turning 8 years old. Doesn't that sound crazy? To me, React seems so much older than 8 years old, but it's only 8 years ago. We look back on this as a very significant event. Our careers are built around React. But at the time, React was not so well-received. It had a lot of haters and skeptics, and people were especially upset at JSX. In fact, there were entire codebases, like the Mozilla DevTools, Firefox DevTools, that were written, it was an entire React app written without JSX. So it was using, like, create element, and so forth. So we've come a long ways, to say the least.

Now, there are two sort of breakthroughs, I'll call them that, in my mind, that React brought. One is that it made it easier to build and maintain complex user interfaces. And it provided a new way to think about and build UIs that was totally new to anything that had come before. And another really a nice invention here was the declarative component model. And so this, you know, no longer had to use jQuery to surgically update the DOM and all the places that it needed to change. So let's jump forward a couple of years to 2015. Now one significant event in this year was that React released ESX class support. So prior to this time, you were using React.createClass to create all your components. If you don't know what I'm talking about, go Google React.createClass and check out some code snippets and it looks pretty funny. Totally different than what we're used to today. And there's these things called mixins and all kinds of wild stuff that, yeah. So this was a big deal. And of course we've kind of moved beyond that by now, but this was a big deal in 2015. Now there's one other thing that was very significant in 2015. That was the introduction of GraphQL by Facebook. Now this is at a time where the single page application is just really getting going. And so now you have separate backends and separate frontends, and teams are getting And this API layer is becoming a very crucial piece of the infrastructure of your application. And of course people are running into limitations with REST APIs, and so GraphQL was an answer to that.

2. React App and Next.js

Short description:

In 2016, two important releases happened: Create React App and Next.js. Create React App focused on static single page applications, while Next.js was optimized for server-side rendering. Both frameworks abstracted away the webpack config and routing, improving developer productivity.

It was bringing focus to this, this important piece, and seeking to optimize it and making better and make developers more productive. So, very nice. Let's go on to the next year, 2016. This was a big year. Because two very important things were released this year, Create React App and Next.js, within mere months of each other. Isn't that crazy? Looking back it seems like one came before the other, but they were both released around the same time. But they were focused on two different things, right? So, Create React App was really focused on the static single page application. And, but Next.js was optimized for server side rendering. And it didn't have any static optimization or any static pages. As long as my memory is correct. But this was very important because it brought a couple of breakthroughs. Number one, is it abstracted away the webpack config for you. No longer did you have to create your own webpack config from scratch. Or use a boilerplate where you had this massive webpack config inside your project that was scary to look at. And additionally, Next.js abstracted away the routing and the per page bundling. So this was a big deal for developer productivity. No longer did you have to set up the router and figure out which router to use and things like that.

3. GraphQL Backend as a Service

Short description:

In 2016, GraphQL backend as a service platforms like Graphcool and Hasura were introduced, making it easy to spin up a backend database and a GraphQL API. While they provided a boost to initial productivity, the downside was being tied to a third-party service and limited customization options. However, the idea of quickly setting up a backend without extensive knowledge was powerful.

Now, there was one more thing that happened in 2016 that I think is very worth mentioning in this context of building full stack applications. And that is the introduction of GraphQL backend as a service platforms. Graphcool being one of the prominent ones that was created by the company that is now Prisma. And then also in 2018, it's jumping forward a couple of years, but in the same category is Hasura. And this was around the same time that Graphcool was being shut down. Hasura started up. And so both of these are GraphQL backend as a service providers. And the breakthrough that they brought is it made it really easy to spin up a backend database and a GraphQL API. Now remember, this is, especially from when Graphcool was released in 2016, GraphQL was only a year old. And so it's still early and still figuring out how to do all these sort of things. But they gave a real boost to initial productivity. But the downside is that you're tied to a third party service. Even if you self-hosted, you're kind of handcuffed to that implementation. And it's very hard to customize or change the resolvers and implementation. But there's an idea here that is really powerful. And that is the ability to get your backend up quickly, without having to know a lot about how to do that.

4. React Hooks, Next.js API Routes, and Blitz.js

Short description:

In 2019, React hooks were officially released, changing the way we write React apps. The introduction of API routes to Next.js allowed for building full stack React apps with a single server. In 2020, the outlook for full-stack React developers was bleak until the revolutionary framework Blitz.js was announced. Blitz.js provided a batteries included framework for React and a zero API data layer.

All right, let's move on to 2019. At the beginning of 2019, React hooks were officially released in a React stable version. So this was a big year. This was when, well, many people had already been rushing into hooks in the alpha versions, but this is when the safe folks could say like, yes, now it's production ready, let's start using hooks. And this really changed the way we write React apps.

So today, two years later, hooks are very much a key part of almost all of our daily workflows. The second thing in 2019 that was very significant was the introduction of API routes to Next.js. Before this, Next.js only did pages. But in 2019, around June, they added API routes. This is very significant in the context of building full stack React apps. Because now, for the first time ever, you could have one single server that would serve your React components and your API routes in a really nice integrated package.

And it was in this fall at React Rally Conference that I remember hearing about someone who was... They were now using Next.js for all of their applications. And it was sort of like a progressive idea. But I was like, wow. Like, there's something to this. And there were people who saw that early on, that Next.js was gonna be kind of key to building full-stack apps.

So now we come to 2020. And at the beginning of 2020, the outlook for full-stack React developers was very bleak. It's seven years after React was released and we still don't have anything remotely comparable to Rails or Laravel. When starting a new project, you have a million decisions to make. But even with all the choices, there's none that seem truly great and partly because they're hard to make all work together and there's a portion of React developers that are abandoning React altogether and going back to traditional Ruby on Rails apps with server side rendering because they're faster at that because of the complexity of React apps and the API layer and getting everything to work right.

But then comes February 17th, 2020. And an unknown fella by the name of Brandon Bear announces a revolutionary new full-stack framework for React called Blitz.js. React developers all around the world got super excited because finally there would be a solution to their full stack blues. And Blitz brought a number of breakthroughs. Number one, just the fact that there was now a batteries included framework, like Rails or Laravel for React. This was awesome. It was super exciting. And secondly, Blitz brought a zero API data layer that abstracts away the API into a compile step.

5. Blitz, Redwood, and the Future of Full Stack React

Short description:

Blitz brings a super-fast developer experience to React apps by abstracting away REST and GraphQL. Redwood offers a refined version of GraphQL and Hasura, with customizable code and no third-party dependency. Both frameworks provide a monolithic developer experience, with optional deployment flexibility. Full stack JavaScript and TypeScript eliminate language barriers and enable end-to-end type safety. These batteries included frameworks for React are a game-changer.

This returned us to a developer experience similar to that of the traditional server-side rendered Rails approach. Because, with the traditional Rails workflow, there's no API, and so it's very simple and fast to develop, because you don't have that extra piece of architecture in your app.

And so that's what Blitz brings to React. It brings that same super-fast developer experience to React apps because you don't have to mess or think about REST or GraphQL. It just abstracts the whole thing away. And so this is a massive boost to productivity.

Also, Blitz is built on top of Next.js, the very well-loved framework at this point that is a hybrid framework and you can do so many things with it, but it's still pretty minimal and what it gives you out of the box. And so by doing this, Blitz effectively creates a custom distribution of Next.js, similar to a Linux distribution.

But surprise, just one month later on March 20th, there's another huge announcement about Redwood.js, yet another full-stack framework for React. And so Redwood is seeking to solve the same problems as Blitz, but it takes a totally different approach. Instead of abstracting the API away like Blitz does, Redwood keeps it and seeks to optimize it with a GraphQL layer and really nice integration between the front and the back end.

And the breakthroughs, in my mind, for Redwood, is that it gives you a developer experience similar to that of GraphQL or Hasura, but where you have the ability to customize the code because you have ownership over the stack. There's no dependency on a third party service. And so this is really, I believe, it's a refined version of that idea of GraphQL and Hasura, but in a much better package and a framework at this abstraction level.

And secondly, Redwood brings a monolithic developer experience similar to Blitz, but with Redwood, it's an optional monolithic deployment. So you can deploy them together as a monolith, or you can deploy them totally separate places if you so desire. And so just like that, all within about a month's time, all of a sudden we are launched into a new era for full stack react. This was a very exciting time.

So let's take a back, let's take a step back and look at Blitz and Redwood both, and look at what are the commonalities and try to understand where we're going with full stack react. Number one, both of these are full stack JavaScript and TypeScript. And so no longer do you have a separate language on your server versus your front end. And this is a very big point for me personally, and many others I know as well, that you get slowed down so much by having, say, Ruby on the back end and then JavaScript on the front end. And then additionally, you have the typing issue. you have full stack TypeScript, you can share code and types end-to-end and get end-to-end type safety. This is incredible. And it's hard. The benefit that it brings you to your productivity and debugging and all of that it's hard to overstate.

Secondly, both of these are batteries included frameworks like Rails and Laravel. And so this is awesome. You've had similar things in the JavaScript world, but not for React.

6. The Future of Full Stack React

Short description:

Blitz and Redwood bring a batteries included framework to full stack JavaScript development. They provide a monolithic developer experience and offer opinionated default conventions. Both frameworks seek to optimize full stack productivity. The future of full stack React looks promising, with a focus on making back end development easier for front end developers, increasing productivity, and improving backend architecture and patterns.

Most of them are server-side rendered. And so it's still full stack JavaScript, but it wasn't a batteries included framework with React. And so that's what Blitz and Redwood bring to the table.

Thirdly, they both provide a monolithic developer experience. So this allows you to just develop your app as all as one cohesive thing, and it's much simpler to think about.

Number four, both are opinionated, to various degrees. And this is really nice because it gives you a set of default conventions, configurations, you know, patterns and ideas. It's just like, hey, you should do it this way. And so if you don't know what to do, then, you know, follow that opinion. Of course, you can change and you can go against the opinions. Fairly easy for both of these, but it gives you a nice starting point.

And lastly, both of these seek to optimize full stack productivity. Most things until now have focused on optimizing either the front end or just the back end, but not both together. And this is a really hard problem to solve. But it's a problem worth solving.

So what do we look forward to? What do I think is coming for full stack react?

Number one, is that it's going to continue to be easier than ever for front end developers to do full stack. There are many more front end developers than back end developers. And so it really makes sense to make back end development easier for front end developers and do it and provide it a really nice developer experience and then everyone benefits. So this is definitely going to be an area of focus for Blitz and Redwood in the coming years.

Secondly, is we're going to continue to see increase in productivity for full stack development. And this is very significant for solo developers who are just doing side projects, solo developers who are building a business from scratch. This is very key. And then also small teams who are on a budget and you know, and trying to work together and and allows you to get more done with less people. So this is certainly going to be an area of focus as well.

Next is more backend architecture and patterns. Blitz and Redwood are both very minimal right now when it comes to the backend. There's we don't provide any APIs or recommendations. It's pretty, kind of leaves a lot to the reader to figure out where the coder in this case. But we absolutely want to make this better. And we're going to get there.

7. Backend, Serverless, Mobile App Integration

Short description:

On the backend, Blitz focuses on adding recommendations, libraries, and APIs for background processing, scheduled jobs, queues, emails, and file uploads. Serverless deployments and serverless full stack apps are areas of future improvement. Mobile app integration into the full-stack developer experience is a growing focus, with plans to add React Native support and bring the zero API experience to React Native apps. Follow FlyBear on Twitter for updates and visit for more information and easy documentation.

So there's the things that you need on the backend are things like background processing, scheduled jobs, queues, emails, file uploads, these sort of things. And so Blitz is going to be focusing on this on adding, you know, recommendations, libraries, APIs for these things. For example, like Nest, if you know about Nest.js, it's a very heavy backend framework. And so we're looking at Nest and seeing what patterns that we can bring to Blitz to make all of this even easier than it is now.

Number four is serverless. Now, while both Blitz and Redwood support serverless deployments out of the box today, serverless full stack apps are still the wild west. There are dragons, beware. I believe that over the coming years, we're going to see massive developer experience improvements for full-stack serverless applications. And it won't be just for really nice serverless deployments, but also serverless databases, serverless background processing and the queues, and a nice integration of all these things together. And so it's still the dream for many people to have this serverless workflow where you don't have servers to manage, whereas auto-scaling scales to zero. And so it's very cheap if you don't have very much traffic. So this is definitely an area to keep an eye on. And I'm very excited to see what comes down the pipe.

The other area to keep an eye on currently is mobile app integration into the full-stack developer experience. Currently Blitz and Redwood are mostly focused on the full-stack web experience, but increasingly mobile apps are a very common thing. And so we want to bring those into this full-stack developer experience. So you get, so like, like what good is it, right? If you have a nice full-stack web experience, but then your mobile app experience is just like kind of left to its own, like, like let's bring that into this entire full-stack thing. And then it's even easier for, for everyone, right? Like it's just, it just makes sense. So Blitz is going to be adding first-class React Native support. And so what we want to do is bring the zero API experience to React Native apps. And so you don't have to mess with Raster GraphQL. You just import your Blitz server functions into your React Native code, and then it would be compiled away, same as it is now, into an API call. So this is something that will be very exciting to come, hopefully sometime later this year.

And that concludes my presentation. Thank you for your attention. If you would like to keep up with what I'm working on, you can follow me at FlyBear on Twitter. And if you're interested in learning more about Blitz.js, go to, and documentation is there. It's very easy to get started. Additionally, on the homepage, the first video there is, I think it's like an hour-long video that goes into all the key areas of Blitz, the key features, and shows you how productive it can make you. So, definitely check that out.

8. Stickers, Mechanical Keyboards, and Frameworks

Short description:

If you want free Blitz.js stickers, go to and get them for free. Regarding mechanical keyboards, there is a range of opinions, with some finding them amazing and others not interested. Trying out different levels of clickiness is recommended. In terms of the frameworks being ready for production, both Redwood and Blitz are pre-1.0 but are being used in production. Blitz has over a hundred production apps, including, a medium-large player in the online casino space. They converted to Blitz due to performance issues with Sanity. Blitz is in beta, making it a good time to start a production app.

And last but not least, if you want free stickers, free Blitz.js stickers, go to forward slash stickers, enter your name and address, and we will send you free Blitz stickers. They're really cool. So, check that out. Again, thank you.

So, let's go back to that question about mechanical keyboards, and I'll open it up on my phone to see how people have been responding. Let's hear from you. Are you a big mechanical keyboard fan? Not yet, but I am waiting. I'm going to order the Keychron K3 as soon as it comes back in stock. Oh, wow. OK, so you seem knowledgeable about them, even though you're not into them. I feel that I'm falling into it, though. Yeah, yeah, yeah, I built this one myself.

So 52% say they're amazing, 27% say they intrigue me, but I've never tried one. 16% aren't interested in 6% are it's not for me. So I don't know. I like having the fancy keyboard. I've tried out some new switches at Target the other day and like the different clickiness. So I guess that's my advice for anybody out there is to to try out different levels of clicky and see if you like the different ones.

Okay, let's dive into some questions that are a little bit more relevant to your talk. It was an awesome talk, by the way, I really appreciated the journey through React. And then also the introduction to Blitz and Redwood, I especially like throw back back to like pre-ES6 React. That's when I started writing React in the Crete class days. So the first question that we got, and we got a couple that are kind of similar, but this one's from poplingay, are the frameworks ready for production and to what extent? So both Redwood and Blitz are pre-1.0, but there are people using both of them in production. And for Blitz specifically, I know that there's, I think there's probably north of a hundred production Blitz apps like that are running in like real businesses. And one of the largest is, and it's like a medium-large player in the online casino space. And they converted from Next and Sanity over to Blitz because they were having performance issues with Sanity. And so, yeah, they're running Blitz in production like since last fall and they're loving it. And there's tons of startups starting it. So Blitz is in beta. And so what I'm saying is now's a good time to start our production app.

9. The Evolution of React Frameworks

Short description:

Blitz.js and Redwood.js are frameworks built on top of React, blurring the line between library and framework. React itself is evolving into more of a framework with features like suspense and concurrent mode. Blitz.js and Redwood.js are aimed at teams of all sizes and are open source projects with community contributions.

It's not 1.0 yet, but there's minimal breaking changes and things. And then also the foundation is Next.js. So the foundation is already like super battle tested. And so what we add on top is pretty well tested at this point too. So we're expecting 1.0 probably in a couple of months, like May or June. Oh, coming up, super exciting. Oh, May is like next month. So that's really soon.

And a follow-up to that from rman, would we be talking about something that would be production ready for like a company with 200 engineers? Yeah. Yeah, for sure. Yeah, that's what we're working towards or what we're... Yeah, it's aimed for teams of all sizes.

Cool, I think you mentioned this a little bit in both your talk and so far in this Q&A, but this is from Alex. Is there a roadmap on when we could expect some of the future backend architecture patterns to come to Blitz, like background processing, emails, file uploads and more? So there's not a roadmap. So I don't have a company around this yet or at least yet. And so it's still like very much open source. So I can't really like say a roadmap of like, it's gonna be here and there, but I can say that right now, I'm focused personally on getting to 1.0, which means fixing bugs and things. So I'm not planning on adding any new features myself, but anyone else is welcome to come in and like kind of like, you know, dive in and help add new features. And so we're still having new features being added by other people, but it's just if whoever is motivated and so you're welcome to come help. We'd love it.

Awesome, awesome. So that's a call out to the community. If you want to see a feature, add it. So when React was first introduced, it was appreciated because it was just a library Blitz.js and Redwood.js seem to angularify React. And do you think that the React is just a library and mentality may diminish over time? And this is from Jayrock94. So I think React itself is becoming more of a framework, especially with suspense and concurrent mode, like outside of Blitz and Redwood. But yeah, and then like Blitz and Redwood, they bring they're like very much a framework. And so it's like, it's built on that concept of React, whether you call it library or framework, Blitz and Redwood are definitely a framework. Yeah, like plus one to that, the name library versus framework I feel like isn't even super clear anymore because I mean React does decide how you structure your front end code. Like it kind of is a framework, even if we call it a library.

10. Choosing Between Redwood and Blitz

Short description:

If you want to work with GraphQL and APIs, choose Redwood. If you prefer a faster implementation without the extra API layer, choose Blitz. Blitz is based on Next.js, while Redwood uses its own custom React framework. Blitz provides a level of conceptual compression and is popular among developers. Blitz.js comes preconfigured with Jest for testing and plans to add support for Cypress and Playwright. Users report being 5 to 10 times more productive with Blitz compared to other frameworks.

Another question. This one's from poplingay. And how to choose between Redwood or Blitz. So the real question is, do you want to work with GraphQL or do you not? Do you love dealing with APIs or do you not? If you do, if you want to use GraphQL and APIs, use Redwood. If you don't use Blitz because Blitz abstracts that layer away and it lets you just import your server code directly into your front end. And so Blitz, like one-to-one Blitz is a lot faster to implement a feature because you don't have that extra API layer. And so there's a level of conceptual compression that Blitz provides that is why a lot of people choose it. And then the other thing is also, Blitz is based on top of Next.js and Redwood is not. Redwood uses a custom, basically React framework. It's like it's its own framework. So if you really liked the experience from Next.js then choose Blitz. But if you're rather something a bit more like out of the box, trying new things, then try Redwood.

Cool, cool. Another one and this one's from Tech4Everyone. Is there any testing framework already available or preconfigured out of the box in Blitz.js? Yes. Yeah, we use Jest as set up by default. And so we have a Jest preset where everything's already configured together. We give you a test-utils file that has the providers, like the router providers and things already set up for you. So it's ready to go out of the box for Jest. And we will be adding Blitz recipes for Cypress and maybe Playwright for the more end-to-end testing. But we don't have that yet, but we'll get there.

Oh, that's awesome. That's really cool. And then a couple more. So you emphasized full stack productivity. Do you have a rough idea of how much Blitz increases your productivity? So what people are mostly saying is like somewhere between 5 to 10 times more productive with Blitz than what they were before. Like it's like significant. It's like where people are like, they like use Blitz on a side project and then they go back to work and they're like, this is awful. Like, I want to use Blitz everywhere. So it's, yeah, that's pretty cool.


Blitz: Openness and Backend Architecture

Short description:

Blitz aims to strike a balance between being open and opinionated. While it is more flexible than Rails, there is a desire to be more opinionated around defaults. Blitz abstracts the API into a compile step, inserting an API layer at build time. It allows for dynamic, client-side rendered data loading via queries and mutations. Inspiration for backend architecture and patterns is drawn from Nest.js.

That's awesome. That's awesome. This question is from Drake Yoon. Do you plan to be more open and allow everything type of framework or be more opinionated? So this is something that is a tension, like between people, some people want to be more loose, some people more opinionated. Right now we're kind of on the looser side and people are giving feedback that they want to be a bit more opinionated. So overall, it's more about like around defaults. There's not a lot of things that we're going to enforce, like versus Rails enforces a lot of things. And so Blitz is more flexible than that. But yeah, we're trying to make that balance as best we can. That convention versus configuration spectrum, right?

Cool. This one's from Radoslav. It's always fun saying people's usernames out loud. How does Blitz abstract the API? What do we do when we want to load data dynamically? So there is an API at runtime. So Blitz just abstracts into a compile step. And so at build time, Blitz inserts an API layer. And so by default, whenever you're loading data in your pages via your Blitz queries and then changing data via mutations, it is using an API. So it is dynamic. It is client-side rendered. Blitz isn't server-side by default, but you can opt into that on a page-by-page basis, same as Next.js.

Cool. Cool. We talked a little bit about bringing more backend architecture and patterns to Blitz. Are you taking inspiration for this from anything else? So one of the big ones that people have been using is Nest.js. So not Next, but Nest, N-E-S-T. And so that's confusing. But some people are using Nest with Blitz right now. Sort of like a stopgap. So we'll be taking some inspiration from that. And this is something that we would love more input on and contributions to and helping flesh out our back-end patterns and APIs. Awesome.

Nstarjs Libraries and Slido Interaction

Short description:

I like to call them the Nstarjs libraries because it's like Next, Next, Nest. Thank you so much for an amazing talk. Head over to Slido with the code 1415 to give 5 stars for Brandon's talk and join his discussion room on full-stack app development on

Awesome. I like to call them the Nstarjs libraries because it's like Next, Next, Nest. Very confusing.

Awesome. Well, thank you so much. Again, this was an amazing talk. If you liked it, go ahead and head over to Slido. And again, the code for that is 1415. And you can give 5 stars for Brandon's talk. And you can join Brandon in his discussion room, which is on full-stack app development on

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

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 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.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
Top Content
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

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