Bringing Fullstack to the Jamstack with Tom Preston-Werner

Episode Description

Tom Preston-Werner discusses the journey from Jekyll to GitHub to Redwood JS, exploring how full stack Jamstack frameworks simplify modern web development.

Episode Summary

In this episode of FSJam, Tom Preston-Werner traces the evolution of his thinking from creating Jekyll, one of the earliest popular static site generators, through his work at GitHub, to his current project Redwood JS. He explains how the concept of "full stack Jamstack" emerged from Netlify's serverless capabilities, which inspired him to imagine building complete web applications with databases on Jamstack architecture. Tom describes how his language learning company Chatterbug served as a proving ground where he and co-creator Peter discovered powerful patterns combining React, GraphQL, and backend services, but found the JavaScript ecosystem lacked the cohesive developer experience that Ruby on Rails provided. This frustration drove them to build Redwood JS, a framework that makes opinionated choices about tooling and integration while still allowing developers to swap components as needs evolve. The conversation covers Redwood's scaffold generators, its GraphQL-based architecture that enables multiple client applications, the framework's naming history from Chainsaw to Hammer to Redwood, and the vision of a future where developers can spin up web, mobile, CLI, and even VR clients all consuming the same backend API.

Chapters

00:00:00 - Introduction and the Origin of Full Stack Jamstack

The episode opens with hosts Anthony Campolo and Christopher Burns introducing Tom Preston-Werner as their guest. Tom explains how the term "full stack Jamstack" originated from Netlify's static hosting and Lambda function capabilities, which got him thinking about building complete web applications with databases using Jamstack architecture rather than just assembling third-party APIs with static sites.

Anthony draws a colorful analogy comparing Redwood to a genealogical mix of Ruby on Rails, Jekyll, and React. This leads into a discussion about Jekyll's history, including its original name "Autoblog," and how it fit into the broader landscape of static site generators that now number in the hundreds across every programming language.

00:03:25 - Jekyll's Naming and the Problem It Solved

Tom reflects on why he renamed Autoblog to Jekyll, explaining his love for creative naming and the connection to transformation, inspired by the story of Dr. Jekyll and Mr. Hyde. He describes the core problem Jekyll solved: losing blog content stored in self-hosted WordPress databases that required constant maintenance and attention he wasn't providing.

The conversation explores how Jekyll was designed to let developers write Markdown files in a Git repository and convert them to static HTML, optimizing for author efficiency by removing every excuse not to write. Anthony connects this to his own experience reading Tom's famous blog post "Blogging Like a Hacker," describing it as a defining moment that shaped workflows still used today.

00:07:18 - From Chatterbug to Redwood's Genesis

Tom describes how Chatterbug, his language learning company co-founded with former GitHub colleague Scott Chacon, began as a standard Rails application using jQuery. The team gradually adopted React for the frontend after bringing on developers with React experience, including Peter Pistorius, who would become a Redwood co-creator. Tom shares his own journey of learning React after multiple failed attempts, eventually falling in love with its one-way data flow paradigm.

As Chatterbug evolved to use GraphQL as its API layer with React components doing their own data fetching, Tom and Peter recognized powerful development patterns emerging but lamented how long it took to arrive at them. The lack of best practices and the overwhelming number of choices in the JavaScript ecosystem made Tom yearn for a Rails-like experience where everything is laid out clearly, motivating the creation of Redwood.

00:12:15 - Framework Philosophy and Integration

The discussion turns to Redwood's core philosophy of handling integration work so developers can focus on what makes their applications special. Tom emphasizes that while there will always be many ways to build something, the real value lies in having technologies that work beautifully together out of the box, from Storybook integration to testing fixtures that automatically set up and tear down database state.

Christopher and Tom discuss how users don't care about underlying technology, reinforcing that what matters is getting from idea to working application quickly. Tom draws parallels to Rails' greatest strength — seamless internal integration — while arguing Redwood aims to go further by including authentication, authorization, and other features every real application needs, reducing the boilerplate and custom integration work that slows teams down.

00:17:00 - Scaffolding, Flexibility, and Swappable Components

Tom explains Redwood's scaffold generators for CRUD operations, noting they're designed to actually be used in production code rather than just for prototyping, thanks to GraphQL's structured approach. The conversation addresses comparisons to Rails' monolithic reputation, with Tom clarifying that Redwood aims for strong integration without tight coupling, allowing components to be swapped through well-defined interfaces.

A concrete example emerges around GraphQL libraries: Redwood currently ships with Apollo but is experimenting with lighter alternatives, and the architecture allows developers to swap providers through a simple interface specification. Tom frames this as providing a "happy path" that isn't secretly oppressive, where developers maintain free will to make different choices as their needs evolve.

00:21:38 - Team Size, Deployment, and Scaling

Christopher asks about ideal team sizes for Redwood projects, and Tom suggests 10 to 20 people as optimal for most projects, emphasizing how small teams of specialists can move quickly with low communication overhead. The conversation touches on Redwood's deployment flexibility, supporting Netlify, Vercel, AWS, and eventually other cloud providers, all selectable through a single command.

Tom and Christopher discuss how Redwood serves both solo developers who need to generalize and larger teams with specialized roles. Tom explains that Redwood is designed to scale from weekend hack projects to mature applications, drawing parallels to how Rails powered GitHub and Shopify. He stresses that choosing GraphQL means slightly more upfront work but pays off in long-term organizational clarity and reduced complexity.

00:27:36 - Multi-Client Vision and the Future of Redwood

Tom outlines Redwood's vision for supporting multiple client applications beyond the web, including mobile apps, command line tools, and even VR applications, all consuming the same GraphQL backend. He explains how the explicit decoupling of frontend and backend via GraphQL future-proofs the framework against shifts in frontend technology, allowing new "sides" to be added without rewriting backend logic.

