Blitz.js - The Fullstack React Framework

Rate this content
Bookmark

Blitz is a hyper productive framework for building fullstack React apps. You'll learn why I created Blitz, it's advantages and disadvantages, how it makes you so productive, and for what cases you should consider using Blitz.

Brandon Bayer
Brandon Bayer
32 min
17 Jun, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Blitz is a framework for building full stack React apps with a monolithic architecture and no API layer. It uses Next.js and Prisma 2 and follows convention over configuration. Authentication and authorization are set up by default, and adding social login is easy. The Blitz community emphasizes inclusivity and welcomes contributions. The future of Blitz includes a stable release cycle and the vision of bringing the Zero API experience to mobile.

Available in Español

1. Introduction to Blitz and Full Stack React Apps

Short description:

Hello, everyone! Today, I'm going to talk about Blitz and building full stack React apps. I wanted to love full stack web development again and be extremely productive. To achieve this, I knew I needed a monolithic architecture and no API layer. Initially, I thought server-side rendering was the solution, but I wanted something even easier. That's when I realized you could write server-side functions and import them directly into React components.

Hello, everyone, it's so exciting to kick off the second day of React Summit. We had awesome talks yesterday, and I'm excited to talk this morning about Blitz and building full stack React apps. So let's get into it.

I was building full stack React apps for a few years. And I happily put up with the complexity and struggle required to do so. And I did that because I loved building user interfaces with React more than any other way. But the honeymoon ended. And I became increasingly frustrated with rest, with GraphQL APIs, Momex State Tree and a host of other API services and libraries, managing multiple servers, managing multiple servers, multiple deployments, etc. Anything that got in the way of me building features slowly depleted my morale.

I really wanted to love full stack web development again. I wanted to be extremely productive again at building full stack apps. I wanted to focus on building features instead of mostly marshaling data all around the universe. So I decided enough was enough and I set out to build the best possible developer experience for full stack React apps. Well there there was two fundamental things that I had to have in place to achieve the developer experience that I wanted. Number one, it had to be monolithic. And a monolith means that there's only one thing. Everything is all together in one thing so there's only one thing to develop, there's only one thing to deploy, there's only one thing to reason about as you think about your entire architecture. And a monolith is just really awesome. And in my experience with Ruby on Rails, I came to really appreciate the benefits of a monolith. Secondly, is no API. The API layer in React Apps is the biggest source of complexity, headache, heartache, holes in the wall, Oh, whoa Brandon, that's too much, it slows you down more than you would think about. And I knew that I had to go somehow. Okay Brandon, that sounds great, but how are we going to do this? Well, does it mean we have to go back to 2004 and do server-side rendering? I thought so. And I was prepared to embrace that. Cause I wanted this developer experience, without the API, so bad, that I was willing to go down that route. And in fact, when I first announced that I was working on Blitz, the initial prototype was server-side rendered. But the early Blitz contributors and myself were trying to figure out what would the architecture of Blitz really look like. We were exploring all sorts of things, model-view-controller, basically everything under the sun. So one day, I was laying in a hammock in Thailand, thinking about this, and I asked myself, what would this look like if it was easy? So I thought about that for a bit, and I realized that if it was easy, you could write functions that run on the server and then import them directly into your React components and use them directly. So you could use them without doing fetch calls or API endpoints or HTTP or any of that.

2. Blitz Key Factors, Features, and Principles

Short description:

It would just work. And so I was like, wow, that's pretty awesome. This could be a game changer. And it turns out it was. Now you know about the single biggest defining factor of what Blitz is. Next.js is a wonderful framework that is fast, flexible, performant, and provides a great developer experience. Prisma 2 is the modern way to access databases, with a nice schema, declarative migrations, and fully-typed database access. Blitz has three key factors: full-stack and monolithic, no API required, and convention over configuration. It also has seven main features and principles: scalability, no API required, convention over configuration, loose opinions, easy to start and scale, and stability.

It would just work. And so I was like, wow, that's pretty awesome. This could be a game changer. And it turns out it was.

