Tom Preston-Werner is the Cofounder at Preston-Werner Ventures. They dive into the world of React, Redwood JS, and the evolving landscape of JavaScript development. They discuss the importance of keeping up with the JavaScript world, the benefits of learning SQL, and the challenges of using ORMs. They also explore the upcoming Redwood JS conference, the future of React Server Components, and the motivations behind building open-source projects. 

 

Charles Max Wood (00:22.627)

Hey folks, welcome back to another episode of JavaScript Jabber. This week on our panel we have Steve Edwards.

 

Steve (00:29.172)

Hello from a all of a sudden cool and misty Portland today.

 

Charles Max Wood (00:34.71)

Dan Shappir

 

Dan (00:36.871)

Hi, coming from a warm and sunny Tel Aviv, as is usual in August in Tel Aviv.

 

Charles Max Wood (00:44.494)

AJ O'Neil?

 

AJ (00:46.365)

Yo, yo, coming at you from an early fall.

 

Charles Max Wood (00:50.055)

Charles Maxwood from Top End Devs. And I'm gonna introduce our guest, but just seeing his face just reminds me of interviewing him back in like 2009 or something. We've got Tom Preston Warner. Tom, do you wanna introduce yourself? Let people know who you are and why we like you.

 

Steve (00:50.172)

Oh, bummer.

 

Tom Preston-Werner (01:08.238)

Sure, yeah. Tom Preston Warner. I live just north of San Francisco in Marin County. And you probably know me best as the co-founder of GitHub, but I've also created a lot of open source projects that you may have heard of or used, like Jekyll or Semantic Versioning or Toml, the configuration language. Various other things, but those are the big ones. So I'm really happy to be here. Thanks for having me.

 

Steve (01:33.228)

So could you explain what GitHub is for those who might not know? No, I'm kidding, I'm kidding.

 

Charles Max Wood (01:33.231)

Yep, absolutely.

 

Tom Preston-Werner (01:35.819)

Alright, so GitHub...

 

AJ (01:39.581)

No, I want to hear this. What is the explanation of GitHub?

 

Charles Max Wood (01:39.646)

Well, it's funny because...

 

Tom Preston-Werner (01:43.702)

What is the, it's a social coding platform where people can collaborate on code.

 

Charles Max Wood (01:51.143)

I still remember you and Chris talking about it at like a RailsConf or something. It was just a little project that you were trying to get people to use.

 

Tom Preston-Werner (01:59.542)

I know. Well, everything starts small, right? Like everything, everything big started out as something small.

 

Charles Max Wood (02:00.919)

It turned into this thing. Yeah.

 

Dan (02:05.251)

And now you're an authentication platform.

 

Charles Max Wood (02:05.701)

Yeah.

 

Charles Max Wood (02:09.083)

All right, there we go.

 

Tom Preston-Werner (02:09.708)

Well, yeah, that's true, right? That's a true measure of success. Do people use you to log into other things?

 

AJ (02:10.292)

Huh?

 

AJ (02:15.882)

Yeah, that's what you know who've arrived

 

Tom Preston-Werner (02:17.335)

Ha ha ha.

 

Charles Max Wood (02:19.651)

Yeah, so you're doing the Redwood JS thing, and I think we've had you on before to talk about it, but we probably could do with just a brief reminder of what it is and how it works, and then we can get into, okay, well, what's coming, because you're doing some pretty interesting stuff there.

 

Tom Preston-Werner (02:36.146)

Yeah, Redwood.js is a full stack JavaScript web application framework where we really try to integrate a lot of really great open source tools and add sort of our special sauce on top of it and make it a really beautiful experience for building full stack web application things, like any kind of SaaS app. Or you could build a GitHub type of thing with Redwood, and we've done a lot of the work for you around integrating things like testing,

 

storybook, an ORM. So I come from a Rails development background, and I love that, but there's no Rails for JavaScript. And that's partly why Redwood exists, is to sort of fill that gap and say, why are we all integrating and building our own frameworks? That's a lot of duplicated effort, and it's hard to transfer then these skill sets from job A to job B.

 

And I thought it was time to combine some of these things, along with some other technical things I was trying to accomplish with Redwood. And that's kind of where it comes from.

 

AJ (03:38.913)

So I've been thinking about this over the years and to the very premise. So we have WordPress. We didn't rewrite WordPress in Ruby or we didn't create a WordPress and rails because WordPress is the PHP killer app. It is the singular reason for PHP. Rails.

 

Dan (04:05.819)

That and Facebook. That and Facebook, I think.

 

Charles Max Wood (04:05.903)

You just heard a whole bunch of people's feelings. Ha ha ha.

 

AJ (04:08.485)

You know, Facebook's not written in PHP. And then, I mean, it used to be once upon a time, but like anyway, I mean, that's Twitter's not written in Rails anymore. OK, sure. But yeah, and then PHP BB is still out there. So then we had Rails and Rails was Ruby's killer app. And it was like more control than WordPress, but still pretty cookie cutter.

 

Tom Preston-Werner (04:19.146)

What about PHPBB? That was my favorite. Great, great bullet.

 

Tom Preston-Werner (04:31.723)

Yes, agreed.

 

AJ (04:37.365)

And when node came out, it seems like the thing that both, you know, that the time period, as well as the technology, what node was well suited for. Especially because JavaScript was admittedly much worse back then. There were so, so many more things weren't yet standardized and people were still bickering and fighting over which of the 10 different ways you could organize parameters and promises was going to be the one that wins out.

 

Right. But, but the thing about node was it was for connecting API APIs. And I don't feel like node has had a killer app other than express, which is kind of like, it's a better Sinatra because it's way more poor, way more performant. So with it, and I've seen there's like sales and there's a couple of others that people have tried to replicate rails and node, but my question is.

 

If you want rails, why not use rails? Why is something else going to be successful where node seems to take, have taken over a different market and that's not its killer app.

 

Tom Preston-Werner (05:50.25)

Yeah, well, I don't know that, I mean, there have, I think, been attempts to really recreate Rails in a more specific way where it's like where it feels like Rails, you're using a lot of the same patterns. So just to be clear, Redwood.js is not that. It's sort of inspired by some of the feelings of using Rails, but it's not trying to be Rails as such. It's trying to be all of the tooling, all of the really great tooling that we have in the JavaScript TypeScript world these days, but combined in a way that makes them all really shine.

 

together in a way that Rails gave you the feeling of this fully integrated suite of tools that you could use to build a SaaS app. You didn't have to reach outside of the main tools a huge amount. Like, for instance, testing was just built in. You're like, oh, I'm going to build a Rails app. Here's what I'm using for tests. And that's not as much the case in the JavaScript world. Or what ORM am I going to use? It's just sort of set for you. It's all integrated so that you don't have to think about it.

 

You don't have to go evaluate 17 different ORMs. You just are like, oh, I'm using Rails, I'm using ActiveRecord, okay? And Redwood.js is the same.

 

AJ (06:51.837)

Right. And that's my question is that we already have that. It seems we already have the market for that and we already have the product for that.

 

Tom Preston-Werner (07:04.542)

You mean Rails? Sure, the only problem with Rails is that you have to use Ruby to write it, which if you look at the numbers of developers... And I don't have anything against Ruby. I love Ruby, to be fair. Okay, I love Ruby and I love Rails. But there's a lot more developers writing JavaScript and TypeScript today. So there are opportunities in the developer landscape to service those developers that are sort of optimizing their career path for using...

 

Charles Max Wood (07:12.687)

I don't see that as a problem.

 

Dan (07:14.875)

Hahaha!

 

AJ (07:15.195)

I mean, I'm gonna agree with Chuck on this one if it's...

 

Tom Preston-Werner (07:33.89)

JavaScript and TypeScript. And that is a tremendous number of people. It's just incredible how many developers are choosing that path today because you can write website code, you can write server-side code, you can write command line tools, you can write pretty much anything you want to write these days using Node and using the browser runtimes that JavaScript, TypeScript sort of run in these days to build everything. It's the whole thing. It's everywhere, all the time, all at once. And there's...

 

Dan (08:00.819)

and on top of that uh... sargon

 

Tom Preston-Werner (08:03.434)

Yeah, go ahead. No, no, no.

 

Dan (08:06.051)

No, I was going to say that I totally agree with everything you said. And on top of that is that tight integration with the front end framework, which you just don't have when you use a language on the backend, which is not JavaScript or TypeScript.

 

Tom Preston-Werner (08:25.15)

Right, exactly, yeah. Well, there's something nice about having a unified language front-ended back-end, right? Like when you're writing Ruby, if you're writing Rails, you're writing Ruby, but you're also gonna be writing some JavaScript, which is generally not a huge problem. But if you could reduce the number of languages that you use in your project, that would be nice, right? It's not a deal breaker, certainly, but you'd prefer

 

Charles Max Wood (08:25.159)

I think that's also a false premise, but maybe Redwood's solving some of those issues. Yeah.

 

Tom Preston-Werner (08:54.226)

all other things being equal to use fewer languages than more languages.

 

AJ (08:59.205)

I also don't know if that's true.

 

Dan (09:01.24)

But it's not just the language. It's also the templating. It's the fact that you don't need to implement the HTML templating in two different mechanisms to effectively recreate some of the same templates into distinct programming languages using distinct frameworks.

 

Tom Preston-Werner (09:21.714)

Right, and that I think is the beauty of React, that React really helped solve that problem. And this is where Rails sort of fell behind, and we could talk about where Rails is now and they've solved some of these problems, but for many years, Rails sort of completely ignored the JavaScript, the evolution of JavaScript. And so things like React came along and Rails was just put on blinders and was like, I see nothing. I see nothing new in the JavaScript world. And it was really pretty shocking to me. And I think they lost a lot of people because of that.

 

Dan (09:45.154)

Ha!

 

Tom Preston-Werner (09:51.094)

people who are like, React is amazing. Like this uni-directional flow of information, like the ability to prototype out your components in isolation using something like Storybook, which is amazing to me, right? You don't have to load your whole app in order to build a new component. You can just sort of mock the data that goes into it. You can press buttons and twiddle all of the different fields that there are. Like it's such a tremendous thing to be able to do to isolate it.

 

