A Glimpse Into the Future of Fullstack Development with Blitz.js

Rate this content

Blitz was created as a fullstack React framework, inspired Ru on Rails, and with a goal to make you as productive as possible! It features a ""Zero-API"" data layer abstraction, has authn & authz out of the box and a few more exciting features. However, we recently decided to pivot Blitz to a framework agnostic toolkit, which means a huge and thrilling change for the Blitz community. During this talk, I will introduce the core concepts, talk about the why & how of the pivot, and give you a glimpse of Blitz's future.

You can check the slides for Aleksandra's talk here.

32 min
18 Feb, 2022

AI Generated Video Summary

Today's Talk introduced Bleeds.js, a full-stack React framework built on top of Next.js. It eliminates the need for an API layer, allowing server code to run directly from the frontend. The Blitz framework is pivoting towards a framework-agnostic toolkit to bring more people to Bleeds and decouple it from any specific runtime. The new Bleed toolkit will include core features like zero API data layer and authentication, with additional features like JWT authentication and advanced data-aware authorization. The audience showed interest in the Blitz Pivot concept and the ETA for the stable 1.0 release is the end of March.

1. Introduction to Bleeds.js

Short description:

Today, I'm going to talk about the future of full-stack web development with Bleeds.js. Bleeds is a full-stack React framework built on top of Next.js. It includes direct database access, middlewares, authentication with authorization. One of the core concepts is that Bleeds is monolithic. The most significant feature is the zero API layer, allowing you to run server code directly from your frontend.

Today, I'm going to talk about the future of full-stack web development with Bleeds.js. I will introduce you to what Bleeds currently is, and I will give you a glimpse into what is going to be in the future. My name is Aleksandra and I'm currently maintaining Bleeds, and previously I led a Hasura console team. You can find me on GitHub and Twitter, and you can also check out my personal website.

The agenda for today is to talk about the past, the current state, and the future of Bleeds. We'll go through the core concepts and features, and then I will explain what are our plans and what we are currently working on. Some of you might have already heard about Bleeds, or maybe you even used it in your projects. For those who didn't, Bleeds is a full-stack React framework. It was hugely inspired by Ruby on Rails, and built with a motivation to empower developers and give them the best possible experience for building full-stack and React applications. Bleeds is built on top of Next.js. Next is a framework mostly focused on the frontend, where Bleeds adds all the missing features and functionalities that turn it into a full-stack framework. It includes direct database access, middlewares, authentication with authorization. For the setDatabaseAccess, Bleeds is using Prisma, by default. It's a batteries-included framework, which means that all the boring things like Slint, Pretier, Husky, TypeScript, Jest, are already there configured for you. You can go straight to writing the business logic and shipping your products.

One of the core concepts is that Bleeds is monolithic. It means that you can reason about your application as a single entity. There's only one thing to develop, deploy, and think about. Now, let's talk about some of the core features. The most significant one is the zero API layer. If you're using React, it requires you to have REST or GraphQL API to connect to database or perform some business logic which is meant to be performed on the server. You need an API, even if it's not going to be used by third parties apart from your own application. Build times is also a source of complexity and sometimes it could be avoided. BLEEDS allows you to run server code directly from your frontend. How does it happen? So BLEEDS abstracts the API into a BUILD step. You can use the SERVER function in your frontend and BLEEDS will swap the import with an HTTP call at build time. The server functions are called BLEEDS resolvers and we have queries and mutations. However, they are just plain JavaScript functions, which will always only run on the server. Also, you can still add your own API if needed, and BLEEDS won't get in your way. Let's take a look at the architecture diagram.

2. BLEEDS Server Code and Queries

Short description:

At the top, we have client code and server code at the bottom. With BLEEDS, you can have a server-side rendered and a client-side rendered page next to each other. The middle layer is an auto-generated JSON API that exposes each query and mutation at a unique URL. We use Prisma to find the project with a given ID in the database. In a component, we use the useQuery function for queries and the useMutation function for mutations.