Okay. So now you know about the single biggest defining factor of what Blitz is, so let's talk about the second two. I mentioned that I was just frustrated with full-stack web development in fact, but throughout that entire time there was one thing that constantly shone through the mess, and that was Next.js. Next is such a wonderful framework. It's so fast and flexible and performant and it's a nice developer experience. And so it was so clear that it was a perfect thing to build on top of and add all the other things that you need for full-stack web development.

Okay, so now we need a way to talk to the database. And back in February when I started Blitz, Prisma 2 was just coming out in beta, and it was just pretty obvious that this was going to be the modern way to access databases. And if you don't know about Prisma 2, it's awesome because you have a really nice schema that you can define and have declarative migrations from that schema. You generate a TypeScript client from that schema, and so you have fully-typed database access. And then in Blitz, those types can flow all the way down to your frontend. So everything is fully typed, end-to-end.

Alright, so those are the three key factors of what Blitz is. Let's talk about the seven main fundamental features and principles that define everything else we do. So, full-stack and monolithic, I touched on that. One thing I want to mention is that a modern monolith scales much better than, like, Ruby on Rails, for example. And that's because you can deploy Blitz to a serverless environment. Not just a server, you can do both. But if you deploy it serverless, all your server endpoints can be independently scalable as serverless functions. So the whole scaling thing with a monolith just sort of goes away. So that's really awesome. Secondly, API not required. Number three, convention over configuration. Number four, loose opinions compared to strong opinions that are hard to go against. Number five, easy to start, easy to scale. Number six, stability.

3. Blitz API Layer and Architecture

Short description:

We abstract the API into a compile step, swapping it out with an HTTP API at compile time. Blitz uses queries and mutations, plain asynchronous JavaScript functions that run on the server. You can always add an API to a Blitz app, as we have fewer restrictions than Next.js. The architecture allows for both server-side and client-side rendered pages, using the same server code. Convention over configuration means most of the setup is done for you, saving time at the start of a new project.

And number seven, community over code. Okay, so let's talk about this API layer a bit and get into how we actually do this and how it works. We abstract the API into a compile step. So as you're developing your app, like I mentioned, you don't do any API stuff, you just import the server functions into your front end and then at compile time we swap that out with an HTTP API. And so you do get client-side rendering, but without any of the API headache.

And how you do that on a Blitz app is what we call queries and mutations. Now this has nothing to do with GraphQL, we just use the same nomenclature and they're just plain asynchronous JavaScript functions that always run on the server. If you're familiar with Ruby and Rails, or Laravel, the controller concept, it's basically replaced by queries and mutations. Now of course, you can always add an API to a Blitz app because there's zero restrictions that we give you. So we're 100% compatible with Next.js. And in fact, we have less restrictions than Next.js does. So you don't have to worry about Blitz getting in your way.

Alright, so let's look at an architecture diagram here to maybe give you a rough idea of how this all fits together. So along the top is client-side code, along the bottom is server-side code. And the purple boxes are pages, React pages. And so you can see that in a single app you can have a server-side rendered page and a client-side rendered page side by side. And they can use the same server code. So the green boxes at the bottom are a query and a mutation. And both of those pages use the same query. And then at build time, this middle layer is inserted automatically for you, which is a JSON HTTP API. So all your queries and mutations are exposed at a unique URL. And you can use that directly for mobile apps or third parties or anything else.

Okay. Let's talk about convention over configuration. This means by default, things just work. And it doesn't mean no configuration. It just means configuration is optional. So most of the boring stuff is completely done for you out of the box. And you especially see a lot of this a principle whenever you generate a new app. Because it has so much stuff set up for you, basically all the things that you would set up you would take the first week or so of a new project and set up all that's done.

4. Blitz Authentication and Authorization Setup

Short description:

We include ESLint, Gear, Jest, Husky githooks, and more already set up for you. Authentication and authorization are set up by default in new apps, allowing you to immediately sign up and log in as a user. Adding social login is easy with the Passport.JS adapter.

So we include ESLint, Gear, Jest, Husky githooks, and a number of other things just already set up for you. Now the big thing that's really awesome is authentication and authorization is set up in new apps by default. So that means when you run Blitz new in your app name and generate a new app you can immediately sign up and log in as a user. And isn't that amazing? You don't have to ever do authentication stuff for so many projects because you get it out of the box with Blitz. And then if you want to add social login, we have a Passport.JS adapter that you can just drop in on a single file, and very easily add in GitHub authentication or any other type of thing that, anything there's a Passport.js adapter for.

