Tom Preston-Werner
===

Noel: ~Test, test, check. One, two, test.~

Tom: ~Test, test, test, checking. Check, check.~[00:00:00] 

Noel: Hello and welcome to Pod Rocket, a podcast brought to you by Log Rocket. Log Rocket helps software teams improve user experience with session replay, error tracking, and product analytics. You can try it for free@logrocket.com. Today we're joined by Tom Preston Warner. ~Uh,~ Tom is the creator of Jekyll SemVer.

~Uh,~ the T in Tomal is his namesake. ~Um,~ he's the GitHub co-founder. Welcome back to the show, Tom.

Tom: Thanks. Great to be here again.

Noel: Yeah, and I'm super excited to chat today. ~Um,~ so your resume likely proceeds you to some extent, ~uh,~ but can you give us like a brief overview of where you've been, where you've been spending your time lately, and ~kind of~ what you're working on right now?

~Um.~

Tom: Sure. There's a couple of big things, so redwood js, which is mostly what I'm here to talk about. I've been spending a lot of time with the team on that as we try ~to,~ to build that into the modern web application framework. You wanna choose. For your next project. I also spend a lot of time, ~uh,~ doing angel investing.

So I invest in a lot of software development technology companies, as well as getting more into [00:01:00] climate technology, investing in ai, productivity tools, that kind of thing. So I spend a fair amount of time doing that. I also work with a organization, a think tank ~that we call, ~that my wife and I created called 1 28 Collective, where we do a lot of, ~uh,~ political and activism work around climate change.

And so that feeds into some of the technology investing I do as well. So those are ~kind of the,~ the three big buckets of what I work on.

Noel: Nice. Nice. Yeah. ~Um,~ we got into some of the, yeah, ~like~ the, ~um, Kind of~ nonprofit, ~uh,~ work and stuff in the last episode, but I wanna make sure we have enough time to talk about what's going on with Redwood right now. So I'm just gonna, I'm gonna jump right in. ~Um, yeah, yeah, yeah. So, um, there's, there's,~ you put up a blog post recently, ~uh,~ called Redwood Jss Next Epoch All in on React Server.

~Um,~ So that's why I wanna spend most of our time talking. But ~kind of~ before we do that, for maybe listeners that aren't super familiar with what Redwood is, can you give us the kind of quick overview in your own words of where Redwood ~kind of~ fits into the, ~um,~ framework space? How does it compare to things like, ~uh,~ remix or like ~kind of~ next JSS tooling stack?

~Um,~ like h how do you ~kind of ~position it.

Tom: Yeah, so we really [00:02:00] started Redwood js. As a dynamic web application framework. So ~we,~ we started with that angle, whereas in contrast to things like next, for instance, they really started from more of a static perspective. So they concentrate a lot on caching to get you the performance that you need.

Static site generation, that's ~kind of~ their roots, and of course they become more dynamic over time. We wanted to start somewhere where the assumption was you're building a web application. So something that's dynamic, something that maybe doesn't need to be fully indexed by a search engine, something that's an s p A.

So we have up till now had ~a,~ a single page architecture. A ~single,~ single page web app architecture, s p a. ~Um,~ and so we ~kind of~ came from that dynamic angle. And you see also remix comes at this problem of, ~uh,~ react based web app framework from a similar angle. So these are, I think, in response ~to,~ to next, and these are all great tools.

Like they just, they come from different places, they have different histories. They're optimized for [00:03:00] different things. So I'd say Redwood is probably a little more similar to remix than next, just based on what our overall sort of values are about what kind of app you're building. ~Um,~ but they're in that same space.

You might, if you're building a web app, you might choose next. You might choose remix, you might choose Redwood. These are all sort of the choices that you would be making. ~Um, but,~ but we come from, ~uh,~ an angle where we've thought about integration and long-term maintainability. The assumption being that you're going to be working towards building a large app.

So you're gonna wanna do testing, you're gonna wanna have separation of concerns on your front end and your back end. We use GraphQL for a react front end to talk to a GraphQL, a p i backend. For reasons of maintain long-term maintainability. Now we'll talk about why we're changing our TAC a little bit on and really going all in on react several components, but that's ~sort of~ how to think about redwood JS in that sector.

Noel: ~No, that, that's, that's perfect. Um, yeah, and I guess let's, let's keep going. You kind of mentioned it there. Uh, like~ last time you were on the show, ~you were,~ you were talking to us about, ~uh, kind of~ the. The [00:04:00] decoupling that like draft QL provides, ~like~ we've had this history where big frameworks would always kind of be opinionated ~and,~ and, ~uh,~ obfuscate away the request layer away from the developer.

So ~like,~ devs wouldn't, you wouldn't have to think about this cuz ~there is,~ there is some overhead. Like doing that kind of request response pipe, that to the front end work. ~Um,~ but I think that there are a lot of compromises made when that is just all being handled, ~which,~ which we touched on before. ~Um,~ and now ~in this,~ in this, ~uh,~ blog post and ~kind of~ with some of the direction that we're going with server side rendering, ~um,~ this kind of, as an industry at large, I feel like we're ~kind of the,~ the relationship there is a little bit murky again.

Have you felt that there, ~that~ that kind of SSR is. Antithetical conceptually to that ~like ~decoupling that we had for a long time of ~kind of~ like gats, BJs, and API layer and that front end rendering layer,

Tom: ~Well,~ this is classic in the. Technology industry, and especially in software development, is that people joke that, ~you know, we~ we're just reinventing like what the web used to be, right? ~Like,~ oh, you have a request and the server generates a response and sends it to the client, right? And they're like, oh, we're just, we reinvented P h P, [00:05:00] right?