in that way. Anyway, but Rails is overdoing the thing that it's always been doing with ERB and whatnot. And that lack of keeping up with the JavaScript world to me, that was part of why I sort of wandered off is that at a previous startup after GitHub, Scott Chacon and I, another GitHub co-founder, we worked on this project called Chatterbug, which is a language learning platform. If you want to learn German or French, you can go there today, actually chatterbug.com. You can go to learn these languages.

 

So we started building it with Rails in the traditional way using ERB and everything. Then we brought on a developer slash designer who wanted to build with React. And we were like, okay, yeah, React is modern. Let's use your prowess to start building in React. And so more and more the front end became React and that was really nice. And then something interesting happened. We needed a mobile application. And so we built a mobile app using React Native. We also built a GraphQL backend.

 

to then serve the mobile application. And so now we had the front end of the web app being primarily React and a mobile application consuming GraphQL. The interesting thing was that the front end developers started to prefer using the GraphQL API even within the web application itself. So that GraphQL was consuming, or sorry, the web front end that was being served with Rails, that was a React app.

 

was consuming directly from GraphQL and not asking Rails for information anymore. So we're bypassing Rails almost entirely. It was just serving assets at that point. And so this architecture of a...

 

Charles Max Wood (11:52.615)

Hmm. I'm just going to chime in here and say that GraphQL in Rails is still a giant pain in the rear.

 

AJ (12:00.077)

Oh, that's true. I think for everything except JavaScript.

 

Tom Preston-Werner (12:00.225)

Yeah, like they're just not made for each other.

 

Dan (12:04.816)

It's true for everything except Apollo, I think.

 

Tom Preston-Werner (12:05.246)

Yeah, well, and.

 

AJ (12:07.421)

Right, right, more specifically.

 

Tom Preston-Werner (12:08.722)

And this, and so this is why you see some of these decisions reflected in Redwood. So Redwood is actually informed out of some of this work with Chatterbug where we, we made these, we had these learnings that like, wow, it's actually really nice because then you don't need multiple backends to do stuff, right? Because what we were doing is being like, all right, we have one backend that is Rails and then we have a separate backend that is a GraphQL API. And now we got to keep these two kind of synchronized, but eventually we ended up just having

 

pretty much the GraphQL API backend that was serving all of the clients, the web client and the mobile client. And this architecture I thought was pretty cool. And so that's partly why Redwood JS looks the way it does today, which uses GraphQL. So it's a React app on the front end that consumes data from a GraphQL API backend. That's all written in TypeScript or JavaScript if you want. And so that's the architecture. And this...

 

Part of the reason, not the reason anymore, but part of the reason too that Redwood looks the way it does is because that architecture works really well in a serverless environment. And I wanted to be able to deploy full stack applications to Netlify because I've worked with them since they was just the two founders and I've been an investor all along and I'm on the board. So I wanted to find a way to build a framework to make it easy to deploy full stack applications on Netlify. Now that-

 

Turns out to not work as well as I wanted it to, mostly because of lambda functions. Have not evolved almost at all since in the last five years. But right now, the focus has become more serverful. You can still use Redwood in either environment. But we focus more now on really good performance in serverful environments.

 

Dan (13:53.575)

So who exactly was your target audience with Redwood? Obviously yourselves, but you didn't just create a framework for your own specific use. You were, I think, thinking a wider scale. So aside from the Netlify-based deployment, what was your focus?

 

Tom Preston-Werner (14:16.466)

Initially, it was really anyone that wanted a smoother path to a full stack web application framework. What we found as we made a more sophisticated framework was that, and especially one that used GraphQL, is that we needed more sophisticated kinds of players, people that knew more about more of the stack and were willing to invest the additional time upfront in order to get the long-term benefits of using.

 

something like this architecture of React, GraphQL, use Prisma on the backend, because it's more difficult to experiment with that stack than it is with something like Next.js. Right, you can spin up a Next.js thing in like five seconds. With Redwood, it takes a little longer, right, because you gotta go through the GraphQL, the generation of the GraphQL, SDLs and stuff, right? So...

 

But the advantages that you can get from that are really great. And so we started focusing on startups. So the marketing message today, kind of the ideal profile of a user today is, looks more like a startup, someone that is willing to put in more effort upfront to get these really nice benefits long-term and be able to hire people that understand and know how to use Redwood and the stack. And that's worked really well, but I'm not satisfied with that because it's, it's too difficult to get into Redwood today. And that's a big reason why we're going all in on.

 

React server components is one of the big reasons is that it allows us to not need to use GraphQL anymore. You'll be able to talk directly to the server in the server side components and not have to use GraphQL at all in your Redwood JS application.

 

Dan (15:49.531)

So.

 

Dan (15:54.087)

So I will get into that and dig into that, I promise, but I want to pull us back slightly because it kind of stems from a blog post that apparently you put out in May, but I only noticed ahead of this recording, which is about the new epoch or the next epoch for Redwood JS. And reading throughout this entire blog post, first of all, I understand that

 

that it's not yet something that exists, it's your roadmap going forward, correct?

 

Tom Preston-Werner (16:29.058)

Correct. Yes.

 

Dan (16:31.346)

but that you're already working on.

 

Tom Preston-Werner (16:33.766)

Oh yeah, we've been, yeah, we have simple versions of React Server components working in Redwood today, yes.

 

Dan (16:39.943)

So it seems to me that in a lot of ways, and you might disagree or agree, you're doing a sort of an almost about face on some of your core previous decisions, which leads me to kind of ask, is this the official death of the gemstack?

 

Charles Max Wood (17:02.752)

Oh, here we go.

 

Tom Preston-Werner (17:06.673)

That's a fine question. That's a really great question for me, actually, because I was part of the conversation for where Jamstack came from, talking to Chris and Matt, founders of Netlify, when they were actually talking about, like, should we create this term to help people clarify what this architecture is that Netlify was really making it easy to produce and call it the Jamstack. So I was there at the...

 

at the birth of the JAMstack. I think like with most technologies, it's not so much that the JAMstack is dead. Okay, let's say it this way. Maybe the JAMstack is dead in the same way that Ajax is dead. In that Ajax is not dead, it just became everything. It's just a part of how things work now. It is one of the... I see furrowed brows.

 

So Ajax, right, Ajax for those young listeners out there, Ajax was, so the first real big use of Ajax to me was Google Maps, right? Google Maps came out with the ability to like pan around your map on your computer, and it would just pull in like new tiles. And it was mind blowing. Like this was a thing that almost nobody did at the time. Right? Like you couldn't do that. You couldn't just pan a thing around and have stuff load in like asynchronously. And so Ajax made that possible.

 

AJ (18:00.874)

Mm.

 

Steve (18:02.696)

Well, I mean, I thought it.

 

Dan (18:06.779)

Hahaha!

 

Tom Preston-Werner (18:30.518)

And the only reason that Ajax is as popular or became as popular as it did is because it had a name that allowed people to understand what it meant. So you'd be like, how did you do that? How did Google Maps do that? Oh, well, they used Ajax. Like, what is Ajax? So you go look it up and you're like, oh, it's how you use XML HTTP request to pull in data asynchronously from a web browser. And so it had a name.

 

Steve (18:50.604)

Well, here's the thing you got to remember though, is the X stood for XML. I mean, that alone was pretty thing. In the Drupal world, they changed the acronym to like, aha, I can't remember what it was, but it was to simplify that it didn't have to be XML, it could be some other source. But, all right.

 

Tom Preston-Werner (18:55.07)

I know, but that's... fine, but the-

 

Dan (18:56.792)

Yeah.

 

Tom Preston-Werner (19:05.966)

Yeah, yeah, of course. But I mean it evolved, right? Like the way that we started using Ajax and XMLHttpRequest was to send, you know, JSON and other stuff, right? The XML was not important.

 

Dan (19:18.207)

And to be fair, or to be honest, I think the vast majority of web developers these days would not even know what Ajax stands for. It's just.

 

Steve (19:26.464)

Well, for those of us that are old enough.

 

Tom Preston-Werner (19:26.634)

Right. And that's my point entirely, is that we all use AJAX all day, every day. That is how the web works. And I'm suggesting that Jamstack is similar, in that many, many websites will use that architecture, but it doesn't necessarily need a name anymore, because everybody understands that architecture.

 

Dan (19:43.343)

So can you define?

 

Steve (19:43.424)

For those of us who are old enough, we remember it as a cleaning product.

 

Charles Max Wood (19:46.927)

Right? An abrasive cleaning product. Can I?

 

Dan (19:47.967)

Yeah, so you could do... Yeah, so just a question. I think it just required kind of, sorry for barging in, but could you define the gem stack from your perspective?

 

Tom Preston-Werner (19:50.071)

Also that.

 

Tom Preston-Werner (20:02.502)

I think the latest version of Jamstack that we all know today is an architecture where you're statically delivering most of the content. So you're doing a lot of pre-building. So this is really useful for content sites. And then you're using JavaScript to pull in information on top of that to make it interactive as an enhancement, right? But you get the security benefits and performance benefits of having statically generated content.

 

Meanwhile, you can make it interactive, right?

 

Dan (20:35.479)

So from your perspective, the gem stack is tied to the concept of static site generation or SSG.

 

Tom Preston-Werner (20:44.11)

Well, that's part of it, right? But things like Netlify and Vercell have made it so that you can do more advanced things. You build in a lot of caching so that you can do real-time updates. You don't have to pre-build everything, right? You can do stale while revalidate. You can do different techniques, but they're all based around generally executing something in advance and either caching it or doing it in advance, you know, real-time caching. So if you have a like a giant product catalog, you don't want to pre-generate

 

5 million pages would take forever. So you wait until someone requests them, you generate it, you cache that response. It ends up being sort of a similar behavior. It's just that you're waiting until someone actually wants the content to do it. So it's a lot more complicated now. And that's why I think Jamstack is losing its appeal because it's so much more than that. The techniques have blossomed in a way that you can't just be like, oh yeah, it's static sites with JavaScript.

 

AJ (21:27.381)

That's.

 

AJ (21:42.741)

So what you had just mentioned, that's kind of the WordPress plus varnish approach, right? You wait until it's.

 

Steve (21:47.624)