5. Code: Sign Up Mutation and Git Project Query

Short description:

This part covers a sign up mutation that runs on the server, using Zod for input validation and Prisma 2 for database operations. It also explains how to use this function in a sign up form and the simplicity of the process. Another topic discussed is the git project query.

Okay, let's get into some code. Alright, so this is a sign up mutation that always runs on the server. And basically this same thing is what you'll get in a new app by default. This will be generated for you. So, you can see we export a default async function. And the first argument to that is the argument to the mutation. And the second is a context parameter. And this context parameter is provided by middleware and Blitz. And so by default you have one middleware configured, which is session middleware. And that's built in session management from Blitz.

Ok, and so inside this mutation, the first thing we're going to do is validate the input. And we use a library called Zod that's really awesome for both runtime validation and TypeScript types. So you're guaranteed that after this line, email and password are both strings, and the password is has a minimum length. Ok, and then we're going to hash the password and then we're going to create a user in the database. And this db object is provided by Prisma 2. And so you can see how nice it is just to create a user. So email, a password, and you get that user back. And then secondly, the last thing we do before returning is to create a new session, which is how you log in. And you can set the user ID, roles, anything else you need in there to use on the frontend. Ok, so fairly simple.

Now, how do we use this? Well, you import this direct function into your component. And so here is the sign up form. And you can see we import, it's on the 5th line I believe, we import that function we were just looking at. And we pass it to the use mutation hook inside the component. And then we can just use that mutation thing inside the own submit hook. And so you just call it a wait just like a regular function there. And it just all works for you. So super slick. Alright, let's look at another one. This is a git project query.

6. User Authentication, Community, and Contributions

Short description:

In this part, we discuss how to ensure user authentication and authorization in Blitz. We also cover the use of the useQuery hook, which simplifies the process of fetching data. Getting started with Blitz is as easy as installing it globally as a CLI and running Blitz new to generate your app. We emphasize the importance of community and treating every person with dignity and worth. We invite contributions in the form of code, documentation, tutorials, and more. Donations and sponsorships are also appreciated.

So you can see again we get some inputs and then the contex parameter. And the first thing we do in this case is call session.authorized And this is going to ensure that the user is logged in. If it's not it will throw an error. And that error will propagate all the way to the front end and it will show either a login form if they're not logged in or it will show it on an authorized page if they don't meet the required rule. And of course you can customize that whatever you want. But that's the default setup. So we find the project and if it's not we don't get the project and we throw a not found error and again that propagates to the front end and shows a 404 page.

Alright, so let's use this thing We simply import this function over into your component. And inside this project component the first thing we do is get the parameter from the route. So this is project ideas. A dynamic parameter that you get from the url and then we have a usequery hook that you pass that query function we were just looking at, you pass it to usequery and then the second parameter to that is the argument so where id is equal to the id of this route and then you get that back and you just render it. Now one thing to note here is we have concurrent mode enabled in Blitz by default and so you're using suspense which is really awesome. So you can see in this component we don't have this entire if else dance of if loading show the loading if error show the error, if something else show something whatever. It's just very simple so it's really cool and then in the page component toward the bottom half of the screen you can see we have the suspense component and the fallback for the error and so it's a really nice API. Usequery is built on top of reactquery and reactquery provides a ton of awesome stuff that you get by default in here caching all your server data, caching and validation, polling, all these sorts of things, really powerful features and you just get it by default.

Okay, so how do you get started with Blitz? Well it's pretty hard there's only two commands and first thing is install Blitz globally as a CLI and then secondly is run Blitz new and pass it the name of your app and that's it. And it'll just generate your app for you, install your dependencies and so forth, and then like I mentioned you can immediately sign up and log in as a user and it's awesome.

Alright, let's talk about community over code, so this is one of our foundational principles. People are far more important than anything else and these are principles that we hold dearly in the Blitz community, but it's also principles that we as a tech community at large really embrace and live by. Secondly, we treat every person with dignity and worth regardless of who they are, what their beliefs, they, every person is worthy of dignity and worth. We're all in this together, we all want to be productive, we all want to have fun in our jobs and we're all more similar than we are different, so we can and should solve problems together. We have an entire page in our documentation linked here that details how the Blitz community operates, we'll go through pretty much everything and so you can get a good idea like if you want to be involved in the Blitz community or not, you know, want to see how things operate, that's a good place to do so.