The discussion draws on Chatterbug's pain point of maintaining two separate backends when adding a mobile app alongside the web application. Tom argues that a standardized GraphQL API consumed by multiple clients eliminates this duplication, and as Redwood matures, generators and setup commands will make spinning up new client types as easy as the current web development experience.

00:34:01 - The Many Names of Redwood

Anthony reveals that Redwood has gone through at least four names, prompting Tom to tell the entertaining story of each iteration. Starting with "Der Spielplatz" (German for playground), a test repository for a Yelp-for-playgrounds idea, the framework was first properly named Chainsaw, then Hammer — which Tom loved for its German slang meaning of "awesome" and its connection to Thor's mythological hammer.

Tom explains the practical reasons for the final rename: discovering that Thor's hammer symbology had unfortunate associations with white supremacist groups, and more critically, that an existing popular project called Hammer.js would cause confusion on launch. After brainstorming dozens of alternatives and checking npm for conflicts, Tom landed on Redwood, drawn to its nature-themed contrast with the atomic-energy naming conventions prevalent in the React ecosystem.

00:39:11 - Redwood Trees, Nature, and Closing Thoughts

The hosts and Tom discuss the properties of actual redwood trees, including their fire resistance and evolutionary adaptation to thrive after forest fires — a fitting metaphor for resilient applications. Tom explains his attraction to naming the framework after something in nature as a deliberate contrast to the physics-inspired naming trends in the React ecosystem, appreciating the contrarian surprise it offers.

The episode wraps with heartfelt exchanges as Anthony shares how Redwood has been life-changing for his career, and Tom expresses gratitude for the community that Christopher and Anthony are helping build. Tom emphasizes that his favorite thing is helping people turn ideas into reality, and he hopes Redwood serves as a vehicle for that creative empowerment.

Transcript

00:00:00 - Christopher Burns

Are we gonna have intro music?

00:00:02 - Anthony Campolo

Yes! Dude, I'm a musician.

00:00:16 - Christopher Burns

What's up, Jammers? Welcome back to episode four of FSJam. On this episode, we've got an incredible guest, Tom Preston-Werner. Some of you may know him from GitHub, but we're going to speak to him about what he's up to now with Redwood JS. All right.

00:00:34 - Anthony Campolo

Good to go. Well, thank you, Tom, for being here. We're really excited to have you here on the show. Welcome to the Full Stack Jamstack podcast. You probably had a little bit to do with the name of this podcast, because the first time I heard of Full Stack Jamstack was for Redwood JS. Why don't you tell us where that term came from?

00:00:55 - Tom Preston-Werner

Thanks, and happy to be here. Full Stack Jamstack comes from some ideas around what Netlify was producing. They've had the ability to do static site hosting for quite a while. And then a few years ago, they added the ability to easily get Lambda functions up on AWS by just putting your code into a certain directory in your Git repository and pushing that to Netlify.

It got me thinking about how we could use that same technology to build full web applications with a database, so a full stack application, as we normally think about it. That turned into the ideas for Redwood. We started talking about full stack on the Jamstack because the Jamstack normally isn't used in that way. You're not using a database and writing your own logic. You're assembling third-party APIs and connecting them to your static React site, or just static HTML.

Really, it was around the idea that maybe we could use that same architecture for full stack applications, and so it seemed like a natural name.

00:01:56 - Anthony Campolo

I find it to be an interesting combination of all of your influences coming together. I once described Redwood as Ruby on Rails and Jekyll had a baby, and then that baby and React had a baby, and that baby is Redwood JS.

00:02:11 - Tom Preston-Werner

Yeah, that sounds about right.

00:02:13 - Christopher Burns

Is it sad that I've never once used Jekyll or Ruby? I'm just a JavaScript kid.

00:02:19 - Anthony Campolo

I don't even know if you're qualified to be here.

00:02:21 - Tom Preston-Werner

Burns, if that's the case.

00:02:23 - Christopher Burns

Sadly not.

00:02:25 - Anthony Campolo

There's so many, right?

00:02:26 - Tom Preston-Werner

I mean, Jekyll was not even the first. There were one or two static site generators before I started working on Jekyll. I took some of those ideas and refined them and made it work really well for blogging. And then we integrated it with GitHub, and I think that really helped the popularity of it, obviously, because we integrated it with GitHub Pages.

But there's so many great ones now. Hugo for a long time was a great competitor. They were pretty early on, and now there's hundreds, or maybe I probably won't say thousands, but you can go online and you can find them for every language, for every different technology. They're optimized in different ways. There's even static site generators for Swift.

00:03:03 - Anthony Campolo

I think if you go to StaticGen, that would be the canonical number of however many there are. I would just go with their number. It's definitely in the hundreds. Last time I looked, you originally called Jekyll Autoblog, and I thought that was an interesting name because I felt like that really captures what it was, a very descriptive way. And then Jekyll could be anything. Why the name change there?

00:03:25 - Tom Preston-Werner

Well, Autoblog seemed a little generic.

00:03:28 - Anthony Campolo

Too on the nose.

00:03:30 - Tom Preston-Werner

I think I'm trying to remember. This was like ten years ago, or more, 12 years ago or something.

00:03:33 - Anthony Campolo

I got the exact date you changed the name here.

00:03:36 - Tom Preston-Werner

Oh, well do tell.

00:03:37 - Anthony Campolo

So let's see. It was 2008.

00:03:41 - Tom Preston-Werner

Oh, I nailed it. Twelve years. Yeah, I think I love naming things. I really enjoy the creative aspect of just thinking about connections that a project has, and how that might tie into things that are a little more surprising and a little less generic, but I don't always come up with them right away.