Yes, yes, exactly.

 

Tom Preston-Werner (21:50.814)

Yeah, right. And so, yeah, so things like WordPress have also had enhancements where they're like, oh yeah, like it doesn't make sense to regenerate a blog post every time someone requests it, right? Like there are solutions that have been created for the WordPress problem, right? You just do it in a different way. It looks like caching, you know.

 

Charles Max Wood (22:10.191)

All right, I'm gonna derail this back onto Redwood.

 

Tom Preston-Werner (22:13.861)

Hehehehe

 

AJ (22:14.145)

Wait, isn't that where we've been the whole time?

 

Charles Max Wood (22:16.775)

Well, we're talking about Jamstack and we're talking about, I mean, we're kind of laying some of the planks, but I really wanna get to, okay, so, you know, Jam, or not Jamstack, you guys messed me up. So Redwood solves a lot of these problems, right? It uses kind of these best of breed technologies, you're putting this stuff together, you know, you have a way, a Redwood JS way of doing things.

 

Tom Preston-Werner (22:17.038)

I'm gonna go to bed.

 

Charles Max Wood (22:42.615)

Right. And so people can go check it out and I encourage you to go check it out because it's always interesting to see what folks are doing and you know, even if you don't wind up using Redwood, you can pick up some of the tech tools that they're putting together for you. Um, but yeah, so what, what problems are you seeing going forward? Right. Cause we've kind of talked about Jamstack solve some of these problems and some of these other things, solving the problem. So what are you seeing coming and why are you pulling in some of these solutions for Redwood JS?

 

going forward and why are those the solutions that you picked? That's what I want to get into, right? I mean, the past is fun, but the future is really interesting.

 

Tom Preston-Werner (23:22.41)

Yeah, well, there's two big reasons. So number one is React itself. So the React team has made pretty clear that the future of React is React server components. That's all they talk about. That's all that they write about. They they're doing a ton of work to get people on board. They're working very closely with Next.js and other framework providers like us to get versions of, of React server components out there into people's hands so that they can start using it and understanding what that means and how React is going to

 

evolve over time. So number one, right, like if you want to be a React framework, you're probably going to need to support it in some kind of way. Okay, so that's number one. Well, I think you'll probably see them supporting it too. I mean, I've seen...

 

Dan (24:02.435)

Unless you're Remix. Yeah, I know, I know. I'm just making fun of them because they kind of looked at it and said, yeah, not now. But I totally agree that eventually they'll adopt it like it or not. Like you said, it's the future of React. I agree with that. But for now, they're holding off on it. So I was just, you know,

 

Tom Preston-Werner (24:31.058)

Yeah. Yes, that's a, it's a fair point. Yes. They, they did not initially like it. And I think that's fine. Right. I'm not saying that everybody has to go and implement react server components. Every project can do or do not as they wish. This is the beauty of open source and new projects and whatever. Right. But react community, the react team, I think is going to be paying more attention to frameworks that support it than to frameworks that do not as well as users, right? Users is going to be like, I expect to be able to use react server.

 

Dan (24:32.859)

jobbing fun. Thank you.

 

Tom Preston-Werner (25:00.274)

And if you can't support that for me, then I'll go find something that does. So that's point number one. Point number two is we were looking a lot at how to solve problems around server-side rendering. So as an SPA, a single-page application framework, that's how Redwood started. And that architecture works really well, but it has some downsides.

 

Dan (25:04.912)

I agree.

 

Tom Preston-Werner (25:28.958)

One of the downsides is doing things like putting OG tags on a page. So OG tags are open graph tags. That's what allow URLs to unfurl in things like Twitter and Slack and other places where you get a little preview. You get an image and a description of the page. In order to do that, you need to be able to put those header tags into the page and serve them with the first delivery of HTML, the very first delivery. It has to be there. It can't be added by JavaScript later on.

 

because the things that consume it are gonna just do like a curl, essentially, and they're gonna be like, all right, here's my page. And if you're a pure SPA with React, then there's nothing really on your page except a div that's gonna be replaced by what React decides to do later on. So problems like this require some kind of a server-side rendering, right? The server has to render the page, it has to get the header tags, and then ship all that down as HTML to whoever's asking.

 

for it for things like OG tags and for SEO performance. These are things that people rightfully want, right? Like these are desirable things to be able to do. So with Redwood, as we were attempting to implement some kind of SSR, then React Server Components is also becoming a thing. And so we're looking at it and saying, should we use React Server Components to solve our SSR kinds of problems? Or should we be rolling our own thing using data loaders or a pattern that maybe looks a little bit more like remix?

 

And we decided that React Server Components becoming obviously the future of React, that we should really double down on React Server Components, use them to solve our server-side rendering needs, and at the same time, be able to offer people a way to fetch their data that did not require using GraphQL. Because as much as I love GraphQL, and as good as it is for a certain set of problems, it also comes with downsides. This is technology in general.

 

everything's upsides and downsides. There's always pluses and minuses. We're always making trade-offs. So the trade-off with GraphQL is that it's an amazing multi-purpose API that is super great for front-end developers to use. The downside is that you have more work to do by defining your SDLs, your definition language of what your protocol looks like.

 

Tom Preston-Werner (27:50.846)

as well as performance and security ramifications in building a GraphQL API. Like it's not trivial. When you do it right, it's amazing, but it takes some effort to do it right. The problem for us with Redwood is that it's a barrier to entry that we feel is reducing sort of conversion of the funnel. Like you're like, Redwood JS integrated full stack web framework, that seems awesome. I'll use that. Like, why would I not?

 

And then you get to the part where it's like, oh, now here's how you use GraphQL. And you're like, I don't know how GraphQL works. And then you learn enough to know that it makes the process take a little more time. And we would love for Redwood JS to be a direct competitor to things like Next.js where you'd use it for a hackathon, where the primary goal is to get something done fast, to prototype, just hack it out, get something done. And the big reason for that is that

 

most people start their projects like that with an idea, some random thing that they want to try out. And then they may keep going. And if they keep going, they're probably going to just keep using what they started with. And if they started with Next.js, then they're going to keep using Next.js. And Next.js is wonderful. It's a really amazing tool, and they've paved a lot of ground and made a lot of innovations. But it's one tiny piece of what you need to build a SaaS application. We'd love to give people more...

 

advantages more out of the box than Next.js does. So that if they do choose to keep going, they have all those tools at their fingertips instead of having to figure out how to add them all. And so if we can make Redwood.js as easy to use for hackathon as Next.js, then we think that we can improve a lot of developers' lives and help them go faster and build more of what they're interested in, which is their app and less of what they're not interested in, which is building a...

 

web application framework.

 

Dan (29:43.655)

So since you brought Redwood as an alternative to Next.js and people, as you kind of indicated, by default when they think about React and React server components and a React quote unquote meta framework these days, they probably think of Next.js. What are the advantages that Redwood.js brings that should make or would make me choose it?

 

rather than just going with the quote unquote default.

 

Tom Preston-Werner (30:15.946)

Yeah, so I've mentioned a lot of them before, but it's being opinionated about the stack of technologies that you're going to use. So even if you're using React server components, you're still going to be using Prisma out of the box. So Prisma is integrated as well as testing with Jest and a mocking framework that allows you to use those things in your tests and mock out API calls and things like that.

 

in a much more natural way than trying to just bolt them on. Like the amount of work that we've done to integrate these things is quite a lot. And if you're doing them on your own, it takes a very long time. But let me just say, even without GraphQL, the ability to say, I'm not gonna use GraphQL today, but someday I might like to build a mobile application, or some kind of third party client. And it would be really nice to use GraphQL in that use case.

 

And having first class GraphQL API support available in the same framework that you're using to build your web application as an add-on later on, to me represents a pretty massive benefit over something that's much more specific and small like Next.js.

 

AJ (31:27.125)

So why bother with an abstraction layer? Why not just get right to the core of it and say, okay, Postgres, why the... So this seems like a paradox because if you compare and contrast databases and you're like, well, are we gonna pay $100 million per month for Oracle? Are we gonna just suffer through ambiguous error codes with MySQL? Are we gonna use the right database Postgres? You know, like why even...

 

Tom Preston-Werner (31:55.01)

Hehehehe

 

AJ (31:56.157)

Why even make people go through all of that trouble rather than just saying, look, here's the baked in solution. It's totally baked in. You don't have to futz around and then you actually get to take advantage of your database. So, so let's even say that you didn't use Postgres. You use something else. Every database has some sort of advantage to it. That if you use that advantage, then duh, you get the advantage of it. But if you abstract it away,

 

then you get no advantage and then it's like, well, why bother picking a database in the first place? So why not just go straight to the database rather than say, oh, we're going to handle the abstraction.

 

Tom Preston-Werner (32:37.602)

I think that's a fine question, and that's absolutely true, I think, to some degree. Now, any decent ORM is going to allow you to write raw SQL statements and use a database directly. Well, that's.

 

AJ (32:47.069)

And at that point, there's no point using the ORM, right? If you, if you've had to drop down to raw SQL statements, then just use the SQL and not have all the convoluted stuff in between.

 

Tom Preston-Werner (32:56.086)

That's true if you had to make the decision to do one or the other, but often you can get advantage of most of the benefits of the ORM in the easy cases where you're able to do most normal things that you want to do without writing raw SQL and have the negatives of using raw SQL. You can get everything that's really nice about the ORM in most cases and where you want to dive down into the specifics of a specific database, then you might have to use raw SQL to do that.

 

that is okay. You're not going to get the sort of advantages of using the ORM and the tools that it builds, the abstractions that it gives you on top of that, right? I'm just saying it's not 100%. You don't have to choose 100% one or the other. But I mean, yeah, I mean, if you want to write raw SQL all day long, I think that that's a fine thing to do. And there are certainly advantages to doing that. But most people like using ORMs.

 

Dan (33:48.736)

Is it worthwhile?

 

AJ (33:49.289)

Well, it's not just about writing role sequel. It's about picking something that is actually geared to take advantage of the benefits of a specific thing. Right. So Prisma is not going to give you any advantages, right? It's you're not going to get any benefit out of Prisma, whether you pick Postgres or Oracle or MS SQL, right?

 