At the top, we have client code and there's server code at the bottom. In particular, we have one query and one mutation at the bottom. In your application, you can have a server-side rendered and a client-side rendered page next to each other. With BLEEDS, they can use the same server code. In build time, the middle layer is generated and inserted for you.

The middle layer is this auto-generated JSON API on the diagram. Each query and mutation is exposed at a unique URL, which means that you can also call those URLs directly, for example, from a mobile application. Here we have a sample BLEEDS query, it's called GetProject. And let's take a look what happens here. So we use that to define the shape of the query parameters. Then we parse the input to make sure that it's what we want. Later, there is a call to the database, we use Prisma here. And with this call, we are trying to find the project with a given ID. At the end, the query returns the project that we were looking for in the database.

In a component, we pass it to a useQuery function imported from Blitz. It's built on top of React Query, which is a great library, providing caching, polling, great developer experience, and many, many more features. Now let's take a look at the mutation example. It's not much different from the previous function. We also define the shape of the input, we parse it, we connect to the database to create a new object, and at the end, we return the newly created project. In a React component, we pass this function to a useMutation and then we use it upon a form submit.

3. Blitz Features and Future

Short description:

Blitz provides authentication and authorization out of the box, including a Passport.js adapter for third-party logins. The sign-up mutation handles password hashing, user creation, and session authentication. Code scaffolding in Blitz generates models, resolvers, pages, and form components. Recipes allow easy extension of applications with UI libraries and deployment logging tools. Blitz also introduces type-safe routes, enabling reference by name instead of URL. To get started with Blitz, install it globally and use the Blitz new command. The future of Blitz includes a pivot to a framework-agnostic toolkit, expanding beyond Next.js users to Remix, Speltkit, Nuxt, and more.

Another great thing about Blitz is that it has authentication and authorization out of the box. After creating a new application, you can sign up and log in instantly. All the code needed for creating new accounts for login logout is already there generated for you. There's also a Passport.js adapter, which allows you to add a third-party login.

Here we can take a look at the sign-up mutation provided for you in Blitz projects. This code is already there after you created a new Blitz application. So what do we have here? We hash the password with a secure password utility imported from Blitz. Then we create a new user in the database, we pass the mutation values and we pass the hashed password. As the next step, we create a new authenticated session. The CTX object is the second argument of Blitz resolvers and is provided by the session middleware and the session middleware is configured for you by default in your applications. In our queries and mutations, we also need to be able to restrict the access to the server code. For that, we can use, for example, this is one of the methods, we can use authorize function. So if user is not authenticated or if it's not authorized to access a resource, it will throw an error.

Blitz also comes with code scaffolding. You can use Blitz command line to generate models, resolvers and pages. For example, Blitz generate all project command, we create pages to list, add and edit new It will also create a new form component to create new projects. And finally, it will generate all the necessary queries and mutations. Then we have recipes, which were mostly inspired by Gatsby, and they provide us with an easy way to extend our applications. We have a bunch of recipes in Blitz, and they allow to, for example, add UI libraries, deployment logging tools, and a few more things.

So, another cool thing that Blitz introduced is type safe routes. Let's say you have a page called Products page. In a different page, you can import the routes object from Blitz, and then you can refer to the Products page by name instead of providing a string with an URL. So, if you want to get started with Blitz, you can install it globally, and then run Blitz new command. You will need to pass a name for your project, and then it will ask you a few questions. For example, whether you prefer JavaScript or TypeScript, what form library you want to use and what is your preferred package manager. Till now, I was mostly talking about the Blitz framework as it is now. But now, let me tell you about the future of Blitz Toolkit. At the end of the previous year, Brandon, the creator of Blitz, has announced the Blitz pivot. The plan is to move to a framework-agnostic toolkit that preserves all the developer experience that Blitz has and all the features that developers love about Blitz. But we want to bring it to not only Next.js users, but also Remix, Speltkit, Nuxt and so on.