I think when I started working on Jekyll for the first time, the concept really was around making it so that I could write my blog in a Git repository so that I would never lose the database again. Because I've lost several blogs to hosted WordPress. There's a database somewhere, or it wasn't even hosted. I was running my own and it's on some random server and I'm running MySQL, and I've got that hooked up to WordPress, and I go in and do my thing, and then I get distracted and I don't blog for a while.

00:04:23 - Anthony Campolo

And then this happened to my WordPress blog. This happened a month ago. This is still a thing.

00:04:28 - Tom Preston-Werner

Still a problem. Okay, yeah, I expect so. When you have a database, it requires a certain level of attention and backing up and care that I just wasn't taking, and so I would lose content. And that's really sad. It's the saddest thing when you create something special and then it is somehow lost to the ages, just disappears. You lose information working on GitHub, too.

It made me think, why are we not just writing Markdown files in a Git repository and converting them to static? It's not like we need a database here. Comments were really the only thing. And as blogs became more popular, comments became less popular because people are not very nice on the internet sometimes, and so even that capability became less desirable. And so it seemed natural to me. I was like, well, whatever, I know how to do this. I'll write a simple translator. There were a couple of examples that were super early that were doing similar types of things for content sites, and I wanted one for a blog.

[00:05:24] And Jekyll, you can name a file a certain way, and it gets the date and the title from that, the slug. I was trying to optimize it for efficiency for an author, and make it super easy to write and remove all the excuses that I had for myself for why I wasn't writing, to just be like, oh, I can write a Markdown file anytime I want, and then I just run this single command and it generates it, and I can push that to GitHub and publish it on GitHub Pages. And that's the whole thing.

Autoblog was the name that I came up with because I didn't have a better name, and then I wanted a better name. And so I started thinking about what it did. And Jekyll is really about transforming one version of a blog into another, just the source files into the final version, stitching it all together. And so I started thinking about things that transformed, and that made me think of Jekyll and Mr. Hyde, where the doctor turns into the monster when he takes the potion.

[00:06:17] That kind of transformation, I don't know, it struck me as interesting, and nothing else was called Jekyll, and it seemed like a nice short name and had the right connotation for me. And I don't torture myself over naming. Usually I come across a name that I like and I just go with it. I don't ask too many questions.

00:06:32 - Anthony Campolo

Yeah, I remember when I first read your post, Blogging Like a Hacker. It was one of those crazy aha moments for me because it was this blog post from around the same time we've been talking about, you know, 2008, and you were describing my current workflow so specifically. It was incredible.

And then once I got into it more, I realized that's because this workflow was built by you and many, many other people over the course of ten years or so. Let's bring it a little closer to today. Redwood came from Chatterbug. Chatterbug was, or is, your language learning company. And you've talked a little bit about how Redwood was influenced from the work in Chatterbug, but I was kind of curious, you wouldn't necessarily say it was extracted, right? You would just say it's influenced.

00:07:18 - Tom Preston-Werner

Yeah, that's right. So Chatterbug, the architecture of Chatterbug started as a very vanilla Rails application, doing things all the normal Rails way, using jQuery even. It was just very standard. And that's because that's what we knew. Scott and I, Scott Chacon, who was also a co-founder at GitHub, we joined forces again at Chatterbug, and that's what we knew. And so we were like, well, we don't need to learn a bunch of fancy new technologies to make this happen. Let's just use what we know and get it going.

So we started writing it in Ruby on Rails, and then we started bringing other people on. We brought on another developer, a designer. The designer had a lot of experience in React, and so we started using React for the front end more.

00:07:58 - Anthony Campolo

Is Peter there at this point?

00:07:59 - Tom Preston-Werner

Peter, I don't know. Is he there quite yet? No, but he comes shortly after. Peter was very early in the company. Peter is one of the other co-creators of Redwood. We actually brought him on for the mobile application originally because he had a lot of React Native experience from his previous jobs, but he ended up working on the website itself also, because that's the beauty of React: you can use it across both, and you get people that can do that.

It's really nice for a person in a company to be able to work on the website and the mobile application. It's super nice. We're using more and more React in the site and really enjoying it. And I didn't know React at all at that point, but I started writing some of it and learning it. I went through a learning phase a number of years ago and finally it clicked for me. I had attempted to learn React, I think three or four times previous to that. I think the documentation has improved quite a bit since those days, because I could never quite understand what they were getting at.

[00:08:52] But finally I sat down and I learned it properly and I just really loved what I saw. The paradigms that are available there, especially the one-way data flows, are so much better than the jQuery imperative. Just trying to manipulate your DOM directly to get it to where you want it to be, and not having really an official source of truth anywhere. You have to kind of create your own data structures on the page and be like, this is the representation of the data and trying to keep that updated.

It was just a big mess in jQuery and React was so refreshing. So I learned that and I was like, this is amazing, let's use this for everything. So all new development at Chatterbug we started doing in React on the front end. And then I was really struck by how awesome React was, but at the same time, how difficult it really was to put it together.

There were so many choices you had to make and so few best practices that I could find anywhere.

[00:09:46] Everyone seemed to be doing it differently, and I thought that the barrier to entry there, that learning curve, was too high. I really yearned for those days of Rails where everything is set out for you. All the best patterns are there. Everyone writes about it. A broad consensus on a lot of the main ways that you might want to do things, and I thought we should have something like that for JavaScript. Why was it so hard to do what we were trying to do?

And then we started using GraphQL. So we started not using Rails even in the way that Rails wants to be used. We just started using Rails more and more as the GraphQL API, and pulling things into React on the front end. Each individual component can do its own fetching. So we started settling on some patterns that were really nice. They just worked really well. We could do the design work, do the development work in concert, communicate really well. Everything's isolated. You could use Storybook to look at the components and develop them outside the application.