~Like~ that's the classic joke. ~You can, you can,~ you can apply that joke to like almost every technology that we've ever created, right? Someone comes up with some new sort of system and they're like, oh, you just reinvented, ~you know,~ public transportation,

Noel: Right. Right.

Tom: like, oh, that's, you just, you invented buses, right?

You're like, well, kind of. Kind of. Yes, but also kind of, no. The best way I've heard this explained is that people think that this is like a cycle. It's~ like,~ oh, we have ~static site gener, you know,~ static generation on the server. And then~ we created, you know, then~ we have php and now we're doing, ~uh,~ we're doing dynamic things.

And then, ~you know,~ I created Jekyll a bunch of years ago, and then it was like, oh, ~you know,~ we, like, we got dynamic and now we're getting static again. It's like, oh, ~you know,~ people said this with Jekyll too. It's like, oh wow, you reinvented like Apache serving directories of content.

Noel: Yeah.

Tom: And it's like, well, yes, kind of, but I added something to it.

There's a layer here ~of,~ of, ~uh,~ there's a build step. Like it's doing more than that. Yes. It's taking things that we used to do dynamically and saying maybe they don't need to be done real time every time. ~Right.~ Like that you have better security, better performance when you don't [00:06:00] do that, but you're still able to do a lot of the things that you could do.

So yes, it's a reinvention of things that we were doing before, but with something added. And so you can think that this cycle looks like. A circle, but really it's a spiral in kind of a 3D space, like a slinky. And as you go around in that cycle, you're also going up, so you're adding layers, you're adding capabilities, you're adding complexities, you're able to solve more problems.

And sometimes, ~you know,~ things get messy and it's not like this perfect, beautiful spiral, but I think that's really the reality is that, yes, we go back and forth because oftentimes there is no. There is no clear cut winning strategy, right? Like we have these separations of front ends and back ends essentially because of the speed of light.

If the speed of light was infinite, then it kind of wouldn't matter. You could do anything anywhere and it would just be like where, ~you know,~ do you have enough compute on your client to do it? It's because we have time to transfer data across space that you end up having to care [00:07:00] about things like a server rendering versus a client rendering, ~I mean,~ as one of many concerns.

But that I think ~is,~ is one of the biggest ones, like where. Where are you willing to do your compute now? Because if you can do that on your client in Sspa, you can get, ~uh, the,~ the kind of performance that you would never get in a traditional server rendered application just because of the time it takes to transfer bytes across an internet connection.

Noel: Okay.

Tom: And so now you're faced with that choice. You have to choose, you wanna do this on the server and then send it over. Do you wanna send over smaller amounts of data and do it on the client and maybe have the client be able to do things dedicated just on the client for performance reasons? And so we now have to make those choices, right?

So ~it it,~ there is no perfect solution. Doing everything on the server is not perfect. Doing everything on the client is not perfect. There is some combination of these two things and related all the related problems around them that is gonna look like optimal eventually. And so we're searching for what that [00:08:00] is and as our technologies.

The technologies that are available, ~sort of ~the building blocks that are out there. As we get more of those, people will assemble them in different ways that have different trade-offs, and it'll look like it's going around and around and back and forth forever and ever. But we're still solving these problems.

And so this latest one is, Hey, s SPS have these problems. ~Like~ there's SEO issues. How do ~you, you know,~ do OG tags? What's performance like? ~Um,~ all these different things, right? That people say that, that are the weaknesses of s spas. And I agree. So that is where a solution like React Server components becomes this hybrid solution where it's still React, but now React has more powers.

Or they're reaching into kind of the server space that they haven't really reached into before, and you're like, oh, that is a really elegant solution to some of the problems that we've been seeing with Redwood. Where people don't wanna operate solely behind a login, right? Like people need OG tags, people need better performance in seo.

And so where Redwood has really shined so far [00:09:00] has been in your logged in app kind of world. But people then, ~uh,~ for public facing things need to reach out for next. And we prefer that you be able to use Redwood for your sort of public facing front end and your backend and do your OG tags and get your s E O performance.

~And,~ and just your overall speed of ~your,~ your pages and responses and et cetera, et cetera. GraphQL is a burden for some people coming on board so we can get more into those, ~uh,~ issues, but that's kinda how I see it.

Noel: Yeah. No, ~that's,~ that's a good breakdown. I guess~ I'm,~ I'm curious if you share this opinion. ~I,~ I feel like a lot of the kind of push towards s p A and doing everything in the client side, a lot of that, I don't know if it was consciously done, but I think a lot of the weight, there was just ~the,~ the dev experience was so much nicer at the time.

It was so much more responsive and snapping. You could like just iterate so much quicker. ~Do you feel, I guess,~ do you feel that that's true? And if so, do you feel like we're finally at a point with React server components where that, ~um,~ like the kind of the pain point that was alleviated slightly, there is ~not,~ not so much a thing any longer.

Tom: ~Yeah, I think that was,~ I think that was part of it though, [00:10:00] maybe not the biggest part. I think for a lot of people it was just the performance that you could get on the client where you're building an app. ~Like~ let's say you're building a music app, something like Spotify. ~Like~ doing that with a server architecture, like where every click has to go back and forth, like it feels very not native.

And I think their challenge was how do we make a web based client feel like a native app and the way that you really get to that kind of instant performance. Is through doing a lot of stuff on the client, right? So~ that kind of,~ that kind of capability. And then, ~you know,~ certain people started doing that and then it's like, oh wow.

Like you can get that kind of responsiveness. In a web app, like that's unbelievable. And so ~everyone,~ everyone tries it out and it's like, oh, ~let's,~ let's do this like this architecture's really cool. We'll have the client and hey, now we're paying less for servers. Maybe because the client is doing more of ~the~ the compute, and that's desirable.