4. The Pivot and Objectives

Short description:

This was a huge decision and a huge change for the Blitz community. The feedback was very positive, with most people agreeing that it was the best direction for Blitz. Blitz has seen significant growth with over 100,000 projects created and 10,000 GitHub stars. However, the reliance on Next.js has caused some challenges, leading to the decision to pivot. The pivot's objectives are to preserve the developer experience, bring more people to Bleed, and decouple it from any specific framework or runtime. The new Bleed will allow developers to choose the features they want and work with different runtimes.

This was a huge, huge decision, and it was a huge change for the Blitz community. As we were reading the feedback and we were going through what people were saying about the pivot, it only made us more sure that this is the right decision. The feedback was very, very positive. And most people said that this is the best direction for Blitz.

So Blitz is a community project and we value community over code, so you wouldn't be able to make this decision if it wasn't for this feedback, and if it wasn't for people telling us that this is the best choice. So you might be wondering why you even started thinking about it. So over 100,000 projects were created with Blitz, and we recently, a few months ago, passed the 10,000 GitHub stars milestone. Blitz got tons of positive feedback and people were saying that it made them super, super productive. However, as I mentioned before, this is based on top of Next.

What's more? So a few months ago, we forked the Next.js repository, which on the one hand, was a good decision because it allowed us to remove some custom compiler step. And it allowed us to hook directly into the Next code. On the other hand, it slowed us down as the migration to the fork was taking time. And we were catching up to Next.js. They have a great team and they make a tons of amazing things. So it's kind of difficult to stay up to date. The growth of Bleed has kind of stagnated and we are very much looking forward to improve that.

So let's talk about the pivot's objectives. We aim to preserve the developer experience as much as possible. We don't want to make any APA changes that we don't have to. And we don't want to change the existing features. Our main goal is to bring more people to Bleed or bring Bleed to more people. We want to enable developers to use some parts of Bleed, even if they don't want other parts or even if they don't use Next.js. Having said that, we want to decouple Bleed from any specific framework or runtime. We'd like to work with Deno, Cloud for Workers, and not just Node.js. Lastly, we want to ship more and more amazing features without focusing on maintaining Next.js. Let's compare it a little bit and explain how exactly the new Bleed will be different from the old one. You can think of the current Bleed as a bug with features like zero API, recipes, authentication, code gen, and it all stands on Next.js. While with the new toolkit, you can take those parts that you are interested at. You want a zero API but you don't want authentication? That's fine. Or maybe you don't want zero API but you like authentication that Bleed provides? That's also fine and possible.

5. BLEEZ Toolkit Features and Setup

Short description:

The new toolkit will include the core features of BLEEZ, such as the zero API data layer, authentication with authorization, and code scaffolding. Additional features like JWT authentication and advanced data-aware authorization will be added. The new toolkit could also support websockets, background processing, email integration, and more. Existing BLEEZ projects will continue to run with bug fixes and releases. The migration to the new setup will be made as seamless as possible with code modes and automation. The BLEEZ toolkit setup includes a setupServer function that returns setupClient, gcp, gcpAPI functions, and a BleedsServer type. Plugins like AuthPlugin, zeroAPIPlugin, and FileUploadPlugin can be passed to the setupServer function on the client side.

And on top of that, the foundation can be a framework of your choice. So let's go over the toolkit features that we plan to have. So we believe that the core value that this currently has is the zero API data layer, the authentication with authorization, all the conventions that we have, the new app and code scaffolding. So the new toolkit is meant to have all those features as well, and we plan to add a few additional things like JWT authentication, and for example, more advanced data aware authorization. But that's not all, there's a plenty of other features that the new toolkit could support, such as websockets, background processing, email integration, and many many many more.