[00:10:40] Designers could look at those and make sure everything was right and not have to run the application itself. So there were just so many positive things about what we were doing, and yet it took us so long to get there. It was just way too hard to get there. And so Peter and I started talking about a way to make it easier. And that, combined with some of these ideas around what Netlify was making possible with Lambda functions, making it easy to deploy those which could serve as business logic, they already have the ability to put a React client on a CDN and deliver it to the user.

Now add business logic. The missing piece was some kind of a database, but if we could hook all those things together and create a framework around it, then that we thought could be pretty powerful and just reduce the amount of choices that developers have to make going into wanting to do a React-based web application so that they could get to where we were essentially in Chatterbug, but be able to do it all with JavaScript, front end and back end, because that was still the one thing that was a bit of a mismatch.

[00:11:35] We hire Ruby developers, then we also hire JavaScript developers. To me, it's always more desirable if you can focus on one language across everything. If you can do it, there's a lot of benefits to being able to do that. The front end people can work further into the back end and back end people can work further into the front end. Some people can easily work across both sides. It's much more difficult to find someone who's a React developer and a Ruby developer. It's a much more rare skill. You just get better synergies.

Did I just say synergies across the front end and the back end? I think if you do it all the same, you get better synergies. So we were like, what do we want a framework to look like? If we were to build this from scratch, what would we want it to look like? And then we just started building it.

00:12:15 - Anthony Campolo

Cool. So it sounds like you kind of started in the front end with React, and then you kind of moved into GraphQL. And then I guess the final piece then would have been Prisma, which we haven't talked about yet.

00:12:26 - Christopher Burns

I built the first MVP of my startup's product in Gatsby with serverless functions and Prisma 1, and all of these connections were done by me with as much research as I could do. I find that's where Redwood helps you most. It says, we've made that decision for you. This is how it happens, so you don't need to think about that.

The reason I think that's so important is I watch a lot of conference talks, and when I watch conference talks, I always think I need to re-implement it that way. The way they've said it, that way is better. But then when it comes to things like Redwood, you go, it may be better, but this implementation works and is now proven. So does it need to be better? No, because your customers don't care about it. At the end of the day, they don't care. They care about the product. How can we make sure the end user is getting the experience they want and the developers are happy too? What I found is that Redwood is that connection.

[00:13:27] Your customers may not care and that's really sad to hear, but you can be happy knowing that it's built in Redwood.

00:13:33 - Tom Preston-Werner

That's exactly right. And that's how I think about it. There will always be a thousand ways to do everything, and some of them will be better in certain contexts, and some of them will be worse. What to me matters is that I can go from an idea for a web application. I can envision it in my mind what I want it to look like, what I want it to be able to do for the users, how signups work, all of the things that make it special, and then turn that into a real application in a short amount of time.

And like you're saying, the users don't care what technology you're using. So as long as things are integrated, that to me is the most important thing. And the thing that Rails got the most right is that everything just works beautifully together within the realm of what Rails claims as its own framework. And with Redwood, we want to even go further than the boundaries of what Rails is considering to be part of the framework into authorization and authentication.

[00:14:26] Some of these things you're always going to do, that any real application is going to want to do, and we want to make it really easy to do all of those things if you can do it. And it's good, right? I mean, we would prefer that it would be amazing, that everything is amazing. Sometimes things are amazing when you build them for the first time, and then a year later, they're not quite as amazing. And there's maybe some better solution in certain contexts.

What you have to do in those regards is always do all the integration yourself, and the integration work turns out to be very time consuming, very difficult to do really well, to get it to have and feel like it has a lot of polish in it. And that's what we're really trying to do with Redwood, is do the integration beautifully, so that all the pieces just work well together and mesh perfectly.

So Storybook, out of the box, should just work the way you want. Like, okay, well how do I test my components that do data fetching? Well, now you have to build some things for Storybook that are going to make it work. Well, with the way that you've decided to do the React front end, if nobody's integrating that for you, guess what? You're doing that work.

And the problem is that most companies, that's not what makes them special. It's whatever your business is. And so you're going to take shortcuts on the integration. And that's going to mean worse developer productivity for the life of your product if you don't do that work. But it's ridiculous for everyone to do that work separately. We should have economies of scale here in the frameworks. This is the job of a framework, to do that work once and then allow everyone to reap the benefits of that.

And it goes into testing. We're working right now through what do fixtures for testing your services, your business logic. What does that look like? You need to use the database. You need to have something that's setting up test data and tearing it down. And you can do that with before and after actions.

[00:16:07] But doing it manually is incredibly time consuming. A bit of integration, which we're doing now with fixtures, with a feature called scenarios, will do that for you automatically. You just create a file with a scenario that has a set of fixtures that you export, just data in the way that Prisma can consume it. And then we'll read that in automatically for you and set that up in the database. You do your test and then we'll tear it down afterwards.

Rails has been doing this stuff for ages, but for some reason that work has not really been undertaken much at all in the JavaScript and TypeScript worlds. And I think it's time. It's time for people to do that integration work. And you see that now in a couple of different projects, especially in the FSJam world, doing exactly this kind of integration and saying we have the bits necessary to do this. Well, let's choose a selection of those technologies and architectures and glue them together in a way that makes people's lives easier.

00:17:00 - Christopher Burns

I want to talk about one of the big features of Redwood, and the more I work on Everfun, the more I notice tables and scaffolding just appearing everywhere. It's like, oh yeah, everything is almost always a table or a form. How does Redwood help with that?

00:17:17 - Tom Preston-Werner

Yeah, that's true. That's a website. That's a web application. We have scaffold generators in the same way that Rails does, to allow you to get started really easily with your CRUD operations for specific pages. And the idea with those is that you really can take them and use them and really evolve them into your actual website.