Dan (34:10.731)

Is it worthwhile maybe for at least some of our listeners to explain what ORM is and what Prisma does? Or does everybody, or can we assume that everybody knows?

 

AJ (34:22.841)

I think we ought to... I don't think people know. I think even people that think they know don't know.

 

Charles Max Wood (34:28.751)

Yeah, let's just keep it brief because I still I want to stay on Redwood. Make sure we're covering what's going on there.

 

Tom Preston-Werner (34:34.178)

Sure, well, I can take a stab at it for you. So Prisma is an ORM, an object relational mapper for a database that says you can write code essentially, that's not SQL, right? You're writing JavaScript, TypeScript code to ask for information from your database. In this case, if you're using a relational database like Postgres, MySQL, then you write

 

code to do that, and then you get a JavaScript object that contains the data from your database in a way that is easy to consume in your language of choice, in this case JavaScript, TypeScript. Prisma goes to great lengths to guarantee type safety, so you get that if you're using TypeScript. You get to know that the data types that are coming out of your database are going to be what you expect in your language, so that would be an advantage of using an

 

Tom Preston-Werner (35:28.49)

then you'll know that that's going to be represented as a string type in your TypeScript application, and you don't get confused about what the types are. So a lot of people really enjoy the type safety there, as well as defining relationships and being able to traverse relationships. That's something that you would have to do much more manually if you were using raw SQL. So you can say, this key on this table represents a foreign key on another table, and now you can traverse those relationships using the ORM.

 

much more simply than you can by having to explicitly define all the joins and everything yourself every time that you're writing raw SQL. These are some of the big advantages of using an ORM like Prisma. I think Prisma does a really good job. It also allows you, I mean, this is unlikely, but if you did need to change a database at some point, if you needed to switch from MySQL to Postgres, and this does happen from time to time, especially in an age where we have things like planet scale and terso and...

 

fauna and you know, there's so many, you know, neon, there's so many different providers that being able to switch from one to the other. And I've seen it happen. Don't say it never happens. I just saw it happen with a company the other day actually.

 

AJ (36:31.617)

I don't

 

AJ (36:36.985)

I'm not going to say it never happens, but I think it's, I think it's like saying you shouldn't get in a car because you might get in a car crash, right? Or you shouldn't get in a plane because you might get in a plane crash. Like it, I, people bring it up and, and I think that it does a disservice to anyone listening in the same way it would do a disservice to people listening to talk about the dangers of planes.

 

Tom Preston-Werner (36:46.494)

No, I agree. I agree. That's a tertiary advantage.

 

Tom Preston-Werner (37:03.118)

There's nothing really that says an ORM can't create specialized features for specific databases, and I actually would need to go look for Prisma, but I would be unsurprised if it allows you to use some of the specialized features of Postgres directly.

 

AJ (37:18.539)

I, I over the last couple of years, I've become more and more redpilled that like you have to learn the sequel anyway. And there's so many benefits of learning it that it just doesn't make sense to pretend like it's some sort of scary thing. I mean, if you don't get sequel, you fundamentally don't get. Concepts of programming that, that you would benefit by, you know, learning

 

those because it's a language it has some strange characteristics, you know, you don't really do loops to you've got like, like group by is, you know, there's some things that have nuance to them that are really frustrating. But at the same time, there's so many frustrations in learning an ORM and there's so many more ORMs there and there are databases, right? You're, you're much more likely over the course of your career.

 

over the course of 20 years to use 50 different ORMs. Well, whatever the number is, right? Use a different ORM at every job than you are to use a different database at every job. There's a finite number of databases and an infinite number of ORMs. Each ORM is incomplete. Each ORM has hundreds or thousands of open issues. And so, and each ORM makes it difficult for you to take advantage of what the database would do easily.

 

Tom Preston-Werner (38:25.898)

Yeah, true.

 

AJ (38:43.941)

natively and if there were an ORM that was like a full on let's say that it was my sequel let's say it's just a full-on my sequel ORM heaven forbid that they you know didn't choose Postgres but I could get behind that philosophically in the same way that I can philosophically get behind something that says there's no JavaScript it's just TypeScript we do TypeScript like pick a path

 

AJ (39:13.093)

So that that's, I'm, I get that SQL builders can be convenient when you're learning, especially if it has like a, a two query or a two string method where you can see what it generated so you can learn, but I'm, I'm more from like, my curiosity is more like you're trying to streamline this. You're trying to make it great. Um, you know, why not just go down to the database and then they don't have to deal with all that planet scale or whatever, cause every single

 

Every single platform is going to have essentially, I think Postgres has kind of become the universal database. Even even platforms that have something that's a modified version of Postgres like Cockroach or whatever. They all have a Postgres adapter. So you end up using Postgres commands.

 

Tom Preston-Werner (39:59.71)

Yeah, I think your viewpoint is totally valid. I think if you want to use SQL directly, that that's a fine way to do it.

 

AJ (40:05.769)

Well, but I'm not, I'm not saying that the SQL directly is the viewpoint. I'm saying pick the database is the viewpoint. I personally have come to the, you know, SQL is not an enemy. It's a friend, but I'm saying rather than pick an abstraction layer, the Prisma picks some like say we use PG SQL or, or whatever, like keep, keep an abstraction layer, if that makes sense, which I'm whether that makes sense or not.

 

Charles Max Wood (40:15.067)

Yeah.

 

AJ (40:34.781)

It's totally up for debate. I think there's good arguments on both sides, but pick an abstraction layer that is about a specific thing. Not like two or three times removed. That that's what I'm, that's what I'm questioning.

 

Tom Preston-Werner (40:35.819)

Yeah.

 

Tom Preston-Werner (40:47.55)

Yeah, well, I'll give you some history here as well, is that at the time that we were building Redwood JS a couple of years ago, looking for an ORM, because I do like using an ORM. I do find that the ergonomics of using it can be excellent. And I think Active Record from Rails is the best ORM hands down. 100% nothing can touch Active Record today. Like even it's like a hundred X better than anything else out there. So I'll put that out there first.

 

Charles Max Wood (41:03.763)

I agree.

 

Tom Preston-Werner (41:16.562)

I like the advantages of using an ORM. At the time, there was very little that was good in the JavaScript world at all. And then Prisma came around and they started developing, this is like three years ago now, four years ago probably. And they looked like an ORM that finally could be one that was good. Like the choices that they were making in how you built things like relationships between models.

 

actually made sense, more sense than anything else I'd seen in the ORM space. And so we chose it because of that. And we've been working with them actively to try to make it the best ORM that it can be. And I think that there's still challenges there. I won't say that there's not. There's limitations and challenges to using an ORM. And I'd love for Prisma to be even better than it is today. But at the same time, it allows us to give people choices that allow them to...

 

not use that as a reason to not use the framework. So this is, when building a framework, you have to decide where your line is on your opinionation. So you could say, why don't you just use Tailwind CSS as your CSS solution and integrate it like super great, and that's the choice that everyone has to make if they use it. This is maybe an easier call to make today. I think you could probably reasonably make that call and not alienate.

 

huge amounts of your potential users because it's such a popular thing, but three years ago, it was not at all. Right? And so if you say you have to use Tailwind in order to use Redwood, guess what? You're not going to get anyone to use your framework that doesn't want to use Tailwind. Likewise, for a database, if you say you have to use Postgres, then yeah, that works pretty well and even better today than it, you know, likewise, Postgres has become a better and better database, a more and more easy

 

AJ (42:58.442)

Wait.

 

Tom Preston-Werner (43:11.83)

default choice, but I think that you still alienate those people that want to use Planet Scale, for instance.

 

AJ (43:14.484)

I

 

Charles Max Wood (43:20.867)

I think I'm gonna push us back to the main discussion. I think this is an interesting debate to have, but I think our listeners are gonna want to know what other things are coming with Redwood. And then maybe we can have Tom back to discuss the ins and outs of ORM design, or maybe have somebody from Prisma on. Because I think it's an interesting discussion, but I don't think that's what people are gonna be tapping our episode to pick up.

 

AJ (43:20.958)

I don't...

 

Tom Preston-Werner (43:23.607)

Ha ha.

 

Tom Preston-Werner (43:42.359)

There you go.

 

AJ (43:49.053)

Well, that's actually kind of my point, is that people that don't care about the database don't care about the database.

 

AJ (43:58.889)

It's like Tailwind is something that people who are going to use Redwood probably. I, my guess is that you have more people have more opinions that are using Redwood. More people have more opinions about diverse front end technologies they want to use than diverse backend technologies they want to use. Cause you've almost specified the backend the whole way through.

 

Charles Max Wood (43:59.184)

Yeah.

 

Tom Preston-Werner (44:23.71)

Yeah, true. Yeah. No, I mean, focusing on a single database, I think could be a reasonable thing to do.

 

Dan (44:32.507)

So to pull us back towards Redwood itself, so you're making some significant architectural changes in this next epoch of Redwood, which I gather is called Redwood JS Big Horn. And so the obvious question is, what happens to those people who are using the existing version of Redwood? Like, what is the transition story for them?

 

Migration Story.

 

Tom Preston-Werner (45:03.338)

Our hope is that they continue to be able to use Redwood JS via an upgrade path that is not too difficult. We're trying to not completely break how Redwood JS works for those that are using it. So if you're using the GraphQL, the current kind of GraphQL based version, then that will continue to work because we'll continue to support GraphQL and make it better. In fact, we're adding real-time GraphQL support now. That's actually in, I think, 6.0, a 6.x version.

 

Dan (45:28.015)

Mmm, nice.

 

Tom Preston-Werner (45:33.554)

So we'll continue to make the GraphQL support better and better and we have new improvements to the sort of playground for using GraphQL that integrates it with the authentication so you can get off that you can be authenticated in your GraphQL queries, etc So we're going to continue pushing GraphQL as an option for those people that want to use it

 

AJ (45:54.558)

Can you talk more about that authentication bit? Because I know that's been a huge problem for people historically. And I don't know if it still is generally, but getting granular permission on that. What's your approach on that? Or how do you...

 

Tom Preston-Werner (46:07.57)