In fact, if you have any ideas, you can let us know after the talk. You probably wonder, what about all the current BLEEZ projects? As I mentioned, there are plenty of them. So the existing BLEEZ applications will continue to run and will fix any critical bugs that came up. We'll be doing releases when needed, and we'll have BLEEZ in some kind of maintenance mode for as long as we need. We are also working to make the new setup as close as possible to the current setup. For any changes required, we'll have a code mode that will automate some of those changes, if not all. So the effort on the user's part should be as minimal as possible. For the existing projects, we want to make the migration as seamless as possible, with the set code modes and the automation.

So, let's talk about the BLEEZ toolkit setup now. I will show you a bunch of code snippets. And you can think of them as some kind of work in progress to the code. They are not final. This is something that we were talking about, thinking about, something that we are evolving around. But it's more or less what we want to have in the end. So we are going to have a setupServer function, which returns a bunch of things. For example, a setupClient, a utility to initialize the client part of Bleeds. It also returns gcp, gcpAPI functions, which will be wrappers for the GetServerSideProps, GetStaticProps, and Next.js API handlers. It also returns a type, BleedsServer, which you can use to type. For example, you can use it to provide to the setupClient function. Also, the setupServer accepts a list of plugins. The first one in this example is AuthPlugin. It takes a configuration to set a cookie prefix and a storage float to handle the session database management. You could also pass a zeroAPIPlugin with its own configuration and possibly some other plugins like, for example, FileUploadPlugin. So on the client, we'll have the setupClient function, as I mentioned before. And here, we'll also pass all the plugins that we want to have on the client site.

6. Client Plugin Interface

Short description:

The client plugin interface will provide utilities like useQuery, useMutation, useSession, and higher-order components. It will also include events, middleware, and exports for the plugins. The withProvider higher-order component will be used to wrap the application.

It will return a bunch of client utilities like useQuery, useMutation, useSession, with Blitz higher order components to wrap your whole application, QueryClient to configure the react query, and so on. Here is a client plugin interface. So this is also more of a pseudocode, but it will have events, something that should happen on SessionCreate and SessionDestroy, so that other plugins could plug into the auth plugin. It will have middleware, so things that should happen before http request and after http request, exports, all the functions that will be exported from the plugin, like useQuery and useMutation will be exported from zeroAPIPlugin, or useSession will be exported from the auth plugin. It can also have withProvider, a higher-order component which will be used to wrap the application.

7. Exploring the zeroAPI Layer and Plugin System

Short description:

Now, let's look more closely into the zeroAPI layer and how it could work with the Blitz Toolkit. We want to preserve the current API as much as possible and are considering keeping the magical imports. We are currently working on the plugin system and making it easily expandable. Takeaways from this talk: visit blitzjs.com or blitz-js.org for more information, provide feedback in the Blitz repository, and reach out to Alexandra or Brandon via Twitter or email.

Now, let's look more closely into the zeroAPI layer and how it could work with the Blitz Toolkit. We have a bunch of goals for it. Firstly, we want it to be a standalone library which is runtime and framework agnostic. We will use HTTP GET for queries, because currently both queries and mutations use HTTP POST. We will want to support multiple resolvers in a single file. And what's most important, we want to preserve the current API as much as possible. Ideally, nothing should change in the way that you write resolvers.

So here's a sample resolver, which looks exactly the same as in the current Blitz framework. We will import it into a Blitz setup file and pass to the setup server function, specifically the zero-API configuration. And then in useQuery, we'll pass a string with the name of the resolver. However, that's only one proposition. We strongly consider keeping the magical imports so that you don't have to import the resolvers to the setup file and you'll be able to import them directly to the useQuery or useMutation functions. We think that we can do this with a custom Webpack plugin and that's something that we are currently looking into.

So what we are currently working on? The plugin system, as is the most crucial part, we want to do it good so that it doesn't block us in the future, and it won't stop us from adding additional framework support. We also want it to be easily expandable, so that people can write their own plugins. At the same time, we're extracting some code from Blitz for better understanding of how it all should work together. We also set up a new monorepo on the main branch in the Blitz repository.

