The Dawning of a New Age for Fullstack React

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
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.

This talk has been presented at React Summit Remote Edition 2021, check out the latest edition of this React Conference.

FAQ

React was first announced on May 29, 2013, at JSConf US.

Initially, React faced a lot of skepticism and criticism, particularly towards JSX. Some developers even created entire React applications without using JSX.

React introduced a new way to build and maintain complex user interfaces and provided a declarative component model, eliminating the need to use jQuery to update the DOM.

In 2015, React released ES6 class support, allowing developers to use ES6 classes to create components instead of React.createClass.

GraphQL, introduced by Facebook in 2015, is an API query language designed to address the limitations of REST APIs, optimizing back-end and front-end communication.

In 2016, Create React App and Next.js were released. Create React App focused on static single-page applications, while Next.js was optimized for server-side rendering.

React Hooks, released in 2019, changed the way React apps are written by allowing state and other React features to be used without writing a class.

Blitz.js is a full-stack framework for React that aims to simplify full-stack development by providing a zero-API data layer. It was announced on February 17, 2020.

The main difference is that Blitz.js abstracts away the API layer into a compile step, while Redwood.js keeps the API layer and optimizes it with a GraphQL layer.

These frameworks provide a monolithic developer experience, are opinionated to offer conventions, and optimize full-stack productivity by allowing shared code and types between the front-end and back-end.

Brandon Bayer
Brandon Bayer
34 min
14 May, 2021

Comments

Sign in or register to post your comment.
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.

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 blitzjs.com 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 blitzjs.com, 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 blitzjs.com/stickers 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 mr-gamble.com, 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 blitzjs.com 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 mr-gamble.com, 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.

QnA

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

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

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

A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
Watch video: React Concurrency, Explained
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.

Workshops on related topic

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

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

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

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

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