But oh wait, there's downsides because now we have certain requirements of [00:11:00] running a lot of JavaScript. And oh, by the way, we're transferring a huge amount of JavaScript over the wire every time. And you have to download these bundles and. ~Right.~ So it's like every innovation, every new innovation comes with its own baggage. So this is going up the spiral. It's like, oh, you took a step up that spiral, but then you realized it wasn't perfect, and now you have to deal with your baggage, right? And that baggage eventually gets so heavy that someone comes along and is like, man, that baggage is terrible. Let's throw all that ga that that baggage away, and do this one change and take this one step up.

And everyone's like, whoa, that's amazing. Right? Until they start weighing their baggage again. So I think we'll see. We'll see. ~You know,~ you always see this. You will forever see this. So with React server components, guess what? There's gonna be baggage. We will discover what that baggage is. We think overall we'll be higher up on the staircase, but our baggage is different and we're gonna have to deal with that, and there will always be a next step after that.

So really ~it's,~ it's just the process of. Technology like, ~like~ that's what we're doing. Like we're building. [00:12:00] Every time you build in the software world, you deal with constraints. You come up with solutions. Your solutions have drawbacks, and you're just trying to chip away and always get better.

Noel: ~Gotcha. Yeah,~ I feel like ~this, the, the,~ the way in which you're talking about this ~is,~ is very, ~um,~ Kind of strategic and ~almost~ almost philosophical in nature. ~Do you,~ do you think that you spend a lot of your time, like ~kind of~ thinking about the correct heading for ~the, these,~ these projects long term, like the correct decisions, ~uh,~ for Redwood itself versus ~like, um, you know,~ specific technical implementations or ~like what,~ what tools to choose specifically?

Tom: Yeah, absolutely. ~You know,~ we have a team, we have a core team of eight people or so, now, eight to 10 people that are. That are active in a mostly full-time capacity. And my role in that is really from a high level design, ~sort of~ what does the public a p I look like. So those are matters that I concern myself with a lot.

She's like, are we gonna, if we're gonna make breaking changes, what are those gonna look like? How do we name things? ~How does,~ how does the public api, so what people are typing to interact with Redwood as you're building a Redwood [00:13:00] application. Those things matter to me a lot, that design, that experience, that developer experience of the framework itself, as well as just overall strategic decision making for the framework.

So as React server components becomes more prominent and the React team is evangelizing that more and more. And you see other frameworks like Next come out with their sort of implementation of that and looking at the set of challenges that Redwood has for adoption for people. ~You know,~ like what gets in people's way?

Why do people choose redwood? ~Why do they choose not,~ why do they not choose redwood? As we try to answer all of those questions, that's where I really try to come in and think holistically about the whole landscape of. Products out there that people can choose, and where Redwood should fit into that landscape and then making those high level decisions.

That's sort of my role. I don't really write much code for Redwood anymore. I did ~in the,~ in the early days, I wrote a lot of it. But ~my, my role is~ I'm better leveraged higher [00:14:00] up ~in the,~ in the sort of decision making stack. And I have a lot of other things that I'm, that divide my attention. So ~it's,~ it's better for me to not be a blocker at this stage of the project.

So I come in more from a leadership perspective.

Noel: ~Yeah. No, that makes sense. So I guess, yeah, let's get into,~ let's get into specifics a little bit then. So I guess ~kind of what,~ what led you guys to, ~uh,~ react server components specifically? How did that feel or what made that feel like the right decision? ~Um, and,~ and how involved personally were you in that versus exploring kind of ~the other,~ the other options in that space?

Tom: ~Uh,~ it's become pretty clear that the React team thinks React server components are the future. ~They spend a lot of their time. I mean,~ this is a complex technology. They spend a lot of time thinking about it, making sure it solves the problems that they're trying to solve, that they see in the ecosystem.

Like how can they solve some of these problems that they see with React apps, right? These sort of S P A problems and the challenges of doing server, rendering of react and hydration, and how does all this stuff work and fit together? And it's getting really complicated and. So the React team says ~like,~ what is the next phase of React?

What do they need [00:15:00] to solve? And so this became a very big experimental thing for them to do, and now they're really trying to make it real. And that over the last year or so has become really obvious ~that this is,~ that they've decided to do this React server components used to just be like, Hey, this is a weird thing that we might do.

Noel: Yeah.

Tom: And things like suspense, right? These things are all now coming together to create. ~This, ~this cohesive vision of theirs to where React is no longer just a client technology. It really is a first class server technology as well. And then what does that mean, right? If you're rendering React on the server, which people have been doing for a long time anyway.

Okay. How do they come in and make that better, right? ~Like~ take what people are already trying to do and come up with a better solution to make that easier. So that's React server components. So we've been examining this for quite a while and ~it,~ it ~kind of~ started with ~the,~ the desire to do server, some kind of service side rendering in Redwood,

Noel: Right.

Tom: which is a big change for Redwood because the architecture was originally designed to work in [00:16:00] serverless environments like Netlify and Vercel really ~Well.~

That was like, that was ~the,~ the original reason that Redwood existed was cuz I wanted a way to build full. Stack web applications and deploy them to Netlify and have them be just as good and first class as like a rails app would be.

Noel: ~Mm-hmm.~

Tom: Now that's the sort of distant past. We don't really think about that anymore, but ~that's,~ that's why the architecture of redwood looks the way that it does, because it wanted ~a, a,~ a front end that you could deliver via A C D N, and it wanted a backend that could be an a p i and then your statically delivered front end could talk via some protocol to your backend.