Okay, takeaways from this talk. You can visit the blitzjs.com website to learn about Blitz, or you can also check out the repository in blitz-js.org and it's called blitz. We would love your feedback, so if you have any thoughts about the pivot or any of Blitz features, let us know. You can join the discussion in the Blitz repository, or you can reach out to me or Brandon via Twitter or email. Thank you a lot for joining. And if you want to reach out, don't hesitate, we can continue talking about Blitz. You can find me on Twitter as AlexandraSes. Thanks a lot.

8. Audience Feedback and Blitz Status

Short description:

Alexandra asked the audience if they had used Blitz before. 50% said no, 32% said yes, and 18% hadn't heard of it. For those who hadn't used Blitz, the talk served as a good introduction. For those who had, the Pivot concept and the new Blitz toolkit were well-received. The Blitz project is still in beta, started two years ago with the community's involvement. After the Alpha release, they forked Next.js and moved the Blitz core code into it. They aim to complete all the planned features before the stable 1.0 release.

Hey Alexandra. Hi. Hi. Hello everyone. So, Alexandra asked, have you used Blitz before? And 50% said no, yes, 32% and 18%, only 18% said haven't heard of it. So I have to say, this is a pretty good number, right? 32%... Yeah, this is a pretty good number, you know. So as 50% didn't use Blitz, that might talk might have been a good introduction to Blitz. So that's nice. So people weren't bored. But for those who did use Blitz, I hope that they liked the Pivot thing and that they will be using the new Blitz toolkit. And yeah, 80% haven't heard. I think that's a nice number, you know. Only 18%. That's good. That's good for Blitz. If we ask this question to the same audience again tomorrow, then it will be 50-50, of course. Yeah.

All right. We're gonna jump into some of the audience's questions. First question is from Populinga. Is the Blitz project still in beta? Yes. Yes. It's still in beta because Blitz was started initially like two years ago and Brandon, the creator of Blitz, was working on it with the community for a while. Then they released Alpha and a few months after Alpha, they released Beta. And the thing is that we then, like sometime after the Beta release, I joined and we were instead of using Next.js as a dependency, we forked Next.js. And, you know, we removed our custom compiler. We were moving the Blitz core code into Next.js. We wanted to have it all done before the stable release. And we also had some other features in mind to be completed before the official 1.0 release.

9. Blitz Pivot and ETA for 1.0

Short description:

We decided to pivot to bring Blitz to more people using other frameworks. The framework is in beta, and the toolkit is our focus now. The ETA for 1.0 is the end of March. We are still fixing bugs and making releases. Despite that, I recommend using Blitz because it's stable and gives you a lot of power as a full stack developer.

However, in the meantime, we decided to pivot for the reasons I mentioned in the talk. We wanted to bring Blitz to more people that use other frameworks, not only Next.js. So that's why the framework is in beta.

And is there an ETA on 1.0? We won't be working on the framework itself, like, we won't be, you know, focusing on that. We just shifted our focus 100% to the toolkit. Maybe not 100%, because we are still fixing bugs. We are still making releases of the framework, because you know, so many people are using it and we want to maintain it. If someone submits a PR, we also spend some time on reviewing it. But, yeah, like, regarding bigger things like the 1.0 release, we plan to have the toolkit as 1.0, as, you know, the new official stable Blitz. Yeah, that's what I mean. Sorry. Yeah, the ETA. So, we are targeting the end of March. Right now we have some things working. You can check out the main branch in Blitz repository. We have some work in progress. And yeah, we plan to finish it over the next few weeks. That's pretty exciting. Yeah, that's exciting. Five, six more weeks, end of March. Yeah, I better hurry and go back. Yeah, I will go, bye bye.