on GraphQL calls in general. So with Redwood, you have the ability to create what we call directives very easily. So that's how you do authentication in your SDL. So you just define these directives that you can add to any GraphQL query or mutation, that then basically trigger code to be called that runs through and can determine authentication on any specific.

 

AJ (46:11.103)

Yeah, yeah, yeah.

 

Tom Preston-Werner (46:36.718)

query or field and that's where your authentication is defined. You can do it at the field. You have to go essentially yes. You have to do work to do that. But you can put it on any field in your SDL.

 

AJ (46:40.867)

So you got it to the field level.

 

AJ (46:56.725)

Okay. And did we actually define SDL already? I know it's definition language, but what was the s on that? Okay, schema definition language.

 

Tom Preston-Werner (47:03.026)

schema definition language is how GraphQL defines the API that you're gonna use, right? So it says, here's the names of the queries and the mutations and their types.

 

Dan (47:15.779)

It's interesting to see how with things like React Server Components and other solutions, RPC is kind of making a comeback and kind of replacing to an extent, you know, prevalent web APIs like GraphQL or RESTful APIs in a way. But I think that's like a whole other discussion. Yeah.

 

Tom Preston-Werner (47:36.172)

Yeah.

 

Steve (47:39.888)

Once again, the old has become new.

 

Dan (47:42.679)

Yeah, I'm actually thinking about proposing a talk to conferences about that, about the return of RPC. That's kind of happening under the radar of a lot of web developers. Like they're using or they'll be using RPC without even realizing it's RPC. But again, that's a different discussion. Again, going back to Redwood.js itself. I know that...

 

part of the challenge of adopting React Server Components, be it in Next.js and I assume in any meta framework that chooses to adopt it, is the building slash bundling slash deployment story around it. That's kind of fairly challenging. And to an extent, I think that React Server Components isn't even fully spec'd yet, at least the upstream part.

 

because of some of these challenges, like what do they call them, like server functions or server actions isn't now like totally done yet. So how are you going to be dealing with that?

 

Tom Preston-Werner (48:51.914)

Well, it's by having a good relationship with the React team. So we work closely with them. We're in channels where they work with framework developers. It's been really great to get to know them better. But this is a challenge in that it is not specified as well as one would prefer. They're sort of a reference implementation, if you will, in Next.js. We're using Vite as the bundler. So we also work with the Vite.

 

folks to make sure that the support is going to be there. That's something that we're working on with them. But it's challenging. I'm not going to lie. There are challenges in getting React Server components implemented. But we find it important to be there, to be at the table as it's being developed, because it's important to our framework. And we think that we can help make it better by saying, here's how Redwood works. Here's what we think developers are going to want. Here's the ergonomics that we're going for.

 

How can we make sure that React Server Components is gonna work the way that we need it to? Like there are certain things that we do with Redwood. There's a pattern called cells that we use, which we use for data fetching. It makes data fetching with GraphQL really easy. We intend to use cells as well as the sort of data fetching primitive for React Server Components, where now you may be doing that fetching server side instead of over a GraphQL API. We'd like them to work essentially the same, and there's some things that we're gonna have to do in order to make that.

 

Dan (50:09.36)

Mm.

 

Tom Preston-Werner (50:15.286)

work the way that we want as far as defining loaders and loading skeletons for when you're making a request that's not done directly server side on the first page load. Anyway, there's a lot of specifics around how this stuff is implemented, but it's really about having the right relationships, being in the right rooms where the conversations are happening, and having access to the people that are working on the code so that we can say, hey, we're getting this thing across the wire that we can't figure out why it's there or what it's for.

 

And being able to get some insight into that, because there's not a giant spec that we can read and say, here's what they call flight. Flight is the streamed information that goes back and forth between the server to the client. The flight information comes down and it's this compressed JavaScripty thing. It's its own separate thing, right? But it eventually gets converted into...

 

Dan (51:03.683)

Yeah, it's an interesting pro custom protocol.

 

Tom Preston-Werner (51:10.71)

JavaScript and then makes modifications to the page. And this is part of the streaming that comes along with this modern versions of React, right? The streaming aspect is as important as the SSR aspect in order for React server components to function the way that they do. And it's really very cool. They've done an awesome job. The enhancements that you can get, like the choices that you can make as far as what the user perceives and where you wanna do things, server-side rendered, where you wanna wait.

 

for part of the page to load and stream those down on the same connection. You get these progressive enhancement kind of characteristics in a really slick way, but they're quite challenging to implement.

 

Dan (51:49.776)

Yeah.

 

Steve (51:50.22)

I would say that one sort of meta question is, you know, the React team is looking at React as a whole, right? And so you're looking for stuff that's maybe more specific to Redwood. That's got to be quite the balancing act for them to say, okay, how can we help out Redwood here? They're important while at the same time still helping out the rest of the React base and not maybe alienating some people. Does that make sense?

 

Tom Preston-Werner (52:17.19)

Yeah, well, I think it's really important. I mean, we're essentially design partners with them now, right? It's like any startup that's building a product is going to need design partners, essentially. You're early adopters that say, hey, we'll take the extra effort to work with you to help you make your product better by telling you what we need, right? Any project, any solution is going to need real world information in order to not just be some

 

abstract thing that nobody actually can use, it needs to run into reality and get feedback. And so that's what we're there for as well, as Next and the other frameworks that are working on React Server Components is to say, we need to do this thing, because it's important for us. And they'll be like, oh, we didn't think that anyone would need to do that thing. That's useful information. Let's figure out how to make that thing happen for you. So it's really, it's a two-way street. Like they wanna make something usable. We wanna use their...

 

their technology to make developers' lives better. So it's really a collaboration.

 

Dan (53:19.639)

At this point in time, I think it's also worth mentioning and reminding our listeners that we had a great double episode with Dan Abramov and Joe Savona from Meta, well, Joe is still at Meta, about React Server components. So it was episodes 582 and 583. So if people are interested in understanding like the deep details of how this thing works, I highly recommend listening to that.

 

By the way, talking about the fact that you're built on top of Vite, which seems to be like the default choice for most, not all, but most meta frameworks these days, it seems that some of them are even going up one level, as it were, like thinking about Solid Start, you know, built by Ryan Corneato, and are moving from Vite to being built on top of Astro, because Astro itself is built on top of Vite. So it's like...

 

you know, going one level up, is that something you might also consider?

 

Tom Preston-Werner (54:20.91)

That's probably unlikely. There's very specific things that we need to do. And having something in the middle probably makes that more difficult. We're actually just now migrating from Webpack. So we have historically used Webpack. And the latest version of Redwood makes Veet the default now. It's the transition period that we're undergoing so that we don't rile too many Redwood users' feathers to go through this transition, because it's a little tricky to switch bundlers.

 

And Webpack and Vite are not like, you know, you can't just swap them out. Like they do sort of different things and have their own opinions. So I think that we're going to need to use Vite very directly. So I imagine, I can't imagine what would go in between that we would leverage that would make our lives easier. I'm guessing that we would use it directly.

 

Dan (55:10.607)

Yeah, VT is built on top of Rollup, I believe, for production. Yeah.

 

Tom Preston-Werner (55:13.662)

Yeah, they use Rollup, yep. Yeah, and it's great, it's fast. And I was talking with Evan the other day and it really has a ton of traction. He's done an awesome job. They do a really great job. It's great technology.

 

Dan (55:25.891)

Yeah, for sure. Does it make your life easier, besides being faster?

 

Tom Preston-Werner (55:33.586)

Yeah, that's one of the biggest reasons that we switched to it is that it's just modern. Like, it's getting a lot more attention. You always kind of want to be on the thing that is the rocket ship, if you can, because that's where the people are. That's where the attention is going to go. So speed was obviously a primary concern. It allows us to solve the other problems, but I think speed and just modernity and traction were the biggest factors.

 

Dan (56:02.639)

Yeah, so that's another interesting distinction or difference between Redwood and Next, where you use VEAT and they don't. They have like, what is it, TurboPack? What's the name of the thing that is replacing WorkPack?

 

Tom Preston-Werner (56:15.35)

Well, I think they still use Webpack mostly, but yeah, they're transitioning to use Turbo repo.

 

Charles Max Wood (56:17.574)

Mm-hmm.

 

Dan (56:21.927)

Turbo has something.

 

Dan (56:26.763)

Is there any other big change that you're looking at in the context of Big Horn aside from the move from SSG to SSR with the React server components and React server components instead of GraphQL for the majority of use cases?

 

Tom Preston-Werner (56:49.95)

Well, I'll say you can still, you'll still be able to use SSG in the same way that you do now. You can pre-render pages if you want to, if they're like full marketing pages. But I mean, that's the big one. I mean, there's other things that we're doing at the same time. So we have this part of Redwood called Studio, Redwood Studio. This is where the GraphQL playground lives. So it's this sort of separate app that you can spin up next to your main app that allows you to do things like...

 

Dan (56:54.47)

Oh yeah.

 

Tom Preston-Werner (57:17.238)

experiment with your GraphQL API directly in a playground. We have open telemetry support built into the framework. And so you can fire up Redwood Studio and you can get tracing information directly in the studio app without having to pay, some third party consumer thing like New Relic or Datadog or whatever, to be able to see the performance of your application during development and especially important to be able to see the SQL queries that are being executed.

 

Dan (57:23.982)

Oh, that's cool.

 

Tom Preston-Werner (57:47.014)

AJ, you'll like that. So you can go in and you can see exactly how long each of those SQL queries was taking to run, as well as how many were generated. Because again, AJ, one of the downsides of ORMs is that they may produce many, many SQL statements where you were assuming it was only going to generate one. You need to be able to know that. You need transparency into what the ORM is doing under the hood so that you don't shoot yourself in the foot by creating some extremely non-performant

 

Charles Max Wood (57:48.859)

Hehehehehehe

 

AJ (58:14.885)

order in cubed.

 

Tom Preston-Werner (58:17.726)

Exactly. So we make that as easy as possible. Oh, yeah, no, that's never been a problem with any other RM. No, that's a classic problem, right? So things like that as well, we're just now about to release an email integration where you can use a built-in thing with Redwood to create and send emails. So you hook it up with an external email sender. But part of the Redwood Studio will also be able to run an app.

 

Dan (58:17.813)

