The Dawning of a New Age for Fullstack React

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 29th, 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. People were especially upset at JSX. In fact, there were entire code bases 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 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 came before. And another really nice invention here was the declarative component model. And so this, you know, you 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 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.create class to create all your components. If you don't know what I'm talking about, go Google react.create class 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 larger. 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. It was bringing focus to this important piece and seeking to optimize it and making it 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? It seems like 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 a static single page application. 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, right? 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. 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. graphql 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 graphql 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 graphql was released in 2016, graphql was only a year old. And so 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 host it, 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. 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 going to 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. And 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 fellow by the name of Brandon Bair 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. And 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 there's it's just 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 in what it gives you out of the box. And so by doing this, Blitz effectively creates a custom distribution of next.js, similar to like 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 like 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 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. So when 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, like the benefit that it brings you to your productivity and debugging and all of that is hard to overstate. Secondly, both of these are batteries included frameworks like Rails and Larvo. And so this is awesome. We've had similar things in the javascript world, but not for react. 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. And 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, and 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 trying to work together and it 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 back end architecture and patterns. Blitz and Redwood are both very minimal right now when it comes to the back end. We don't provide many APIs or recommendations. It's pretty, kind of leaves a lot to the reader to figure out or the coder in this case. But we absolutely want to make this better. And we're going to get there. So there's the things that you need on the back end 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 NestJS, it's a very heavy back end 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. And but 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 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, where it's auto scaling, it 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. Lastly is mobile app integration into the full stack developer experience. Obviously 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 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'll 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, there, the first video there is, I think it's like an hour long video that goes in into all the key areas of Blitz, the key features, and shows you like how productive it can make you. So definitely check that out. 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. Okay. So some of 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 and 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 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 throwback 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 a production app. 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 like 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. Ooh, coming up. Super exciting. Next month. So that's really soon. And a follow up to that from R-Man, would we be talking about something that would be production ready for like a company with 200 engineers? Yeah. Yeah, for sure. Like, I mean, it's, yeah, that's what we're working towards. That's amazing. Yeah. It's aimed for, you know, 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 going to 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. I'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 mentality may diminish over time? And this is from jrock94. 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. 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 is, it's its own framework. So if you really like the experience from next.js, then choose Blitz. But if you don't, 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 techforeveryone. Is there any testing framework already available or pre-configured 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 like everything's already configured together. So 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 like 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 emphasize 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 five to 10 times more productive with Blitz than what they were before. And I think 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. 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 is attention, you know, 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 and like, you know, overall there's, we'll probably, 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 in that. But yeah, it's going to be, we're trying to make that balance the best we can. That convention versus configuration spectrum. Right. Cool. This one's from Radoslav. It's always fun saying people's like usernames out loud. How does Blitz abstract the api? What do we need to 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 like 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, server-side rendered, 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. Yeah. 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 on helping flesh out our backend patterns and APIs. Awesome. Awesome. I like to call them like the N-star-J-S libraries because it's like Nuxt, Next, and 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 five stars for Brandon's talk. And you can join Brandon in his discussion room, which is on full stack app development on spatial.chat. So thanks again, Brandon. Thanks again, Brandon.