Next question is quite a good one. For people who want to start a new project tomorrow. Would you recommend choosing Blitz? Or should people kind of stay away until the Biffin is completed? So I would still recommend using Blitz because it's a framework used by many developers. And although it's not 1.0, it is kind of stable. And it gives you a lot of power as a full stack developer. And even though we are working on the toolkit, we want to make this transition really smooth. There will be code modes. We'll be working on them as well.

10. Blitz Toolkit and Exciting Features

Short description:

The Blitz toolkit will have a command to convert Blitz projects to Next.js with the toolkit. Manual steps will be minimized, and code mode will automatically cover most aspects. The focus is on the toolkit, but small improvements to the current Blitz framework are still accepted. The new toolkit may include new features like JWT authorization and authentication. The most exciting part of the toolkit is the plugin system design, which allows users to choose specific plugins and write their own. Making the plugins framework agnostic was a challenging and exciting task.

So when you actually have a Blitz project and we have the toolkit ready, there should be a command that converts the Blitz project to a Next.js with Blitz toolkit. And maybe there will be some configuration on your site, some manual steps. But we want to have them as limited as possible. We want to automatically cover almost everything for you with code mode and so on. Yeah, that's nice because else it's too dangerous or scary to choose Blitz now. So it's very good that you're putting in the work for this code mode. Thanks.

And what are some new features you will be adding to the Blitz framework? Or will you be adding any? Yeah, so we won't be adding new features to the Blitz framework because we want to focus as much as possible on the toolkit. However, we're still like for small things, we'll still accept PRs. So if there is like a small thing that would make the current Blitz better and it won't require like many hours, like hour-hours on review. And it's like just PR and we can ship it, then we still are adding those kind of things. We are not working actively on the framework's features. But possibly, the new toolkit will come with like new features out of the box, like in Blitz framework, we didn't have JWT authorization, authentication. But maybe we'll have it like from the first day in the toolkit. So you can expect those kind of things in the toolkit. Maybe, but this maybe is in five weeks, so I think we got a glimpse of the future here. Yeah, we did. Nice.

Next question from Hail of the Wood. Of all the things in the roadmap for Blitz toolkit, what are you most excited about working on? What I'm most excited about working on? So that's a nice question. So the most tricky part about the whole toolkit and something that we had to initially spend a lot of time figuring out is the whole plug-in system design, like how to make this new Blitz toolkit so that there are plug-ins and people can use, only like, you know, some of those plug-ins, like someone wants authentication from Blitz, but they don't want anything else or something else and how to make it good so that people can write their own plug-ins and so on. So that was like a challenge. And another challenge on top of that was how to make those plug-ins framework agnostic. So that was kind of exciting, like figuring this out. So like I initially spent some time like just setting up a Next.js, like simple Next.js application and like working on like a skeleton of how this plug-in system could work. And that was quite exciting because I could then see, oh, so I need this kind of thing because this authentication works this way and possibly I need plug-in to work this way because the Zero API works this way. And so that was challenging and exciting. Yeah, nice. Yeah, it's a good way of building what you need just being your own customer basically and you see it coming to life what you need. Yeah, nice.

11. Blitz Inspiration and Similarities

Short description:

Blitz, yes, reminds me of Meteor. Were they inspiring for you? A huge inspiration was Ruby on Rails. The idea was to have something like Ruby on Rails in JavaScript world.

Yeah, sometimes you have to experiment. Exactly, we have time for one quick question and answer. This from JSfire, Watch69. As a framework for a full stack developer, Blitz, yes, reminds me of Meteor. Yes. Were they inspiring for you? So, I'm not sure if that was an inspiration for Brandon initially. I know that like a huge inspiration was Ruby on Rails. And I think that, you know, like the idea was to like have something like Ruby on Rails in JavaScript world. So I think regarding this particular inspiration that would be the question to Brandon. I can ask him, you know, quickly after this stretch. And that, you know. If you can enter the Discord to JS Firewatch, then that would be awesome. Yep.

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
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
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 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
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 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
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
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
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
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