This is very rare to do in the Rails world. They also have generators. In this way it seems vanishingly rare that you would actually use those in your production code. You might use them for some kind of back-end admin thing, but for us, because we're using GraphQL, it's really nice to be able to spin up some of the basic CRUD operations that you're probably going to want. And you may not want all of them, and you're probably also going to want to cut them a little bit different and create your own versions of some of them.

Like, you might have several different types of updating a record that are not just like, oh, let me update every record all at once. You might want different mutations that are specialized, right? But you're going to want something that's going to read it. You're going to want something that's going to delete it. Those are going to be fairly standard. Giving you those out of the box very easily as a starting point gets you pretty far and gives you a lot of those building blocks.

And that's important to us. It's important that you can focus on, again, what makes your application special instead of spending your time doing boilerplate work. And we're trying to reduce boilerplate as much as possible so that it's not even in your codebase. But you can never eliminate all boilerplate. That's just not a practical thing to do. There's always going to be some patterns that need to exist in your codebase that you're going to see over and over, and that's okay. You don't want to eliminate it so much that you lose power.

And Redwood is very much also trying not to eliminate power. At the end of the day, it's still just a collection of technologies around React, and you can swap things in and out as you evolve. As your company becomes bigger, you're going to have specialized needs, maybe make some different choices than Redwood does, and we're trying to make it possible to do that. Not that you would always do that, but that you can do that, that the framework doesn't hide so much that it makes it impossible.

00:19:15 - Anthony Campolo

Yeah. This is something that I'm really interested in because Redwood gets compared so much to Ruby on Rails, and Ruby on Rails gets a bad rap for being really monolithic and like all the pieces are really tied together. And what I find interesting with Redwood is it's more of this idea that you can integrate technologies together well without necessarily tightly coupling them. You can have technologies that have interfaces that are generic and universal that can be swapped in and out, but that still work well together and aren't like fitting a square peg into a round hole. So that's something that I try to get across when I tell people like, yeah, it's kind of like Rails, but not really. It's actually going for something totally, fundamentally different.

00:19:59 - Tom Preston-Werner

I think an example might help there. Some work that we're doing right now is the ability to swap out your GraphQL library. Right now we use Apollo, but we very well may change; we're doing some experiments there. It's a much lighter weight library. It has some default behaviors that we think might work better. We're still evaluating it, but in doing that, we want to make sure that certain people that want to use Apollo are still able to do that.

So at the root level of the application, we're working on a way for you to be able to just swap in a new GraphQL provider by specifying what the interface points are, and there only need to be a few of them around how you run a query, how you run a mutation, how you do your basics of data fetching.

And if we do that right, then we can ship with something like Urql in the future probably, and then still say, but if you want all of the power that Apollo brings you and you're okay with the cost, the bundle size cost of that because you're using some of their enterprise features, here's how you swap that in. And now you can go on your merry way and use all the Apollo features as you like.

While we're trying to be opinionated, it's more about having a happy path, getting started. You know that you're going to be able to do everything that you want to do, and you can follow the happy path, and your life is going to be good. But it's not the kind of oppressive, happy path that is secretly an oppressive regime, right? Where it's like you're happy because you have no ability to choose. It's a fake kind of happiness. We want the happiness to be: I'm on this really great path and I'm happy with that, but I also know I can choose differently. I still have free will. We want you to still have free will.

00:21:33 - Anthony Campolo

Yeah. You want to make the easy things easy and the hard things possible, right?

00:21:36 - Tom Preston-Werner

Yes, precisely.

00:21:38 - Christopher Burns

One of my next thoughts is, where do you think the best team size is for working on a Redwood application right now?

00:21:46 - Tom Preston-Werner

That's a good question. I think the best team size to work on most projects is probably between 10 and 20 people, just in general.

00:21:54 - Anthony Campolo

It's like a three or four pizza team.

00:21:56 - Tom Preston-Werner

Right. That's what I found in building things. You can build so much so quickly. If you have the right team of 15 people, say, you get some specialization: developers and designers, and you don't worry about the other parts of the business. You can think just about creating an application itself.

Designers, developers, and some people doing ops. Depending on what you're doing in Redwood, you're maybe not doing as much ops, hopefully. But again, with Redwood, it's still about the ability to choose. And while we would love for you to be able to deploy to Netlify and get all the nice things that come with that and make it super easy for you, one push deploy, we have the ability now to deploy your backend to AWS and we'll continue searching those paths and allowing you to deploy in a more traditional way in a non-serverless way.

You're going to know what the right characteristics are. You're going to know how it's going to integrate best with the other things that you need to do, because often there's other types of work that you need to do. Or you might be using a specialized kind of a database or have specialized data needs. We can't predict all of these things. And so we just want you to have a lot of flexibility around deployment. And so you can deploy to Netlify or Vercel or to AWS and hopefully soon to Azure, Google, and make all of this really first class. And you just choose by running a single command.

You may or may not be doing ops, but to me, when you have a couple of designers and you have a few more developers, you can go really fast. Communication overhead is low. You can make decisions without having to go through the bureaucracies of larger companies, where people need to know that everything's lining up in the right kind of ways. You can do that well. I think you can have good processes, but it's hard. You have to really work at it.

00:23:41 - Anthony Campolo

Steve Jobs has a quote that I really like about this, where he says a small team of A players will run circles around a large team of B and C players.

00:23:49 - Tom Preston-Werner

Absolutely. And a lot of it has to do with being able to decide quickly, being able to make decisions. Now Redwood is very early. It's pre-1.0. There's going to be some things that don't work as well as we want them to. Testing is still in progress. We're still working on testing but things are getting, I think, pretty close. I don't know exactly how to answer your question, so mostly I've talked about other things.