We chose GraphQL, so this is why Redwood is the way it is. but there are certain challenges with that, that anyone that has ever built an s p a knows, which are things like, wow, I, I have to send a lot of JavaScript over the wire. It would be nicer to have some,~ you know,~ my app be able to work without JavaScript, or at least, ~you know,~ most work so that people could at least render like the initial page.

That would be nice, right? And have ~that,~ that page still be able to be, ~um,~ somewhat dynamic. ~So,~ The biggest thing that we were exploring was how do we do ssr? [00:17:00] And so the problem we started with was how do we do OG tags essentially, and seo, which kind of are, they end up being the same thing. You just need to be able to deliver an H T ML page.

Where an SSPA is gonna deliver an HTML page, but it has nothing on it, but a place for react to mount to right? And so there's no, you don't get much there that the search engines are gonna care about until they run JavaScript and you're not able to do OG tags. You have to layer on some kind of clever solution to do OG tags and get unfurling on Twitter or Facebook, slack, et cetera. People have done that with Redwood, but it requires using edge functions or other sort of creative workarounds to make that happen. So we're like, how can we do server-side rendering and what does that look like in a redwood context? So that's where the exploration started. And then one of our team members, Jan, ~uh,~ Danny Chowdhury, has been exploring that for quite a while.

And it started with ~like,~ oh, Webpac is gonna make this challenging. So let's also think about changing to use [00:18:00] VT as our bundler, which we're ~very,~ very close to, to actually rolling out so ~that~ that work is almost done. But, so that made it take a little bit longer than, ~you know,~ it's like, it's, it's the, it's the classic yak shaving problem.

~It's like,~ oh, let's do ssr. Oh, but in order to do that, we have to also switch to V And you're like, oh, snap. That's gonna be hard.

Noel: Right.

Tom: ~Uh,~ and it was hard, but it's almost done. It's basically done. It's about to ship in the next version, ~so,~ which is gonna mean way faster development kind of feedback cycles. It's just, ~it, ~it spins up faster.

It's just, it's better, right? This is the modern solution we had to change to it, to, to stay modern and for speed reasons, et

Noel: Mm-hmm.

Tom: So then it was like, okay, ~well~ we have, if we have vi then we also probably wanna look into the streaming stuff that React now has, because there are advantages to having ~the,~ the thing be streamable if we're gonna have a front-end server anyway, like now we can do streaming and to do a, to deliver an HTML page, you basically have to have a server or something that looks like a server.

~So, okay,~ so now we have a server. We're gonna use VT for bundling [00:19:00] and integrate that with the React streaming stuff. And implement suspense. So ~this is like,~ this is everything that has to go into, to basically do SSR when you come from a sort of purely s p a perspective, right? It's a lot to do. ~Um,~ and then from that point, then it's like, okay,~ well~ we could do a loader style data fetch, right?

Because now your data fetching ~is,~ is different, right? You don't have to use,~ like,~ you're not necessarily using GraphQL to do this. You basically just have a function that runs server side and can ~like,~ Fetch your data or whatever, and that looks a lot more like next or remix. And so we're thinking like we think GraphQL is, ~uh,~ is friction for people who are experimenting.

And so our best segment for Redwood users right now ~is,~ is startups. And that's where ~our,~ our marketing messages are mostly aligned to our startups, right? People, like most of our users ~are,~ are actual like companies, startups that use redwood and build on it. Because they are looking forward and wanting that kind of maintainability and they're thinking about adding like a mobile client [00:20:00] already, ~you know,~ from the get go.

And ~you know,~ they know they're gonna be doing testing and they're gonna be building their team. And so having all of these things that Redwood has always thought about. Is really advantageous and appealing for that group. But for people that are just doing a weekend project, maybe not so much, right?

Like having to define your SDL and get all your resolvers written. Even though redwood js makes that easier than anywhere else you'll ever build a GraphQL a p i, we make it way easier. It's still more that you have to do versus next where you're like, Hey, just fetch data in this function that's right next to your page and ta-da, you're done.

~Right? Like,~ that's easier. And so people choose next for prototyping. But then I think people stick with next because that's where they already are, right? You just keep building. You're not gonna ~like~ go tear, ~you know,~ rebuild in Redwood at that point. You're probably just gonna keep going with Next. And ~you know,~ next has been around for a long time.

It's a mature piece of software, so that's a totally reasonable choice. We want Redwood to be able to solve the same problems, but we need people to be able to start with Redwood. And so this plays into these [00:21:00] decisions as well, which is can we remove GraphQL as. A blocker and make it optional. Still make it first class because we still love GraphQL and it solves a certain set of problems extremely well, better than anything else,

Noel: Mm-hmm.

Tom: but it does not solve the experimentation problem or the prototyping problem.

~Um,~ and so ~can we use, uh,~ can we use a React server components model to avoid people having to use GraphQL, but still allowing them to add GraphQL as the, as a query mechanism later on. For third party clients, like a mobile app or something that would want to consume a GraphQL api. So these are all of the kinds of things that we're thinking about that are going into this choice.

Then ~it's like,~ do we use a loader pattern like, ~uh,~ next, where it's basically just ~you,~ you load all your data up front and then you ~sort of~ hand it to your page. That's ~the,~ the old next stuff. ~The um,~ The what? ~Whatever,~ whatever, ~you know,~ the pre RSC stuff. So ~that's,~ that's what people have been doing for years and years.

And remix looks the same. It's like, here's a function, run it, here's your data loader. ~Like~ get your data, pass your [00:22:00] page, you're done. It's very easy. ~Right?~ Very easy to think about. Very simple. ~Um, and then,~ and then the other hand, you've got react server components which are more complicated and solve the problem in ~kind of~ a different way where you can ~kind of~ split it up where you're doing more like.