OK, now let's talk about how you can contribute to Blitz. So we need your help, we love all the help we can get, we have a bunch of features in our GitHub that are ready to work on but they're just sitting there waiting for somebody to work on them. I'm working mostly full-time on Blitz and then doing consulting on the side. So far, I'm doing the, I'm contributing by far the most, but we'd love anyone else to help in their free time as much as they can. We appreciate any type of contribution, whether it's code, documentation, improving documentation, tutorials, videos, blog posts, anything you can think of. Secondly, donations and sponsorships, it's my goal to work full-time on Blitz without having to do consulting on the side and then beyond that, I would love to pay other people to work on Blitz too, full-time. I would love any type of donation or sponsorship that you can give us through GitHub. There's a button on our GitHub repo.

QnA

Blitz Documentation and Community

Short description:

The best place to get started with Blitz is the blitzjs.com documentation. Follow Flybear and Blitzjs on Twitter for more updates. Feel free to reach out with any questions or to share your experience with Blitz. The current plan is to switch to beta status in the next week or two, with the goal of reaching version 1.0 by the end of the year or early next year. The Blitz community is made up of core team members, maintainers, and a large number of contributors. Maintaining Blitz involves spending around 30 hours per week on average, with consulting work on the side. A typical day includes answering questions on Blitz Slack and working on Blitz development.

And then, secondly, the best place to get started here is this blitzjs.com documentation, which is linked here. So this concludes the end of my presentation. Blitzjs.com is the best place to go to get started there, you can follow me at Flybear on Twitter and Blitzjs on Twitter as well. And so I would love to answer your questions now and anytime later on Twitter anything just reach out happy to help answer questions and I would love for you to try out Blitz and let me know how it goes. Thank you so much.

Amazing, welcome. Thank you so much for your talk. I'm going to jump right in with some questions. First of all, congrats on Blitz, it looks like it's going great. When is it going to be 1.0? So we are currently discussing right now. We're currently in alpha status, but we're discussing switching to beta status probably within a week or two. So we're getting close. So now that we're basically almost in beta status or focused on smoothing out rough edges fixing bugs, adding more tests and all of those sort of things to get to 1.0. So there's not anymore major changes planned. So hopefully around the end of the year, early next year, we'll be 1.0 we'll kind of see how it shakes out. It's hard to schedule open source, but we'll see.

You talked a little bit about this, about the community, but could you tell us a little more about who's involved and how you're managing it? Sure. So there's two other core team members besides myself Rudy and Dylan. And then I think we have about three level two maintainers now, and a level two maintainers have ownership over a certain part of the code base and kind of help manage reviewing PRs and merging them. Then there's about eight or so level one maintainers that just help us community, answering questions and so forth. And then there's a whole host of other contributors. I think we're over 120 now total people that have contributed to Blitz in some way with code, documentation, etc. So it's a great community. We all have a lot of fun and so anyone is welcome to come and help contribute.

That's really awesome. You're maintaining this full time, I think you mentioned. What is life as a maintainer like in open source? Sure. So right now, I'm spending about 30 hours per week on average on Blitz and then another 20 or 25 per week doing consulting on the side to support myself. So how a typical day looks like. I wake up, I look at Blitz Slack and answer questions, check on a few things and then I do consulting work to get me through the first part of the day and then when I get bored of that, I switch over and do Blitz stuff for the rest of the evening.

Blitz Resources, API Compatibility, and Future

Short description:

Some of the audience wants to know whether you or your community have any good resources for someone who maybe hasn't contributed to open-source before and wants to get started. We have a How to Contribute page on our documentation and we try to spell it out very clearly. So that's the best place to get started and then we kind of walk you through how to clone the blitz repo and then what type of things you can work on. We have a bunch of issues that are tagged ready to work on and then we also tag them good first issue and good second issue. So those are good places to see like, ok this is something that I can do. So how did you get into blitz, did you have a bad time with an api and you were like I never want to do this again? I started web development using Ruby on Rails back in 2014. I learned Ruby on Rails and it was pretty easy to do full stack stuff. Then I moved on to React and I loved that but then we had that whole api layer that makes it a lot more complex than Ruby on Rails. Finally, I decided enough was enough and we needed to have that same type of easy, simple, full stack experience that you get with Ruby on Rails or Laravel or Django and bring that to React. Is Blitz.js suitable if you have a shared API that is consumed by multiple platforms, i.e. iOS, Android, Native and JavaScripts? Yeah, you can absolutely do that with Blitz. You can do it like you normally would with Next.js for example, just connecting to the API from the client or the other way to do that is to use Blitz queries and mutations and talk to the API from the server and then use the Blitz API data layer to manage that. Is there anything Blitz is not suitable for and when would you not use it? Blitz is probably not going to be suitable for building something as massive as the core Facebook. But it's really great for prototyping right now and for makers, indie hackers, and new startups. Do you maybe not officially, but in your head have the good future of Blitz? Like what would a 2.0 look like or a 5? Good question.

That's awesome. Some of the audience wants to know whether you or your community have any good resources for someone who maybe hasn't contributed to open-source before and wants to get started? We have a How to Contribute page on our documentation and we try to spell it out very clearly, like first things first we have a link out to Kent C. Dodd's egghead video on how to get started with open-source. So that's the best place to get started and then we kind of walk you through how to clone the blitz repo and then what type of things you can work on. We have a bunch of issues that are tagged ready to work on and then we also tag them good first issue and good second issue and so those are good places to see like, ok this is something that I can do and a lot of times the good first issues are really easy like just changing one word or something very simple a lot of times it will get fixed within an hour of whenever we post them so just watch the repo and keep your eyes out for those.

That's awesome, I bet there are some other maintainers pretty jealous right now. So how did you get into blitz, did you have a bad time with an api and you were like I never want to do this again? So I touched on that a bit in the talk but I started web development using Ruby on Rails back in 2014 I think is when I started learning web programming because I was doing C and C++ before that and so I learned Ruby on Rails and it was pretty easy to do full stack stuff and then I moved on to React and I loved that but then we had that whole api layer that makes it a lot more complex than Ruby on Rails and then finally I decided enough was enough and we needed to have that same type of easy, simple, full stack experience that you get with Ruby on Rails or Laravel or Django and bring that to React. So did you miss it, Ruby on Rails? Yes and no. There's a lot of things I liked about Ruby on Rails especially how there's no api in there but there's a lot of things I didn't like. I like JavaScript and TypeScript way better than Ruby and so my goal is to take everything good about Rails in my opinion and then leave out everything that was bad. So I think we've done pretty well at that. Last week one of the Blitz developers had been using Blitz for a couple months now and he said that he had been developing Ruby on Rails apps for 10 years professionally and now after just a few months with Blitz he's already 10 times more productive with Blitz than he ever was with Ruby on Rails. So that's kind of mind blowing.

Alright so we have from Oakley in the chat, is Blitz.js suitable if you have a shared API that is consumed by multiple platforms, i.e. iOS, Android, Native and JavaScripts? Yeah, so I'm assuming you have like an existing API that you want to connect to and you can absolutely do that with Blitz. You can do it like you normally would with Next.js for example, just connecting to the API from the client or the other way to do that is to use Blitz queries and mutations and talk to the API from the server and then use the Blitz API data layer to manage that and by doing that you can use the Blitz session management which is very easy and integrated versus your own authentication somehow. So it's totally up to you, totally flexible.

I don't know if you get this question a lot but it's a classic. Is there anything Blitz is not suitable for and when would you not use it? So kind of our motto or goal is to be the framework for the 99% of us that work at companies less than 100 employees. So Blitz is probably not going to be, you're not going to build the next like you couldn't take out the core Facebook and swap in Blitz. It's just far too complex for something that massive but you can totally start the next Facebook with Blitz and it will definitely grow with you and you'll end up needing to spin up other services around that. But it's really great for prototyping right now and then we'll also have a lot of people that are building production SaaS applications. So any type of application where you need to have some login, a database and you're connecting to that is really great for that. And especially for like for makers, for indie hackers new startups, it's really great.

Do you maybe not officially, but in your head have the good future of Blitz? Like what would like a 2.0 look like or a 5? Good question.