00:24:09 - Christopher Burns

But the reason I asked that question is I think Redwood has so many merits for single to duo developers who don't have a lot of time and have to generalize, not very much specialize, because Redwood takes a lot of those decisions for you and allows you to really just focus on what's important.

Most of us would probably love to work at 10 to 15 developer companies. A lot of people work at tiny companies, agencies, bespoke projects. And the reason I asked it is I see it working really well for the small to medium-sized teams, but also the very big teams. It's just how they look at it and how they decide what patterns they want to keep and what they don't. For example, ten developers may code the same JavaScript file ten different ways, but if you're using a cell, how many different ways will come out of that?

00:25:10 - Anthony Campolo

Yeah, four.

00:25:12 - Christopher Burns

Four. That's a good one.

00:25:15 - Tom Preston-Werner

Right? I totally believe that. And it was kind of a design decision from the beginning. We wanted Redwood to work really well for the very beginnings of your application, to be able to get up and running very fast for just a weekend project that you want to hack on and be done with, but allow that same codebase to grow into a more mature application and still work well.

And again, Rails nails this. You can bang out a simple application very quickly, but it can scale up as companies like GitHub have shown. And Twitter used to, though they abandoned, I think, all of Rails.

00:25:52 - Anthony Campolo

Shopify is the new guard.

00:25:53 - Tom Preston-Werner

Shopify, like, so you can totally do it right. And I want Redwood to have that same aspect where it's good for small projects. It's also good for big projects. They end up looking very dissimilar. But a lot of the things that we're putting in there and we haven't fully documented and explored and explained are organizational patterns, things like services and how services are supposed to be split up and able to call each other.

We really haven't done the work we need to in explaining, architecturally and organizationally, how we think that's going to help long-term maintenance, while at the same time not impeding quick development. Now, choosing GraphQL at all means that you're going to do some extra work to get to the same point as some of the alternatives like Blitz that are choosing like an invisible API. And so Redwood really is going to be a little bit more optimized for the long-term, larger application.

Getting practice and becoming rigorous around the interface points in an application, to me, is the number one way that you maintain organization, or I should say, reduce complexity over time. You have to have organizational strategies. You can't just hope that they appear, and Rails doesn't do a lot for you in this regard. I want to be more clear in Redwood to say, organize your code like this. Think about these different parts of code like this, and how they interface with each other in these isolated ways, so that over time you can keep a handle on the complexity of your application.

That's everything. And I mean, I've built a number of large applications, and it all comes down to organizational complexity. Velocity will always be tied to that in the long term. And if you're doing something ambitious, you need tools that are going to help you do that, or you are doing way more work than you need to and going slower than you need to.

00:27:36 - Christopher Burns

We look at what's next for Redwood and what's coming, pre-1.0 and post-1.0. One of the things that I see as going to be really exciting is the multiple client side of the platform. Because right now React is very stable. But there's a lot of upcoming technology such as React Native Windows, React Native macOS, and React Native Web. These three technologies, if they can help you build applications that will go across all computers, not just the web, that could be really powerful in the next few years.

00:28:19 - Tom Preston-Werner

Absolutely. And this is one of, I think, the great strengths of Redwood from the beginning, the idea that the back end and the front end are decoupled via GraphQL. And we make that distinction explicit and help you think about how that interface should look and how to construct it so that you can have multiple clients.

And it's also a future-proofing technique, like you're saying, maybe in the future people don't even use React in the same way that we use it now with a router and React components. Maybe they're using React Native on the web. If you have too tight of coupling between your front end and back end in that way, you have to undergo a massive shift in your framework to try to keep up with that.

Whereas Redwood, we can say the website was always envisioned to be one of many sides. It just happened to be the first because that's what we had been working on, and I think is the most common thing that people want is some kind of a website.

[00:29:13] Maybe not anymore. With mobile applications, you probably want a website and a mobile app. Or maybe you only have a mobile app and then a very minimal website, but oftentimes you want both. And so we're living in a multi-client world, and a lot of the people using Redwood now already have multiple clients.

They have a command line tool like Tapesh, who's using the GraphQL API from multiple different places, and right now we're not helping him much in that regard to do his command line application. But I think the patterns that he's learning from doing that can absolutely and should absolutely be brought back into the framework to say, oh, you want to do a command line application and have authentication of your command line application, just do this, run this generator, run this setup command. And now you've got a command line tool going that's integrated with your Redwood back end. It uses GraphQL and you're set.

Or similarly a native application with Electron, for instance, or using React Native on the Mac, whatever that's going to end up looking like. Then we can say, okay, well, let's create a side in Redwood that allows you to spin up a native Mac application or a native Windows application, or a native Linux application. Whatever happens to be, those can all just be sides.

And you get into this world where you have a framework that says, look, your back end is an implementation of a GraphQL API and you have many clients that consume that GraphQL API. To me, that is amazing. It gives you really clean separation of concerns between your front end and your back end. It means that the framework itself can evolve quite naturally to support different clients.

As our technologies evolve, and Redwood can provide Redwood ways to do all of it, that's going to take years, I think, to get to. But imagine a future where you're starting a company and you can just say, all right, Redwood, what do I need? I need a native mobile application, I need a website, and I need a command line.

[00:31:03] Right? I need a VR application, whatever it happens to be. All of it can use the same kind of thoughtful developer experience patterns that we're creating now for Redwood, but be contextualized specifically for the type of work that you're doing and just make your life easier and be all about integration.

I think we would all benefit from better integration across all of these tools. I know what I need to get done, let me do it. Give me the tools to do it. Get out of my way so I can focus on my business.

00:31:30 - Christopher Burns