What we do with redwood js cells. So a redwood jsl is, ~uh,~ is basically a react component that is going to do its own data fetching.

Noel: Gotcha.

Tom: how we think about it, right? So you might have a bunch of components doing client side data fetching to the GraphQL backend to get their data and then render themselves.

So react server components actually are a better match for that paradigm where you can split up your data fetching ~into,~ into multiple places versus a loader pattern where you're mostly just doing it in upfront. You do it all up front, you get all your data, and then you just pass it into your top level component and you go from there for the most part.

So we're thinking about these two different choices and ~kind of ~weighing them and being like, ~well, you know,~ data loaders are simpler and people are really used to them, but React server components is, ~you know,~ more nuanced and ~kind of~ matches a little bit better. What we were [00:23:00] working on already with cells and react is obviously going that direction. It's a modern new technology that everybody's excited about, and we could have a bigger hand in defining what the future of React server components is by participating early on in that process. So ~these are,~ these are the things we're thinking about.

Noel: Yeah. Yeah, that makes a lot of sense. I guess ~I'm, I'm,~ I'm curious, ~so,~ so you talk about how ~there's,~ there's ~kind of a,~ a trade off there, ~um,~ in, in, in like not having the. GraphQL api, always present. Did you guys consider like having the, ~uh,~ cells, I think is the term, like still fetch data via a GraphQL API that's ~like~ established for your data model and having even like the server render~ kind of~ consuming data from a GraphQL API that's created?

I'm thinking something analogous to like Gatsby, like that's how Gatsby builds kind of work. Did you guys explore that at all or did that just seem like a unnecessary abstraction that wouldn't really add any utility?

Tom: ~Well,~ I think so I'm thinking about. How, what is the story for people that are building [00:24:00] with Redwood so that they can come in and say, okay, I can use React server components and my data fetching is really easy and I can just, I have this function that goes along with this server component. It's gonna grab whatever data it needs from whatever data source, be that via Prisma, which is what, ~you know,~ we build in to make your life really easy.

We assume you're gonna have a database, a local database, ~you know,~ some database that you're accessing that has most of your data in it. ~Um, And,~ and then that's how you get ~your,~ your data or how do you go from there? So if you're starting there, cuz that's easy,

Noel: Mm-hmm.

Tom: then at some point you come along ~and,~ and the, ~you know,~ the biggest use case that we see is people have a mobile client or they might have a terminal application or something.

They've got some kind of third party, ~some,~ some third client. Or I guess second client, right? Like a, ~you know,~ a mobile app, a kiosk, whatever, ~uh,~ it could be that needs to consume data from your application. Now, if you're building in something that has a transparent a p i, then you're like, oh, now I [00:25:00] have to build another a p I.

Because you never explicitly built an api, which made it easy to build your web app, but now it makes it hard to have to create ~your,~ your new API to feed that. So I'd love to have a story where when you get to the point where you need that kind of api, we make it really easy for you to create a GraphQL API using the technology that we've always had, that we started with, which it means it's really robust, it's really mature.

To build a GraphQL API with Redwood at the point that you then build your GraphQL api, let's make it really easy for you to consume that GraphQL API from your React server components so that maybe you don't go back and re-implement all the stuff that you've already implemented. But now you front end developers, cuz you've probably got specialized teams at that point,

Noel: Right.

Tom: So you've got front end developers who love GraphQL because it's really easy to query. Very flexible. You've got specialized GraphQL people because GraphQL APIs are a bit tricky to do well, and so if you have a specialized API [00:26:00] team that's building your GraphQL API and you've got frontend developers that really enjoy consuming GraphQL, that becomes the best API that you could have.

Way better than querying the DA, the database directly, because you can put a layer of intelligence and security on that api. That keeps everyone safe and makes everyone happy and have to think about less than if you're in Prisma and you're just reaching directly into your database and you're like, I don't know, it's a little sketchy, right?

~Like,~ I'm not, I don't spend my whole day thinking about data integrity as a front-end developer probably.

Noel: Mm-hmm.

Tom: and so I have to think a lot about how I'm querying data and what's gonna be performant ~and,~ and all of those things. So having that level of abstraction gets you a lot when you have.

Specialization and teams of people. So making that a first class way that you can query your data, get your data in your React server components as well as client components because yeah, like you can deliver most of your content via React server components, but you're still gonna eventually have [00:27:00] some components server side that probably want to do direct data fetching to your backend.

And maybe you wanna do that in GraphQL, cuz that is still gonna be a really nice way to fetch data on the occasions that you need. To be able to do that. So this is the story that we're working on now ~and,~ and how to make it really make sense.

Noel: Yeah. No, ~I, I, I,~ I think it is tricky and ~it,~ it, again, it seems like ~you've,~ you've spent a lot of time thinking about this and ~like~ trying to make it easy for people to kinda, ~um, you know,~ Not go astray as like ~their,~ their app grows in, in, in need and complexity. ~Um,~ but ~it does,~ it does still seem like that ~this,~ this is an increase in complexity overall that like we're just ~kind of~ admitting that we have to, one has to take on at some point.

~Um,~ did you feel at all, I don't know. ~Um, Like,~ like it was ~kind of leaving,~ leaving the history of what Redwood was before, ~kind of~ as a JAMstack first kind of best in class for all these tools thing and make it,~ you know,~ do all this or did, do you think it's like an inevitability, ~uh,~ that kind of had to happen?

Ats some point,