Blitz Future and Updates

Short description:

Blitz is great for prototyping and building production SaaS applications. The vision is to bring the Zero API experience to mobile, allowing for a seamless multi-client app. Next.js focuses on lower level universal solutions, while Blitz is more opinionated with a database layer. Updates in Blitz are handled by upgrading the Blitz dependency.

But it's really great for prototyping right now and then we'll also have a lot of people that are building production SaaS applications. So any type of application where you need to have some login, a database and you're connecting to that is really great for that. And especially for like for makers, for indie hackers new startups, it's really great.

The big thing that really the main thing that I have a vision for that we're not even really close to yet is to have the same Zero API experience like we have right now with Web and bring that to mobile to React Native, for example. Today you can use Blitz with mobile apps. You can connect to the generated API endpoints and use that normally. We have a few people that are working on doing that. You don't have that Zero API experience. You're still doing the calls or whatever you need to do from mobile.

The first thing we can do to that is generate an API client and that's relatively simple. We can do that for multiple different languages so it makes it easy to have a typed client and easily talk to the Blitz backend. Then even beyond that, I want to have a supported where you have a monorepo where you have your normal Blitz web app there and then also React Native app in the same repo and then you can import your Blitz queries and mutations directly into your React Native code and then we would swap that out at compile time to be the same type of API client like we do with the web. So we want to bring that to mobile. So I'm pretty sure that is possible, we can do that somehow, but that's definitely a bit out on the road map but that would be really awesome so you have this entire multi-client app, web app, mobile app, without dealing with REST or GraphQL or any of it. Blitz everywhere. I mean, that's the spirit, right?

Metin from the chat wants to know, have you ever had a moment where you considered just adding some of these features to Next.js since that's also open source? So Next.js team is pretty clear about that they are solving the problems, the scope that they're at now, they want to stay at, where it's relatively minimal and they're solving problems that pretty much are universal kind of lower level things working on RFC for internationalization, RFC for an image optimization component. So these are kind of lower level fundamental things but where Blitz is a bit more opinionated. So we have the database layer, the full stack data layer things. So they don't want to go with that for opinions. So I think it works out good because there's a lot of people that want that lower level and they want to bring all their own opinions and craft their perfect stack in the end. But then there's also other people that Blitz is good for that they don't want to spend a week or two picking libraries and setting things up and hooking things together. They just want to get something built. Fair enough.

Dennis wants to know, I'm a bit curious about how updates of Blitz itself might be handled in the project using Blitz. Like if at some point some underlying library is going to be changed. Right now, Blitz, there's one dependency you upgrade Blitz and then you're good to go. You can do some editing changes right now, which there are occasionally. You just watch release notes and make that change.

Blitz Editing Changes, Release Cycle, and Recipes

Short description:

You can make editing changes now and watch the release notes for updates. After reaching 1.0, a stable and predictable release cycle inspired by Ember will be implemented. Blitz Recipes allow for easy installation of third-party code, and there are plans to enable automatic upgrades with 'blitz install blitz'. Thank you, Brandon, for joining us.

You can do some editing changes right now, which there are occasionally. You just watch release notes and make that change. Then after we get to 1.0, we're going to implement a really stable, predictable release cycle inspired by Ember. How Ember does it, every six weeks there's a new stable release. Then there's also an LTS release that a new one's released every six months. The next release is in beta for six weeks. That's stable and unlikely to get bugs in the final version. And breaking changes are handled nicely with deprecations. We're going to plan on doing that.

We also have a thing called Blitz Recipes, which I don't think I talked about in my talk. That's a one command to install any type of third-party code. You can do blitz install TEOWIN, blitz install Chakra, blitz install Emotion. We have a few of those, we're still building those out. That's another really awesome thing. Where I was going with that is eventually we could have blitz install blitz. And it would upgrade blitz automatically for you. That's really cool.

We are out of time, Brandon, but thank you so much for stopping by. You can all go find Brandon in the Discourse or later in the rooms.

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 Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
Using useEffect Effectively
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
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.
Full Stack Documentation
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Top Content
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Concurrent Rendering Adventures in React 18
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
Maurice de Beijer
Maurice de Beijer
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

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

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

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

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