Hahaha

 

Charles Max Wood (58:18.74)

Right.

 

AJ (58:20.277)

Rails never had that problem. Never, never.

 

Tom Preston-Werner (58:46.566)

an SMTP server and locally and be able to send your emails there. So you're getting a full real life cycle, actual email sent from your Redwood JS app into Redwood JS Studio, where you can see what emails are being sent as you're doing development. So we're working on a lot of these sort of additional tools that are going to make your life easier as a developer. Things that you would otherwise have to go, you know, use some other random tool, pay for. They just be.

 

separate, we're trying to bring those kinds of things in to Redwood itself. And I'm super excited about that. It's just going to make your life as a developer so much easier.

 

Dan (59:22.967)

And in terms of deployment targets, do you support everybody?

 

Tom Preston-Werner (59:28.926)

We support quite a few deployment targets right now. So you can deploy on Netlify and Vercel serverlessly. You can use a serverless framework with Amazon. You can use Amazon directly. You can deploy to bare metal if you have your own server co-located somewhere, or this works on AWS as well. But we have a strategy called bare metal, where you're just deploying straight to a machine, and you're maybe using PM2 or something to keep them up, but you're managing the whole thing.

 

Tom Preston-Werner (59:58.926)

fly.io. We're working on making the Docker deployment stuff work much better and be much faster. So that's been an ongoing development, but anywhere that you can use Docker, you can deploy Redwood too. So there's a ton of, you can go to the website and find the full list of providers, but we've worked really hard with different deployment providers to make it super easy. We're really trying to help you avoid lock-in, vendor lock-in. We want you to be able to move from vendor to vendor.

 

And so that's why we've worked with these vendors. And, you know, this is another philosophy of Redwood, is trying to go further than Rails ever did. So we integrate authentication from the get-go, as well as deployment, things that Rails has never really touched. Trying to say, what's the full life cycle of building and deploying and maintaining a web application today in the JavaScript and TypeScript world, and adding all the necessary things to do that well?

 

Charles Max Wood (01:00:53.827)

Yeah, I do have to say that a lot of the rail strategies are still, I mean, you can use Qubi, which will push to Kubernetes, but yeah, otherwise you're still using Capistrano, which sometimes you need a crystal ball to figure that out.

 

Tom Preston-Werner (01:01:09.798)

Well, they have a new thing now, right? MERSC. Check that out. Nor have I, but it's their new thing. Go ask chit chat, chat.gpt. Yeah. But yeah, I mean, these things are hard, right? Deploying is hard. Getting your authentication set up is hard, right? You don't want to have to go just find some random library to do it. It's much better if the framework can say, hey, you want to use clerk. Here's how you do it.

 

Charles Max Wood (01:01:14.327)

I haven't used Mersk.

 

AJ (01:01:17.653)

GPT will educate us.

 

Dan (01:01:23.452)

Hahaha

 

Tom Preston-Werner (01:01:38.89)

Right? And we talk to Clark all the time and we make sure that it works properly.

 

Dan (01:01:43.415)

One of the biggest motivations for actually using a meta framework, as it were, and these days I think unless you're like a big organization that has very unique and special needs, then you should be using a meta framework. And one of the big motivations is the whole deployment story, because you don't want to deal with deployments on your own in most cases, like...

 

We do where I work at Next Insurance, but we can afford to because we have an entire DevOps department. And that's not something that most organizations can or even want to deal with. It's just not cost effective. In that context, what do you think about edge computing?

 

Tom Preston-Werner (01:02:31.198)

I think there's a lot there. Early on in Redwood, I wanted Redwood to be kind of an edge framework. But again, the realities of lambdas and things and the way that we were doing GraphQL made that pretty challenging. But there's a lot of cool things that you can do on the edge. Now, I don't know that that's going to be the main sort of infrastructure that you use to build a SAS application. But using them to enhance.

 

users' experiences and make things faster for them and do customization for them, right? You know, like last minute before they get the actual HTML from your server. There's some really cool things you can do there around localization and caching and other types of enhancements. So I think we're just, we're still figuring out what that means. Like where do those things add more to the user's experience?

 

then they add complexity to your life as a developer and maintainer, because it's non-zero.

 

Dan (01:03:29.791)

Exactly, exactly, exactly. I'm so happy you said that. I mean, so many times you hear people referring to edge computing as this kind of a silver bullet or like an amazing technology that makes everything better. And it does address some specific use cases amazingly well, but at the end of the day, it does come, as you said, as extra complexity because it's not the front end, it's not the back end, it's another layer that you need to contend with.

 

AJ (01:03:44.341)

So I did.

 

Tom Preston-Werner (01:04:00.446)

Yeah, and I think the main challenge that developers have, really, maybe the developer's only job is to manage complexity. Like if you have a long-term project, like a company, a startup, whatever you're building, some large project, at the end of the day, managing complexity, from the technical side, of course you need to build a product that people actually want to use. But from the technical side, managing complexity is what we as developers should be doing. A good developer manages complexity.

 

That's what makes something maintainable.

 

Tom Preston-Werner (01:04:33.946)

And people overcomplicate things all the time. We love to be architecture astronauts, right? Like we love building complex stuff. We love building the blockchain. Man, do we love building the blockchain, right? But then we're like, and now let's use it for everything. And of course that's not the right solution, right? That's way more complexity than you really need to solve most problems. And I think many people need to remind themselves of that is that starting out, go for the least complex.

 

Dan (01:04:36.362)

Ha ha!

 

Yeah.

 

Charles Max Wood (01:04:51.488)

Yeah

 

Tom Preston-Werner (01:05:02.67)

possible solution to your problem and build up from there. Every working complex thing started as a working simple thing.

 

Dan (01:05:14.883)

Such an amazing statement. Totally agree with you. And I guess that really drives, I think that drives a lot of your decisions around Redwood, right? Because you're assuming on yourself a lot of the complexity so that the person using the framework doesn't need to deal with it.

 

Tom Preston-Werner (01:05:17.982)

It's not mine. I stole that from someone. I don't know who. I'm sure you can find it. I paraphrase. But I think it's true.

 

Tom Preston-Werner (01:05:37.834)

Yeah, exactly. It allows you to go further faster because building a website is complex. Like there's some minimum level of complexity that you're going to get to. If you have to build all of that complexity yourself, then you have to go through all those stages of first creating something very simple, right? Like, and this is the path that if you choose Next.js that you're probably choosing, is you choose that simplest thing, Next.js by itself. And then you're like, all right, now I need authentication so I can add user accounts. Okay, now I need...

 

Charles Max Wood (01:05:43.96)

Mm-hmm.

 

Tom Preston-Werner (01:06:07.01)

to add testing because this is complicated enough and I have to add that. Like every step of the way, you're adding complexity one step at a time. We're hoping with Redwood JS that we can add that complexity for you and go through the steps of turning it from a simple working thing into a more complex working thing that you would have to do yourself anyway, but that we've already done it. And when you're ready for those things, like if you're ready for GraphQL,

 

Instead of being like, all right, well, let's evaluate GraphQL server choices. It's just like, oh yeah, GraphQL is built into Redwood. Let's just use that.

 

Charles Max Wood (01:06:47.227)

Cool, we're getting toward the end of our time. Is there anything else you want to make sure people know about?

 

Tom Preston-Werner (01:06:51.514)

I would love for people to know that we have a conference and I'm actually not sure when this will be airing. So it may not be much notice, but we do have, we will have tickets online. So Redwood JS conference, the first Redwood JS conference, um, will be September 26th through 29th in, uh, Grants Pass, Oregon, United States. It will also be streamed online. So you can go to redwoodjsconf.com and you can pick up your online tickets there.

 

Dan (01:06:52.039)

Thanks for watching!

 

Tom Preston-Werner (01:07:19.878)

or your in-person tickets if there's still time. And we're gonna be collecting together a really great group of people in and around web application development. So it's more than just Redwood. Redwood's really an excuse to be there. It's really about everything that you need to build and scale a web application. So we touch on security, GraphQL, of course, design. We have one of the great designers from GitHub is coming.

 

We have an executive coach who's coming. Like if you're building a company, you'll hear from someone who is really great at teaching you how to do that well. So we have people from all sort of different walks of life, AI, and we have some workshops as well. There's gonna be an Apollo, an advanced Apollo workshop, a Prisma workshop, and an AI workshop. There's a workshop where you can spend time with myself and one of the other Redwood JS founders to talk through your startup if you're using Redwood JS

 

if you're looking at using Redwood JS, where we can give you advice on building a company or otherwise using Redwood JS. As well as two days of talks in the middle, 27th, 28th, and then an optional sort of fun day on the last day in Oregon where we'll go ride mountain bikes or go on a hike or do some other kinds of tours or just hang out at the conference venue and chat. So it's gonna be an awesome time. I'm super looking forward to it. And I'd love for you.

 

to join us one way or another. Check it out.

 

Dan (01:08:50.191)

Sounds awesome, I'm envious.

 

Charles Max Wood (01:08:52.891)

Yeah.

 

Tom Preston-Werner (01:08:53.494)

Get on that plane from Israel, man. It's not that far, right? It's only like 15 hours.

 

Dan (01:08:56.587)

Yeah, not that far at all. Yeah, more or less.

 

Charles Max Wood (01:08:57.851)

haha

 

Charles Max Wood (01:09:02.808)

Yep. I have one more question and I'm just curious. I remember when Microsoft bought GitHub and I think you own like half of Microsoft now. I'm just curious, right? I'm imagining what that looked like. And I'm also imagining that this isn't something you have to do in order to make a living. What motivates you to keep this going? Is there some other thing that...

 

Tom Preston-Werner (01:09:12.974)

Hahaha

 

Charles Max Wood (01:09:32.131)

I don't know. What's motivating you to do this at this point?

 

Tom Preston-Werner (01:09:36.178)

Well, I just, I love building things. It's the thing that I love the most, right? I mean, I didn't build GitHub to make a bunch of money. It did, and that's nice, but that wasn't the reason. And money has never been the reason that I build things. I build things because I love solving problems and I love making people's lives easier. And I love giving people opportunities. And so that's part of this for me as well is building a community. We started this right at the beginning of COVID and it was really pretty awesome.

 