Tom: ~Um,~ I think, ~well,~ it's not inevitable, but reality is what reality is. I think we're reacting to what we [00:28:00] see. There are ~alternate,~ alternate universes where things went differently, perhaps, right? Depending on what the market saw or where in the life cycle things happened to be. The whole collection of technologies that were out there.

So all we can really do is build something that we think is useful, put it out there, and then react to what actually happens in the world. And so that's what we're doing. We're reacting to where we think ~the,~ the friction is for people to pick up redwood and especially early on. So what's weird is that ~we,~ we started upmarket, essentially we did this weird thing where we're like, we're gonna create this really sophisticated, highly integrated, ~Uh,~ web application framework that does all of these things.

They're just designed around maintainability and ~like,~ you're gonna have big teams ~and,~ and stuff, and it's gonna have some complexities because of that, but that's gonna really be good for you in the long run. And so we have companies that are ~kind of ~that using it, but it's upmarket. It's ~like, you know,~ Next is the downmarket.

Next. Next is like the every, the everybody framework. It's like, whoa, this is so easy. I can just [00:29:00] bust something out in two hours and look, I've got this reactive website and this is awesome and this is what I'm gonna use for my hackathons, and it's so cool.

Noel: Mm-hmm.

Tom: And then redwood's ~like,~ yeah, but we've got like a million things that we've integrated, right?

So we spent a lot of time doing that. So we built ~this,~ this almost like enterprise solution first, and now we're looking to open up the downmarket. So how can we better serve people ~that are,~ that are, that want a modern react experience? But are seeing themselves want to build for the long term. Cause I think ~that~ that solution doesn't currently exist.

You've got some things that are easy to experiment with, but they're gonna maybe be a little more challenging as you grow as, cuz you're gonna be doing everything yourself, all of your integration, ~you know,~ like everything is ~sort of~ left up to you to assemble your pieces, which is ~kind of~ the JavaScript way, which is also can be ~a,~ a headwind, which is like people just ~kind of~ assume ~that~ that's how their lives are gonna be.

Coming from a rails background, I. I don't see that life has to be that way. I think there is a better way that we can create conventions and integrations from the beginning ~that,~ that allow you to move way, way faster. ~Um,~ but we are, [00:30:00] we're upmarket and we wanna move downmarket. Next is downmarket. And they have been ~sort of~ going more upmarket and react server components is really, is like ~a,~ a big step ~sort of~ going upmarket and saying, look, you can do way more interesting complex things now server side and client side, and.

And that's where React is going. ~So,~ so we're ~kind of~ going opposite directions. Next is going up market, we're going down market.

Noel: Right.

Tom: ~Um,~ and I think that's cool. ~Like,~ it's cool to see people exploring the territory because there's, there needs to be more and better solutions always.

Noel: Yeah.

Tom: so that's, ~um,~ that's where we're, that's where we're at now.

Noel: Yeah. Okay. I'm gonna ask you ~kind of~ a tough one then on the heels of that. ~So, yeah, like,~ like you said, the, these more, more kind of robust and featureful frameworks with more opinions. I, I understand why. ~I mean,~ as a dev, ~like,~ there's a lot of times where ~I,~ I don't want to jump in on one of those, on some little side project, especially when I don't think it's going to have legs, but~ like,~ maybe it will, ~like,~ I never know which one will be the one that kind of takes off and I've gotta, it ends up blossoming how.

How, like, how would you recommend people think [00:31:00] about that decision? Like ~how, how do you,~ how do you know when ~to,~ to spend a little bit more time upfront and go in on something like Redwood?

Tom: I think ~you do your,~ you do your evaluation and you really look at a lot of things, not just the technology itself, but also documentation and especially the community, and how involved is the community. How robust is the community? How engaged are they? Are you able to get your questions answered? Are you able to find things in the documentation?

What does the leadership look like? Does it look like. They're committed to it. How long has it been around, ~you know,~ Redwood's been around now for three years,

Noel: Yeah.

Tom: so ~what, where, what are,~ what are the answers to those things? Can you bet on it safely? I.

Noel: ~Mm-hmm.~

Tom: And of course, nothing is ever totally safe. These things are all, ~you know,~ most of these things ~are,~ are open source probably that you're evaluating.

So like worst case scenario, ~you've, you've, you know,~ you're not gonna be completely cut off, but you wanna choose something that's gonna continue to grow and evolve with ~the,~ the industry and improve the ways that you want it to. So people will do technology evaluations, and I think that's the right [00:32:00] way to do it.

You say, all right, ~well,~ what do we need? What are the characteristics of what we're building? ~Like is it, you know,~ does it need a big realtime component? What kind of performance does it need? What kinds of devices does it need to run on

Noel: ~Mm-hmm.~

Tom: Cetera, et cetera. Where's where, how much data do we have? Where does compute need to happen because of operations on the compute?

Like all of these different constraints that you might have based on what you're building. Different technologies are gonna serve that better or worse. Or you're going to say, if this is successful, how much time are we willing to spend choosing and integrating things? Or would it be nice to have some of those things done in advance?

And if there is ~a,~ a more integrated solution, something like redwood js, do you agree with the technology decisions that we've made? Cuz if you don't, if you're like, we will never use GraphQL cause I hate GraphQL, right? Then maybe that, maybe Redwood's not. For you, but maybe it will be once you don't have to use GraphQL.

Noel: ~Hmm.~

Tom: ~Um,~ again, ~we, you know,~ we want to be able to serve as many people as we can that are building web applications [00:33:00] and wanna do it in JavaScript or type script. And so we're trying ~to,~ to open that up. But ~it's,~ it's a technology evaluation and it's always a little bit ~of a,~ of a leap of faith for something that does feel more nascent.

Noel: Yeah.