And I think that's really important to think about. And as you said with Tapesh, you can today create another side that connects to your Redwood API. I've done it with Next.js, for example. The core tool is Apollo. Maybe not in the future, but now, if there's an Apollo client for it, it can connect to your Redwood API. But it is a bit of a Wild West situation, right?

00:31:58 - Tom Preston-Werner

Yeah, that's the beauty of a standardized communications protocol that makes no assumptions about either side. It's generic. It's standardized. It means there's a lot of different clients. There's a lot of patterns around it. I think there's a lot of work to do there still around caching. I mean, it's not perfect. And GraphQL in the grand scheme of things is still very young, but it's a flexible and standardized way to fetch data and not overfetch and not underfetch and give the client some specificity there.

And then on the query side and on the mutation side, it's just an RPC protocol essentially with the ability to return structured data, where you also have some optionality in what you get back.

If we envision the world in this way, where you have a thick client that's doing a lot of the work, that also allows you to distribute the computation necessary to do this. The capabilities of our client hardware are improving rapidly throughout the world. If we can do this, then you don't have to write your back end more than once. You write it, it's consumed by everything.

[00:33:00] Like this is a problem that we suffered in Chatterbug. We wrote our Rails application. Yay! We have a really nice web application. Cool. And then, oh, hey, let's start our mobile application because people expect your language learning tool to have a mobile app. And so, okay, cool. Let's choose React Native because we're using React on the front end. And let's fetch some data.

00:33:19 - Anthony Campolo

So backend for front end thing, right?

00:33:22 - Tom Preston-Werner

All right. And then we start implementing a GraphQL API alongside the Rails back end. And guess what? Now we have two backends. Nobody wants two backends. That's the worst. It increases organizational complexity of your code tremendously.

00:33:35 - Christopher Burns

And this is one of the things every developer should evaluate when they're going to pick an FSJam framework. Maybe they need an API or maybe they don't. And which opinions do they care about and which ones don't. Because at the end of the day, every FSJam framework is aiming towards the same goals, but they all take different opinions. You need to find out which one is best for you and then roll with it.

00:34:01 - Tom Preston-Werner

I'll just say that you may not think that you need an API today, but that could very well change tomorrow.

00:34:07 - Anthony Campolo

Yeah, I never knew I needed Redwood until I used it, and then once I used it and I could see all the things I could build with it and the velocity I could get out of it. People talk about how GraphQL has all these complexities around it, but I found that once I kind of got used to it, I moved much faster than I did before using GraphQL in Redwood.

Yeah, I think you're going in the right direction. And it's really interesting to see the development of this over two or three years now. You've really been working on this for a long time. It's come into public view more recently. But you guys have been working on this for a long time.

I know of at least four names that Redwood has gone by. It was known as Hammer. Before that it was Chainsaw. Yeah. What was it before Chainsaw?

00:34:45 - Tom Preston-Werner

There was a repository that Peter and I were using to explore some of the ideas. It was called Der Spielplatz, which is German for playground.

00:34:52 - Anthony Campolo

That's my favorite, actually. I like that one.

00:34:54 - Tom Preston-Werner

Yeah, I wanted to build a Yelp for playgrounds for kids. We have three kids and we used to travel a lot. You'd go places and we'd want to find a playground, and it's impossible to know which ones are good. How do you get there in foreign countries?

So I started taking photos of playgrounds wherever we went, and I was like, I'm going to build an application to do this. And then I was like, oh, I just have no motivation to do this with everything else that I'm doing, and not wanting to use Rails and wanting to use these new patterns. And I just felt I didn't have the right tools. And so Peter and I were using that as an example to start hacking on some ideas, the ideas that became Redwood.

So Redwood was never really called Der Spielplatz. That was just the name of the sort of test repository. So Chainsaw really was the first name, and I just thought that was a cool name. But then we renamed it to Hammer, which I thought was a cooler name and a little less aggressive.

[00:35:39] Chainsaw is a bit gnarly. I was like, I'm gonna call it Chainsaw. That would be awesome because it's a tool. It allows you to really get a lot done quickly, right? It's a power tool. It turned out someone was already using that. So I was like, oh crap, I can't call it Chainsaw. So then I renamed it Hammer because I was like, well, there is a Hammer project, but it's not called the Hammer framework, so I can call mine Hammer.

And I really like that because Hammer in German means awesome. It's slang for awesome. Hammer, you can say like, that is awesome, like the hammer.

00:36:08 - Christopher Burns

I would have thought it was, hit everything with the hammer.

00:36:11 - Tom Preston-Werner

There's a lot of connotations there. And if you go back in the history of the README, you can see at the end of the README I have, like, why is it called this? And it used to be, why is it called Hammer? And I came up with a bunch of clever reasons why it made sense. Based on Mjollnir, Thor's hammer, Thor's hammer could grow and shrink. It could work at any size, just like Redwood or Hammer at the time. It should work for large sites and big sites. It's like indestructible and whatever it had.

So you can go back in the history if you are intrigued someday.

00:36:38 - Anthony Campolo

I've read it, it didn't really make a whole lot of sense to me, honestly.

00:36:42 - Christopher Burns

The ultimate question is, is Redwood the last name?

00:36:45 - Tom Preston-Werner

Yeah, I think Redwood. The reason that I changed it from Hammer, which I love, I loved Hammer and Hammer was very nice to type, sort of flowed really well when you typed it out. The problem with Hammer was twofold.

One was someone told me at some point they're like, you know that Thor's hammer is associated with neo-Nazi right wing stuff, right? And I was like, what are you like? Are you serious? Like, we can't even have Norse mythology. It's not super mainstream, but it does exist. Like, there's just certain symbology that people will have a tattoo of Thor's hammer in a certain configuration, and that's like a white supremacist. That's like I'm a white supremacist. And so, you know, because I have this tattoo of this hammer.