So many people I know are like, man, it's so hard to make friends. Like I just like, how do you make friends in your thirties and forties? And I'm like, man, I make new friends all the time through open source, like just doing Redwood JS. I know so many more people around the world that are amazing. And I have a great time doing it with them. I love creating cool things with my friends and you know, I can do more of that. I can support more of this. And you know, a bunch of, we have people working full time on.

 

Redwood, there is no company, there is no Redwood JS organization, corporate entity, kind of by design. I kind of wanted to see what we could build as an open source project if funding it wasn't the main concern. So I fund it myself. And I do that because it's an exploration into what that could look like, what that community could be like. How can we align ourselves with the users of Redwood in a way that we're not just trying to extract value from the users as a...

 

as a corporate entity. This is not to say that I wouldn't love to make money from Redwood JS someday. I think that would be nice. But it's important to me to find the right kinds of ways. I do invest in companies that use Redwood. I have a fund. I do a lot of angel investing. And I set aside a million dollars to invest in companies that use and are building with Redwood JS. You can go to Redwood JS, what is it? Redwoodstartupfund.com and you can read about that.

 

AJ (01:11:26.15)

Oh.

 

Tom Preston-Werner (01:11:32.242)

But I love investing in the community. I love the ideas that people are creating and building with Redwood and being a part of that journey. Um, whether we invest in someone or not, we have a Slack channel where we get all the startup founders together and we run monthly meetings and chat all the time about building companies and it's just such a nice way for me to stay involved in the startup scene and, and creating something cool and like JavaScript and TypeScript is, is so big and powerful and where it's going.

 

And I would love to be a part of the vanguard of defining what that is. Cause I love writing code. I love building websites. There's so much power there. And to be a part of that journey to me is immensely satisfying.

 

Charles Max Wood (01:12:13.339)

Very cool. I did have one other question that I wanted to throw at you with this is you mentioned stuff around building mobile apps with React Native. So I'm wondering, I mean, this, you know, I've been playing with Redwood, right? So you've got your web directory and then you've got your API directory and the API directory is your backend and your web is your front end. I guess my question is, do you just...

 

create a separate repo for the React Native app and then just point it at your API and use the same APIs or does it work any different?

 

Tom Preston-Werner (01:12:51.582)

Yeah, essentially, you could put it in the same repo. I mean, we've toyed with the idea of creating an official kind of mobile application side using React Native. It's something that we will probably do eventually. Uh, you know, that adds a lot of complexity to the project, like supporting a whole other side. So we haven't endeavored into that yet, but I think it would be really cool to be able to say like, oh, you want to use Redwood to build your web application, we'll also use it to build your, your mobile application.

 

Charles Max Wood (01:13:08.422)

Yes.

 

Tom Preston-Werner (01:13:20.718)

because it's going to integrate really well and here's where your GraphQL goes. And yeah, it should be that simple, right? Because with GraphQL, everything integrates and there's clients for every language, whether you use React Native or Swift or whatever, like consuming GraphQL is really, really easy. So we try to make building your GraphQL API as easy as possible. I think the easiest that you could do it. I don't know of any implementation of a GraphQL API that's better than ours.

 

Charles Max Wood (01:13:49.915)

Awesome. All right, well, I'm gonna push us toward picks and wrapping up. Yeah, let's go ahead and do the picks. Steve, what are your picks?

 

Steve (01:14:03.988)

So before I get to the high point of every episode, my dad jokes, I do have one pick. Dan, in your history, Israeli history, do you know the name Ailey Cohen? Okay, so I've been watching a Netflix special called The Spy, and it's about Ailey Cohen. Yes, yeah, you just stole my thunder. So yes, it's about, Ailey Cohen was an Israeli spy.

 

Dan (01:14:14.851)

Yes, of course.

 

Dan (01:14:21.063)

This is Sasha Baron Cohen.

 

Steve (01:14:31.568)

embedded in Syria from 1961 to 1965. And the story doesn't exactly have a happy ending, but he was very pivotal in a number of things that he was able to help the Israeli military with. But the interesting part about the episode is, as Dan mentioned, the lead actor, Sacha Baron Cohen, and for the most, Cohen, excuse me, Ailey Cohen, you know, most people know him for like the Ali G show or Borat.

 

those movies and he's more of a comedic actor, but in the serious role, he's really quite good. And it was really a well-done episode. I'm only, there's one episode left that I have to watch. There's six episodes. It was a short run series that came out in 2021 on Netflix. But I did some reading on Wikipedia about him and some of the things he did. And it's pretty historically accurate. The show is as well based on what I've seen. So really great show.

 

So my dad jokes of the week sort of have a theme of interactions with my wife. And I just realized that I've navigated away from my page here. So recently my wife and I were talking about, you know, as we get older, we're talking about what we want to happen when we die and she asked me why I wanted to be cremated and I said, well, it's my last hope for a smoking hot body.

 

Dan (01:15:54.982)

No.

 

Steve (01:15:57.568)

And going back in time when we had little ones, I have three kids, when I came home from work one day, my wife said, man, the baby's been crying for hours. Can you take over? I said, sure. And I started crying for hours.

 

AJ (01:15:57.844)

Alright.

 

AJ (01:16:15.201)

That was a little better.

 

Steve (01:16:18.396)

And then finally, recently her cat died. She's always been a real big person with cats. And started to cheer her up. I went out and got her an identical one. And she said, what am I gonna do with two dead cats?

 

Steve (01:16:35.892)

Those are my picks.

 

Charles Max Wood (01:16:37.607)

All right, Dan, what are your picks?

 

Dan (01:16:41.611)

Okay, so first of all, I finished watching the Peacemaker show. It's okay. It's nice. I'll pick it. Action, kind of stupid, but you know, it seemed like there was supposed to be some social message or something with it. But if there was, I didn't really get it.

 

So it is what it is. But you know, fun action more or less. I also already picked it, but I'm gonna pick it again, a book series that I'm reading. It's called The Faithful and the Fallen. It's a fantasy book series, four books, and it's complete, which is a big advantage for me, because I hate it when it turns out that I have to wait an infinite amount of time.

 

for the next book in the series to actually come out. So having one that's actually done is a big plus and I'm enjoying it. It's not like super deep, but you know, lots of interesting characters, lots of action and adventure and whatnot. So it's, I recommend it. And yeah, that and the ongoing war in Ukraine where you should support the people of Ukraine. Those are my picks for today.

 

Charles Max Wood (01:18:10.883)

All right, AJ, what are your picks?

 

AJ (01:18:15.581)

Well, I've got some good ones here. So I've been perusing the Redwood Docs while we were on the podcast here. And I found a quote in the intermission chapter that I thought was quite great. If you enjoy switching between feeling like the smartest person on earth and the dumbest person in history in the same day, programming may be the career for you. So appreciate your.

 

your humor there on that one. Also, since we have Tom on. And I think that Simver has solved. An incredible number of problems. I think, I think Simver is one of the, in the increasing world of complexity that we face where every day there's a new framework and you know, even Redwood itself is on version 6.7 and

 

If you look in your dependency tree, you're going to see a lot of things that are on version 32 or 67 or, or whatever. Uh, Simver is sane and practical. And I have occasionally come across, I think maybe in my, my career come across two or three people that have some sort of argument against it, but I think that they're insane, um, because it's just.

 

Tom Preston-Werner (01:19:36.558)

I'm sorry.

 

Charles Max Wood (01:19:37.851)

Hehehehe

 

AJ (01:19:38.957)

It is it is a necessary tool and so I pick Simver and I thank you for uh Bringing some of the sanity to counteract all of the insanity that you brought to us with allowing people to create social coding

 

Tom Preston-Werner (01:19:45.202)

All right. Great choice.

 

Tom Preston-Werner (01:19:59.267)

Create the disease and the cure.

 

AJ (01:20:01.953)

Yes, yes, I appreciate that you provided a simple cure as well and then To two other things You know right next to anything about cryptocurrencies. I think the next biggest scam is Fulfilled by Amazon and similar programs like affiliate marketing fulfilled by Amazon, you know all that I that's

 

That's I don't know in the Ponzi scheme scam MLM rankings. I definitely think cryptocurrency has taken number one for at least the past five years. And I think that FBA and friends have been at around number two. And I'd love to hear if somebody thinks something else really is vying for that spot. But I have a friend who decided to get into FBA and.

 

I obviously was questioning, are, have you joined a cult? Uh, are you going bankrupt? Uh, so, so I don't know if the specific program is a, uh, one of the scams or not. I suspect it might be, but I, in doing some research to share, I did find that there is at least one person who has had.

 

Uh, honest success with it. And so I'm including a link to this video. It's called, I tried Amazon FBA for six months, the honest results. Now problem is that you really need to know what happens over 12 months because, uh, there's a lot of forces at play. So for example, once you have a product listed and it's ranking higher than a similar company in China is going to just contract with that company because they don't really have the copyright law and everything and you're small.

 

And you know, and then they're going to steal your product and then whatever your product was, assuming that you weren't just white labeling, because this guy, you know, speaks honestly about the evils of white labeling and, you know, the things that are guaranteed that you will only lose money. But even with the passion product approach, which sounds like a very reasonable approach, I questioned what happened after, you know, 12 months or 18 months, but basically the guy was able to break even after about six months.

 

AJ (01:22:24.989)

And then ostensibly based on the six months experience was able to make one or $2,000 a month in actual. Profit. Well, he didn't discuss taxes. So I think you got to take taxes out of it, but you know, around, around a thousand dollars in profit. And so his goal was I'm going to pay for my single dude rent. And he was able to meet that goal, which I think is a lot more, um, realistic than.

 

You know, these people saying that you're going to make a million dollars when really it's, if you are in the top 0 1% and sell a million dollars, only 15% of that is your profits after all of the Amazon taxes. And so you're not like you're making, you're making good money, you know, you're making a hundred thousand dollars, whatever. Uh, but it's, you know, you're not making a million dollars.

 

And then the last pick will be Susanna Venker, who is a relationship coach whose slogan is be counter cultural. Um, and I just came across some of her, her stuff, her podcast, and I've been listening to a few episodes and it's, uh, it's, it's bold and based.

 