Tom: ~And, you know, and,~ and ~this is,~ this is why things, ~I mean,~ there's a lot of choices in the front end. Market right beyond even just React. ~So, you know, we've,~ we've really have decided to ~kind of~ stick with React as well. In the beginning of Redwood, I always thought it would be cool if we had multiple front end sides so that you could be like, oh, ~well there's a React.~

You could build a React web app, but because it's a GraphQL API backend, you could also build a view front end or a Sphe front end, and those would all just talk GraphQL to a backend ~and,~ and you could have any front end technologies that you wanted.

Noel: ~Mm-hmm.~

Tom: It turns out building like seven frameworks is harder than building just one.

So

Noel: Yeah.

Tom: this is part of our problem ~is,~ is the ambition to ~sort of~ do all of these things that, that nobody else is doing. Like it's, ~I~ I sometimes envy next for being like, you know what you worry about. What your database looks like and you worry about testing and [00:34:00] you worry about, you know, if you're gonna use storybook or not.

~Right?~ We take a lot of that on and make it work, but they're just like, I don't know you, you be you and do your own thing. And ~they can,~ they can spend a lot more time focusing on their sort of core. Bit of technology, ~um,~ because they're, the value is just a l is just different, right? They're focusing on a different kind of set ~of,~ of values, but it's, ~uh,~ yeah, it's a lot of work.

When we started this, ~uh,~ I'd always wanted to create a web framework, and ~that's,~ that's also part of the reason that Redwood exists. It turns out building a web framework is hard. I don't know if you knew that, but, ~uh,~

Noel: I, I believe it. ~I've never done it.~

Tom: ~it's a lot of work.~

Noel: yeah. Yeah. I imagine so.~ I guess I am, I'm curious.~ I feel like that kind of,~ uh, I don't know,~ modularity, the composability ~of,~ of the web ~is,~ is something that a lot of devs, ~you know, like, and kind of~ look for. ~Like I, I, you know, like they, they, they, ~some would say they don't feel they need anything more.

I. Then like an xjs. Cause ~they wanna,~ they wanna do that ~like~ cobbling together and making the pieces work. But I think like it's also very fair to argue that there is again, ~like~ a lot of overhead there. There's a lot of stuff you're worrying about then that people have worried about a thousand times over million times over.

~Um, So like, is there kinda, kinda when you,~ when you set out and ~like,~ were ~kind of~ saying that there, there should be entities that are taking on [00:35:00] this kind of as conceptually, like ~kind of ~putting the pieces together and making it all just work. Batteries included a little bit more.~ Um,~ Do you feel like there's anything ~kind of, uh,~ lost in that?

Like cobbling ~in~ in the kind of modularity just of pieces? Or do you think that we can still have like ~kind of~ open web open tools? Everything can talk nicely, but there can still be a layer on top of that that makes it easy for new people to come in and ~kind of~ not make, ~you know, the,~ the same mistake that hundreds of others have made.

Tom: Yeah, the well things go through the cycles. Again, this is ~sort of~ about cycles. It's like you have. A period ~in,~ in languages ~kind of~ early in language is usually where you have a lot of experimentation and everyone's creating solutions to everything. Just exploring the territory and then at some point people become fatigued by that because there's too much choice.

It's like, how can I possibly choose between these 73 different state management

Noel: Yeah. Yeah.

Tom: ~I, like, I can't, like they're all, you know,~ a lot of them are really good and, ~you know,~ people ~like,~ like to use them in for different reasons and yeah. Eventually a lot of people's decisions just come down to what ends up being most [00:36:00] popular for whatever reason. And then, ~you know,~ and then once this fatigue becomes so great that you can almost not deal with it anymore, then you see people start to do integrations. ~So,~ so then it's like, okay, let's pick a few of these cuz they're, ~you know,~ we could pick any of these seven choices and they would all be fine. They would all be great.

They would all get~ the,~ the problem done. So let's reduce ~the,~ the choice fatigue by making some good selections. Probably also based on what's popular, what people are using and being successful with, and then making sure that they work really well together. Because at the end of the day, most people building web apps. Care more about getting their app built and providing value to their customers or users. Then they care about the sort of esoteric choices of bleeding edge technologies.

Noel: ~Yeah. Yeah, I think that~

Tom: ~where, that's,~ that's where we, that's the phase that I think we're in a little bit. And of course, I~ mean,~ the experimentation will always continue.

~You, you'll,~ you'll never stop that. But we are seeing, I think, a little bit [00:37:00] of consolidation. And that's really specifically what Redwood is trying to do, is to say, let's make some intelligent choices of things that are gonna work well together to let you get the job done that you wanna get done.

Noel: ~Yeah, so I guess, yeah. So do you feel that then to kind of circle us back around here, the, the, I guess the blog post was titled Redwood J's Next Epoch. Like do you kind,~ do you ~kind of~ feel that now with. With, ~uh,~ react server components we're kind of, I guess,~ um,~ redwood J'S choices that it's making for the user are ~kind of~ changing, like to adapt to what users have been asking for.

Tom: Yeah, absolutely. ~I mean,~ that's the whole, that's the whole reason. The whole reason was people need ssr, so let's implement ssr. And that led us to a series of choices that then made us choose between doing a data loaded pattern or use React server components, cuz it ~kind of~ doesn't make sense to do both.

And so we sat there and we thought about it and we chose React server components because we think ~that~ that's the future of React. And so we want to go where Reacts going and also it solves the problems that we have in a pretty elegant manner.