And I was like, I don't want to go anywhere near that because that one's kind of fringe. That was not the main one.

The main reason was there is a project called Hammer. It's like a touch framework for phones and stuff, and it has, I don't know, 20,000, 25,000 stars or something on GitHub. And early on, before we had publicized Hammer, at the time almost at all, someone wrote a blog post about, hey, here's some new frameworks that are coming up, you should check them out. And they mentioned Hammer and I was like, this is amazing. They mentioned Hammer. We haven't even really talked about it. That's really cool. And they named it and they called it Hammer.js. And Hammer.js is exactly the name of this existing project.

And I was like, nope, because I knew exactly what was going to happen is we would launch it. If we kept it called Hammer, we would launch it, it would be on Hacker News. And the very first comment would be, you know, there's already a project called Hammer, right?

00:38:08 - Anthony Campolo

And that guy would feel so accomplished making that comment.

00:38:10 - Tom Preston-Werner

Yeah, they would be like, oh, nailed it.

00:38:12 - Tom Preston-Werner

And so I was like, I gotta bite the bullet. I gotta rename it before we launch it. It's just, I gotta rip off the Band-Aid and do it. So I sat down and I wrote a list of a bunch of, like, 50 names or 60 or 70 names. I just brainstormed, and then I went to npm and checked to see if any of them existed. And I crossed all the ones that really had a project that was at all popular that was called that.

There is a project called Actual Redwood, but it has like two downloads a year or something. So it didn't seem to be too much of a conflict. And I was like, I love Redwood. Redwoods are great.

00:38:43 - Anthony Campolo

I love Redwood, too, because I spent every summer for the last like 15 years in the Santa Cruz Mountains, which is the home of the redwoods that you are referring to. So for me, like when I heard the name and I kind of read your description, it really resonated with me.

And I like the idea of building things that are meant to last. The web has certain elements of it that are so ephemeral that I like pushing against that, and saying we can actually make something that might outlive us.

00:39:11 - Tom Preston-Werner

Yeah. Yeah, absolutely.

00:39:13 - Christopher Burns

Aren't redwoods burn proof as well?

00:39:15 - Tom Preston-Werner

They're quite flame resistant. Their bark is, and this is part of their natural life cycle. Their life cycle is that they've evolved to withstand forest fires. And in fact, they thrive in that environment because it clears out all the brush and allows new redwoods to come up because they have less competition for sunlight.

00:39:30 - Christopher Burns

Even if the application is on fire, Redwood will handle it.

00:39:35 - Tom Preston-Werner

Exactly. See, there's just all kinds of clever connotations there. And another reason I liked Redwood was because it was kind of the antithesis of a lot of the names that people are using.

The React ecosystem, where everything has to do with atomic energy, and everything's like, how many different framework elements these different projects, these libraries have, like the Bohr model of an atom, you know, with the electron orbitals spinning around. There's like half of them. You're like, oh, that logo looks familiar, right? And they're all kind of named in a similar way. And it's like there are some themes there that people have latched on to, and that's cool. But I like to be a bit of a contrarian. I like to go the path that people don't take.

I really liked Redwood, too, because it was this thing that was totally just nature, and I don't see a lot of projects that are named after things in nature, right? Which makes sense. Coding, programming, all of this is high tech. And so we choose things that are in the realm of physics and other things quite often. And so I liked bucking the trend there and being like, nope, nature. All of our stuff is going to be about nature.

00:40:42 - Anthony Campolo

This is why the intro song of our podcast is jazz, by the way. The exact same reason.

00:40:47 - Tom Preston-Werner

Ah, there you go. Yeah, it's nice to have that kind of contrarian surprise every once in a while.

00:40:52 - Christopher Burns

Maybe one day I'll take a pilgrimage to California to see a redwood tree in person.

00:41:00 - Anthony Campolo

You should.

00:41:01 - Tom Preston-Werner

I live amongst them. I'll give you a tour. You come out, I'll give you a tour of the redwoods.

00:41:06 - Christopher Burns

That'd be great. California is one of these weird states where I thought it was boiling. And then I see a picture of, like, Yosemite with snow on it. I'm like, how big is California?

00:41:17 - Tom Preston-Werner

Oh, California is very big.

00:41:20 - Anthony Campolo

California is not a state. It is many countries.

00:41:23 - Tom Preston-Werner

California is huge. To drive from the top of California to the bottom would take you probably about 24 hours.

00:41:32 - Anthony Campolo

But nah, you could do it way faster than that. I've done it like 16.

00:41:36 - Tom Preston-Werner

Well, if you're a speed demon. Speed demon like you, Anthony.

00:41:39 - Anthony Campolo

If you're a law-abiding citizen.

00:41:40 - Tom Preston-Werner

Citizen such as myself.

00:41:42 - Anthony Campolo

I'm just saying, going from SoCal, like LA, to, I guess it depends, you know, where you're going from. It's a very, very big state and I'm not there anymore, so let's not talk about it. So wrapping up here, thank you so much for coming on, Tom. I can say that my experience with Redwood has been legitimately life changing for me, and it's led to so many opportunities and great connections. And I've learned so much. So thank you for building this thing and this community that I've really been able to thrive in. Keep doing what you're doing.

00:42:16 - Tom Preston-Werner

Well, you're very welcome. And I'm extremely thrilled to have both of you in the community. You're both doing amazing work, and this podcast is part of that. Evangelism is a huge part of it. Creating a community that is welcoming and friendly and trying to help people build new things, my favorite thing in the world is people creating something new and turning their ideas into reality. And I hope that Redwood helps people do that. And so thank you for being a part of that journey.