Charles Max Wood (01:23:45.127)

Okay, I'm gonna throw in my picks here real quick and then we'll get Tom's. The first one I'm gonna pick, I don't remember if I picked this last time I was on, so I'm gonna pick it again and if you get it twice, you get it twice. But my buddies and I have been playing Risk Legacy. This is my board game pick. I do a board game pick every time. But I was out of town last week and so, anyway, it's been fun. We've done one playthrough, I won. I just point that out.

 

But yeah, it was a lot of fun. If you played Risk, it's kind of a different take on it. Obviously it's a legacy game, right? So you're marking up the board and, you know, I think you tear up some cards and stuff at some point. But anyway, it's just the three of us and we've really been enjoying it. So I'm gonna pick that. And then my wife and I and my kids have all gotten into Wednesday. It's the Netflix series based on The Addams Family.

 

and we're enjoying that. So I'm gonna pick that as well. And yeah, the last pick I have, so I drove out to Denver and back to podcast movement. That's where I was last week. And there are probably gonna be some changes to the show going forward, cause I picked up a whole bunch of different things that should help us grow, help make the show a little bit, flow a little bit better and get you into it a little faster and things like that. So keep an eye out for that, but.

 

When I drove out, I drove out I-70 through Grand Junction. And the highway between Grand Junction and Denver is just gorgeous. And so if you ever wind up driving up through there, up through Vail and Breckenridge and all that stuff. Anyway, it's well worth it and I really, really enjoyed it. So I'm gonna pick that. Tom, what are your picks?

 

Steve (01:25:39.828)

Hey Chuck, can I tell a quick story? This is so funny about that exact highway. I flew into grand junction one time and was going to Alpine, which is a, you know, going up on the West slope toward it was the, this is a business trip long time ago and somehow I got going the wrong direction. And so I'm driving along looking for the signs from Breckenridge and Alpine or whatever, and I keep seeing this line that says Utah state line coming up. Like, is that a town or something like that? And then I finally realized, Oh, I'm at the Utah state line.

 

Charles Max Wood (01:25:47.652)

Uh huh.

 

Charles Max Wood (01:26:07.012)

went the wrong way.

 

Steve (01:26:07.984)

I went there and this is the middle of the night, you know, in place where I have never been. So it cracks me up every time I think about Grand Junction.

 

Charles Max Wood (01:26:15.439)

Yeah, there's nothing out there between, so when I drive down, I go down highway six and then merge on, I don't take I-15 all the way down. And yeah, there's nothing there. There's nothing there between Green River and Grand Junction, so.

 

Steve (01:26:29.482)

Yeah.

 

Charles Max Wood (01:26:32.391)

Alright Tom, what are your picks?

 

Tom Preston-Werner (01:26:34.214)

All right, my picks. Okay, well, your board game pick reminded me of Monopoly, which is one of the worst games of all time. I hate it with all of my being. But did you know that there's a card game version of Monopoly called Monopoly Deal that one of my friends brought on a trip that we went to recently and we played it a bunch, and it's actually delightful. So if you...

 

Charles Max Wood (01:26:43.303)

Ha ha

 

Steve (01:26:46.623)

Hahaha.

 

Tom Preston-Werner (01:27:03.386)

Resented my previous statement and you're like monopoly is awesome Then you might really especially love monopoly deal because it's monopoly esque but in a way that takes a finite amount of time It's like a 15-minute game. It's pretty quick. Like there's like properties and stuff, but it's not really about you know, it's different It's nice. It's just a nice card game. It's a quick fun card game. I Like it AJ is saying something, but I can't hear it

 

Charles Max Wood (01:27:28.271)

Yeah, I'll just try, I'll jump in on that one really quickly. So the one thing I didn't do is put out the board game geek weight on Risk Legacy, which is 2.59, which kind of gets a little bit to the complicated side. Monopoly deal is weighted at 1.08. So it's fast and it's easy enough that your kids can probably play it with you.

 

Tom Preston-Werner (01:27:48.306)

Yeah, it's fairly simple. That's a nice one.

 

AJ (01:27:50.485)

So the thing I was going to ask is have you ever played Monopoly actually by the rules?

 

Tom Preston-Werner (01:27:56.79)

I generally play it by the rules and it takes 19 hours. Am I not playing it by the rules?

 

Dan (01:27:59.979)

Yeah, have you ever played monopoly to completion? It's like the question is, have you ever played monopoly to completion?

 

AJ (01:28:00.678)

Oh, okay.

 

Tom Preston-Werner (01:28:07.908)

Has anyone ever played Monopoly to completion?

 

Dan (01:28:10.416)

No.

 

AJ (01:28:10.761)

Well, I what I was going to say is monopoly actually goes quicker without all the house rules. So everybody has all these things that are culturally they do, but that are actually not part of the rules. And if you play it by the rules, it actually goes much quicker. Now, it's not going to be a 30 minute game, but it might be less than two hours.

 

Charles Max Wood (01:28:11.874)

I have, but.

 

Tom Preston-Werner (01:28:13.879)

Ha ha.

 

Steve (01:28:14.132)

Yeah, I have.

 

Tom Preston-Werner (01:28:21.066)

Right?

 

Tom Preston-Werner (01:28:30.45)

My problem is that there's really only one strategy in that game. You have to aggressively purchase everything. And that's like the only strategy, and I just don't like games where there's, you know, like if you if you don't play by that strategy, then you are basically screwed. And there's too much luck. I don't like that there's just too much luck in the game anyway.

 

Steve (01:28:30.72)

Oh yeah.

 

AJ (01:28:49.397)

Chuck, what's the game where you have a bunch of different types of assets and every turn you get to either take some assets or spend some assets to acquire assets? It's a cards. There's I mean, there's probably so many that are like that.

 

Charles Max Wood (01:29:07.755)

I've played so many games that have that element to it.

 

Dan (01:29:10.103)

Every game ever?

 

AJ (01:29:10.857)

But no, but there's a popular one. No, there's a popular one. It's card-based. I think it's card-based because you pull a card, you flip a card over. I think you can flip two cards over at a time and you can use up to two of them. And then when you're done with your cards, they go back and you rotate through. I mean, that sounds like every card game, but there's a board and there's stuff. There's gold. There's gold and...

 

Tom Preston-Werner (01:29:12.916)

Hahaha

 

Charles Max Wood (01:29:13.655)

You think of like Settlers of Catan or something?

 

AJ (01:29:37.753)

A good naive strategy is to just get as much gold as you can at the beginning of the game.

 

Dan (01:29:43.207)

Cones of Dunshire?

 

AJ (01:29:44.057)

I, it's, it's a really popular one among people. And that might be it. That sounds like that could be it.

 

Charles Max Wood (01:29:48.772)

like Splendor or something.

 

Charles Max Wood (01:29:53.595)

But Splendor is strictly cards, I think. I don't think it has a board.

 

AJ (01:29:57.981)

Oh yeah, this one has, it has a, an area where I think cards are placed or maybe you put the cards out in front of you. Maybe there isn't, but anyway, I was going to say that one is one where you are gathering stuff, but there is a variety of strategies that can win. I, sorry, I can't think of the name of it.

 

Charles Max Wood (01:30:16.015)

Yeah, so no, it's all good. But yeah, if you are looking for a fun game, Splendor is definitely worth it. And it's a pretty easy casual game. It only goes up to four players. So if that's an issue for you, but yeah.

 

Tom Preston-Werner (01:30:34.262)

All right, well, I'll give you one more pick and then we can, maybe we can be done. Let's see, I was on a boat trip recently and we had a drone, so I haven't bought a DJI drone in forever, I don't know if any of you all are into buying drones.

 

Charles Max Wood (01:30:36.57)

Yeah.

 

Tom Preston-Werner (01:30:53.426)

I have a really old DJI Mini of some sort, and it's great, but it's loud as hell. That thing is just like a monstrosity of loudness. I haven't bought one in probably almost 10 years, and so I recently got the DJI Mini 3, and it's so light and so quiet. It's just unbelievable to me. And that company in general, everything that they make.

 

Their products are just astoundingly good. The hardware is just unbelievable. So that's my pick is this mini, what's it called, the mini three. It's like the battery, even the batteries are like, you're like, is there something in this battery? Like the batteries aren't even heavy. It's just wild. And it gets like 20 minutes of battery life or something, 25 minutes. It's really, it's astounding. And the picture quality that it takes is the best. And the kinds of footage that you can get, you take it on vacation and you can just make these, take this footage that...

 

It's unbelievable. It's just so cool that like we just like, you know, you can buy this, it's like a thousand bucks, maybe a little less if you don't get the whole kit or whatever. For like a thousand dollars, you can get this kind of aerial footage that, you know, you would have needed a helicopter before. And it's just so neat. I just love that that's a thing now. So that's my pick.

 

Charles Max Wood (01:32:13.323)

Awesome. All right, I guess we should have asked this earlier, but if people wanna go check out Redwood or see what the latest and greatest is, where do they go do that?

 

Tom Preston-Werner (01:32:22.966)

Go to redwoodjs.com. That's the website. And you can find our various communities there. We have a discourse forum. We have a discord server and we're on X, I guess we call it now. So we have that as well. You can find us there. Those are the best ways.

 

Charles Max Wood (01:32:42.831)

Awesome. Well, thanks for coming and spending some time with us and talking through some of these ideas behind Redwood and some of the updates that are coming. Yeah, I've kind of, like I said, I've been fiddling with it some. This is definitely appealing to me. There are some things here that I like. So, yeah, maybe we'll have you back on, dig a little deeper or see where things go from here.

 

Tom Preston-Werner (01:33:07.21)

Sounds good, really appreciate you having me and thanks for the lively discussion.

 

Dan (01:33:11.139)

Yes, it was a great discussion. I really enjoyed it a lot, learned a lot. Thank you for coming on.

 

Charles Max Wood (01:33:11.351)

Yeah. All right, folks.

 

Tom Preston-Werner (01:33:17.004)

Awesome, you bet.

 

Charles Max Wood (01:33:17.379)

Yeah. All right, till next time, folks. Max out.

 

Dan (01:33:20.635)

Bye.

 

Steve (01:33:20.688)

Adios.