Noel: Cool. Yeah. I guess last time you were on, you talked too about, ~um,~ like releasing frequently, ~kind of, you know, as a,~ as a siver [00:38:00] pro, I would say. ~You, you were,~ you were discussing,~ uh, yeah, like have,~ don't be afraid of the kinda the major, uh, Version updates, ~like~ send 'em out, let people integrate quickly. ~Um,~ do you feel you've been able to do that with, as fundamental a change, ~uh,~ as this, ~um,~ Bighorn is ~for,~ for Redwood here.

Tom: Yeah, so Bighorn is what we're calling the next epoch. So we're currently on Arapahoe. That's where we currently are. We name our epoch after, ~uh,~ national forests.

Noel: very cool.

Tom: ~cuz Redwood.~

Noel: ~Yeah. Nice.~

Tom: ~Um,~ so yeah, we're, I mean ~we're,~ we're gonna release version six pretty soon, so we're already through ~a,~ a number of major versions more than you would generally see from ~a,~ a framework of this size.

And the reason is we want to be very explicit and correct in our use of semantic versioning so that when we make a breaking change anywhere in what we consider the public a p i, which is quite broad that you know about it.

Noel: Hmm.

Tom: And so~ we,~ we use the epoch as the big sort of marketing part where most people use the major version to be like, Ooh, version, ~you know,~ seven, check it out.

~Right?~ We're like, oh, version four, like whatever. It's just, we broke something, but~ like,~ it's not a giant change to our architecture, [00:39:00] so this will be a giant change to our architecture. Moving to RSCs and having service side rendering. ~That~ that is, that's big, right? And so ~we're,~ we're arranging our marketing around the epoch, which we'll call Bighorn.

~So, you know,~ another part of this, of releasing major versions every few months is that we have to make it easy for you to upgrade to those versions. So we spend a lot of time writing code mods and really exhaustive upgrade docs, and you can go check them out for old versions of Redwood if you wanna see what they're like.

But we spend a lot of time thinking about and creating an upgrade process that is gonna be really smooth.

Noel: ~Nice. Nice. Awesome. Well, I guess,~ yeah, ~kind of to, uh,~ to wrap things up a little bit here, ~what's,~ what's on the roadmap? What's ~kind of~ going on in the near future? ~Uh,~ in the redwood js world?

Tom: ~Uh, well~ besides ~the,~ the big thing of React server components, we've got~ some,~ some cool things. We've got some real time GraphQL stuff that we're working on. So that you can do subscriptions ~and,~ and live query types of things with GraphQL a couple different ways that you could do real time, which as we get more into a server centric server full first [00:40:00] approach, these things become simpler.

~Uh,~ having a front end server turns out to, to make a lot of things easier. So ~that's,~ that's nice. So real time GraphQL stuff is coming. And we also have something really cool called Redwood Studio. Open Telemetry support ~kind of~ goes along with that. So we're instrumenting the whole framework with open telemetry and then creating a visualization of that, a visualization tool that will be part of Redwood Studio.

And Redwood Studio will be multiple things. This is just one of them to be able to let you go in and do tracing of performance. ~Um,~ And timings of things in your app as you develop and then even after, ~as you~ as you are in production, having all of that sort of built in for free to say ~like,~ what were your SQL queries?

Do you wanna see, ~you know, this is,~ this is kind of your standard data observability, but bringing it in via the framework and making it available during development in a first class way. That's part of what Redwood Studio will do as well as, A better GraphQL playground, ~uh, and,~ and some other things that we're imagining putting in there.

So work has been [00:41:00] going really well on that. And ~there's, there's,~ there's all kinds of stuff. We have a roadmap that you can find. It's linked from my blog post. Maybe you can add ~a link,~ a link to my,

Noel: Yeah.

Tom: blog post. But there, ~and,~ and to this roadmap. But there's a notion document that we keep now with progress on our roadmap and you can see more of the things that are on our roadmap there.

Noel: Nice. Nice. Very cool. ~Um, how about kind of outside of the code world?~ I have a note that you guys are doing ~your first,~ your first conference, right?

Tom: That's right. So our very first in-person big conference is going to be in September, September 26th through 29 in southern Oregon. So we have a partner that we work with called Zeal, ~um,~ that is a consultancy and they have an event space there. And we've been really good friends with them. They use Redwood and some of their.

Projects that they do. ~And so we have, we're very friendly with them~ and they have a, an event space that's very neat in the, ~you know,~ in the trees. And ~there's,~ there's redwoods in this town, so if you wanna come see some real redwoods, you can come to Grant's Pass Oregon for this conference in September.

It's a two day, it'll be two days of talks. There'll be a workshop day on the front end, [00:42:00] and there'll be ~kind of~ an activity day on the back end where we'll go, ~you know,~ mountain biking or offroading or whatever. There'll be some different activities that people can do. ~So, And it's just, it's gonna be, it's gonna be awesome.~

It's gonna be a lot of fun. We're gonna have some great speakers. We're gonna eat some good food. Enjoy ~the local,~ the local scene there. ~Um,~ and so tickets are for sale Now, we're still putting the speaker lineup together, but you can go to redwood js comp.com and you can see more of what's happening there.

We'll also have a virtual online presence as well, if you're not able to make it.

Noel: Nice. That sounds, ~uh,~ sounds serene. ~Sounds great. We'll,~ we'll ~try to get a link. Uh, To the show notes and ~link to that in the show notes as well. ~Um, yeah. Very cool. Is there, is there anything else you wanted to cover or plug that we haven't, we haven't talked about?~

Tom: ~Um, I don't think so. I think that's the, that's the main stuff.~

Noel: ~That's the gist. Cool. Um, well~ thank you so much for, ~uh,~ coming online and chatting with me, Tom. It's been a pleasure.

Tom: Absolutely. Thank you so much.

Noel: ~sure. Take it easy.~