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 29, 2013 when React was first announced at JSConf US. This means that next month React will be turning 8 years old. Doesn't that sound crazy? To me, React seems so much older than 8 years old, but it's only 8 years ago. We look back on this as a very significant event. Our careers are built around React. But at the time, React was not so well-received. It had a lot of haters and skeptics, and people were especially upset at JSX. In fact, there were entire codebases, like the Mozilla DevTools, Firefox DevTools, that were written, it was an entire React app written without JSX. So it was using, like, create element, and so forth. So we've come a long ways, to say the least.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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