Web Rush on RedwoodJS with Anthony Campolo

Episode Description

Anthony Campolo explains RedwoodJS, a full-stack React framework that combines GraphQL, Prisma, and other tools to simplify building data-driven web applications.

Episode Summary

In this episode of Web Rush, Anthony Campolo joins hosts John Papa, Dan Wahlin, and Ward Bell to break down RedwoodJS, a full-stack JavaScript framework designed for building forms-over-data web applications. Anthony explains that Redwood takes popular but disparate tools — React, GraphQL, Prisma, Jest, Storybook — and weaves them together with opinionated conventions, sparing developers from having to choose among dozens of competing libraries and wire everything up themselves. The conversation traces the framework's philosophy of tutorial-driven development, where a carefully structured tutorial serves as the primary onboarding path, introducing concepts in layers so that even developers unfamiliar with GraphQL or Prisma can build and deploy a working app. Anthony contrasts Redwood with related frameworks like Gatsby, Next.js, Blitz, and Bison, clarifying that Redwood's distinguishing feature is its commitment to GraphQL as the bridge between front end and back end. Ward and John press on practical concerns — lock-in, longevity, and whether experienced developers would find value — and Anthony argues that Redwood's use of stable, portable web technologies and its flexibility around databases and deploy targets make it a safe long-term bet. The episode closes with thoughtful reflections on intellectual humility in both technology choices and broader life conversations.

Chapters

00:00:00 - Introduction and Meet Anthony Campolo

The hosts open with lighthearted banter about redwood trees and hiking before admitting that none of them have significant hands-on experience with RedwoodJS. John frames the episode as a genuine learning opportunity for both the hosts and listeners, setting an exploratory tone rather than an expert review.

Anthony Campolo is introduced as a Lambda School student, Redwood contributor, and the framework's primary advocate. He describes his role giving demos, podcast appearances, and meetup talks, and notes his background as a former teacher who values education. He also mentions his extensive multi-part blog series walking through the Redwood tutorial, which leads into a discussion of the framework's tutorial-driven development philosophy — the idea that the tutorial should be the centerpiece of how a framework is taught and understood.

00:04:27 - What Is RedwoodJS and Who Is It For?

Dan asks the fundamental question of use cases, and Anthony explains that Redwood is a full-stack web framework aimed at data-heavy applications — dashboards, charts, forms, and CRUD interfaces. He emphasizes the convention-over-configuration approach, drawing comparisons to Rails, and contrasts it with the typical React ecosystem where developers assemble everything from scratch.

Ward and John push further on what Redwood actually is, and Anthony confirms it is definitively a framework, not a library. He explains that Redwood combines React, GraphQL, Prisma, and other libraries into an integrated, opinionated whole — something you build your entire project around rather than eject from. Ward summarizes the target audience as "forms over data" applications, and Anthony agrees, noting that most web apps ultimately come down to tables, graphs, and inputs.

00:08:19 - The README, Technology Stack, and Getting Started

John walks through the Redwood README and initially wonders whether React and Redwood are competing choices before realizing that Redwood is built on top of React and its ecosystem. Anthony and a fellow developer confirm that many people had independently assembled similar stacks before Redwood formalized the pattern, and the real value is in the curation and integration — not just combining the tools, but choosing which ones to use from among many competing options.

Ward makes the case that the README should lead with the problem Redwood solves rather than listing technologies, and Anthony agrees this messaging could be improved. He shares a personal story from boot camp where teams spent entire weeks failing to ship basic CRUD apps, whereas after completing the Redwood tutorial, he could build those same projects solo in a day — a compelling illustration of the framework's productivity promise.

00:15:15 - Full-Stack Architecture: React, GraphQL, and Prisma

Anthony explains the full-stack nature of Redwood, emphasizing that React alone is only a front-end view layer and that many boot camps barely cover databases. Dan asks about data synchronization and database options, and Anthony walks through how GraphQL serves as the mediator between front end and back end, with Prisma handling database interactions through a schema definition language and resolvers.

The conversation covers Prisma's flexibility — it supports Postgres, MySQL, and SQLite, with plans for document databases — and the fact that developers can swap Prisma out entirely for other database tools. Anthony also explains the default tutorial path that uses Heroku Postgres but notes extensive documentation for alternative hosting on Azure, AWS, and DigitalOcean. Ward asks for quick explanations of GraphQL and Prisma for listeners unfamiliar with them, leading to accessible descriptions of each technology's role in the stack.

00:22:11 - Prisma, ORMs, and Database Flexibility

Ward asks whether Prisma is an ORM, sparking a humorous tangent about how Prisma only recently began calling itself one after years of insisting it was a query builder. Anthony cuts through the jargon by saying the key point is that Prisma writes your SQL for you. The hosts joke about the anti-ORM movement and Ward's personal history of building ORMs.

Anthony mentions FaunaDB as an alternative to Prisma for developers who dislike ORMs, reinforcing Redwood's flexibility. Ward then pivots to praising the tutorial's organization, noting that its chapters are structured around problems — building pages, getting data, handling forms, authentication — rather than technologies. He compares this favorably to tutorials he and John wrote for Angular, appreciating the problem-first approach over a technology-first one.

00:26:24 - Learning Curve and the Spiral Curriculum

John voices a concern many listeners likely share: with so many technologies bundled into Redwood, is the learning curve overwhelming? Anthony offers a practical learning path — start with Create React App, then explore Gatsby or Next, and only then move to Redwood when you need a database and authentication. He reassures listeners that the CLI generators handle most of the GraphQL and Prisma boilerplate, so developers can complete the tutorial with minimal direct knowledge of those tools.

John compares learning Redwood to peeling an onion, and Anthony refines the metaphor with the concept of a spiral curriculum from his teaching background — revisiting topics at progressively deeper levels. The discussion highlights how Redwood's tutorial-driven approach is designed to onboard developers incrementally, making the framework accessible even to relative beginners while still rewarding deeper exploration over time.

00:30:27 - The CLI, File Structure, and Developer Tooling

Dan highlights two things he finds compelling: Redwood's robust CLI and its enforced file structure, noting that every React team he's encountered at companies organized projects differently, often chaotically. Anthony walks through CLI capabilities including project generation, dev server setup with Webpack, and generators for pages, layouts, components, and cells.

He also explains that every generated file comes with corresponding test and Storybook files, setting developers up for test-driven development and component isolation out of the box. Dan asks about mocking database calls for isolated component development, and Anthony notes that this is an area of active development, with a second tutorial focused on testing and mocking being released that same day. The conversation underscores Redwood's goal of providing a complete, preconfigured development environment.

00:35:40 - Opinionated Frameworks, Trust, and Making Choices

John expresses a tension many experienced developers feel: opinionated tools are great for productivity but potentially limit learning from mistakes. Anthony responds that Redwood appeals to both experienced Rails-style developers looking for a JavaScript entry point and front-end developers who need help connecting to back-end infrastructure. He recommends building small proof-of-concept projects with multiple frameworks.

This leads to a rapid-fire comparison of five React frameworks: Gatsby for static sites, Next.js for server-side rendering, and the newer full-stack options — Redwood with GraphQL, Blitz without GraphQL, and Bison combining Next.js with GraphQL. Ward pushes back on the "try them all" advice, arguing that listeners should first identify their problem type to narrow choices. The discussion becomes a practical guide to when Redwood is and isn't the right tool, with Ward framing the key enterprise questions as whether the underlying technologies are solid and whether lock-in is manageable.

00:44:27 - Longevity, Lock-In, and Final Thoughts

Anthony addresses concerns about Redwood's staying power, noting the framework's name was chosen to evoke longevity and that it's built on stable, portable web standards. He explains that Redwood supports multiple deployment targets for both front end and back end, reducing lock-in risk. John humorously proposes a counter-framework called HouseflyJS that only lasts 24 hours.

The episode wraps with thoughtful final reflections from each participant. Dan encourages intellectual humility and openness to disagreement across technology, politics, and life. Ward builds on this by framing development as a social activity enriched by understanding others' perspectives. Anthony thanks the hosts for the mentorship podcasts provide to self-taught developers and invites listeners to join Redwood's active community. John closes by sharing a workplace lesson about focusing on desired outcomes rather than leading with criticism, tying the technical discussion to broader interpersonal wisdom.

Transcript

00:00:04 - Announcer VO

Welcome to Web Rush, the weekly talk show that brings you stories of real world development from industry experts and developers like you and me each week. Ward Bell, Dan Wahlin, Craig Shoemaker, and John Papa find out what it takes to write, deploy, and maintain apps that stand up to the demands of the real world. And now, here are your hosts.

00:00:30 - John Papa

Welcome back to Web Rush. This is episode 119. And today we're going to the trees. It's all about RedwoodJS, and with me today I've got my co-pilots, Dan Wahlin and Ward Bell. How are you guys doing today?

00:00:46 - Dan Wahlin

Crashing and burning today.

00:00:49 - Ward Bell

I'm actually going to be in the redwoods later today.

00:00:52 - Craig Shoemaker

Oh, really?

00:00:53 - Ward Bell

Yes, I am. I've got a lovely afternoon hike planned. The pandemic has been good to my hiking.

00:01:01 - John Papa

So are you going to be like, all meta and bring a laptop and use RedwoodJS while you're in the redwoods?

00:01:06 - Ward Bell

That is absolutely, absolutely. And I'm going to be only looking at Redwood apps on my phone. It should be that, because that's the way to go into nature is with a framework. Never go into nature without bringing a framework. But it might not be a framework. Is it a framework? We're going to ask that question.

00:01:21 - John Papa

We're going to ask these questions today because this is an interesting topic for us, and I'm going to go out on a limb here and say that the three.

00:01:27 - Craig Shoemaker

Of us on a limb. Oh, God. Oh, that's terrible.

00:01:33 - John Papa

And I'm going to say that the three of us have not actually done a whole lot more than just observing RedwoodJS, so we don't really have a lot of experience with it. This is going to be a learning experience for everybody, at least for all of our hosts, and I'll bet a lot of our listeners too. So hopefully it'll be a good one. And with that, we have our guest today, Anthony Campolo. How are you doing, Anthony?

00:01:55 - Anthony Campolo

Hey, thanks for having me. I'm really happy to be here. Big fan of the show. Happy to talk about this JavaScript framework, which you know would have been assumed in the past, but now I have to make sure I specify.

00:02:05 - John Papa

And to give you a little information out there about Anthony Campolo, he's a Lambda School student studying full-stack web development and a contributor to RedwoodJS. I believe he's also now a co-owner, co-author, and co-conspirator of RedwoodJS. Is that right, Anthony?

00:02:22 - Anthony Campolo

Yeah, so it was originally just a team of four people as the core founding team, which you can get a little bit into the history later. And it's now expanded out into a larger team of around a dozen people. So I'm kind of like the core advocate. I'm the one who goes out to podcasts to talk about the framework. I do a lot of demonstrations and meetup talks where I build Redwood applications from scratch and deploy them and show people how to work with it. So I'm used to explaining it to people who have never even heard of it and don't know anything about it. And as you said, I'm a boot camp student, I used to be a teacher myself, so I'm really just a big fan of education. I think education is really important, and I like getting to kind of blend these different areas of my past and my present.

00:03:07 - John Papa

That's awesome. And it looks like you're also the author of a 12-part. Did I get that right? 12-part series of First Look at Redwood. Is it really a first look? If you're doing 12 looks.

00:03:17 - Anthony Campolo

It's about to be longer, actually. It was a first look, and it was me going through the entire tutorial. Redwood has this idea called tutorial-driven development, which is the idea that the tutorial is actually the main thing that you should focus on when you're building the framework. Not only should you focus on things like docs and things like that, because there's also README-driven development, which is a little bit connected to this. Tutorial-driven development is about creating a tutorial that, from front to back, is how you would want to explain the framework to someone. That way, everyone gets onboarded in a way that gets them up to speed as fast as possible and introduces the technology and the terminology, because there's a lot of tech, like GraphQL and Prisma, that some people may know about apart from Redwood. But then there are also new concepts like cells and things that are specific to Redwood. So there's a lot you need to get into.

00:04:15 - Anthony Campolo

It's a bit of a steep learning curve to get into, but it's also structured in a way that someone with a relative lack of experience, such as myself, can still get spun up with it and build useful things with it.

00:04:27 - Dan Wahlin

So if I were considering your 12 step success life guide or whatever it is, what would be my reason for wanting to dive into that? Like, what are the use cases you see for Redwood? Because I think that's an important thing to address kind of upfront before we talk about the tech.

00:04:48 - Anthony Campolo

Absolutely. So it's a full-stack web framework. It's for building applications that have lots of data manipulation, lots of interaction. So think of a dashboard or a chart- or graph-type application. Any of those kinds of things are going to be in its wheelhouse. But it's also a convention-over-configuration idea. So some people compare it a little bit to Rails in this respect, in that it has a lot of generator commands and scaffolding commands and clear ideas of how your project should be structured, which is very different. It goes very much against the grain of the React world, which is very much build-it-yourself, very low-level, very much put-the-pieces-together. So it's about giving you pieces to build modern web applications, not websites, in a way that doesn't require you to do a lot of the glue between the front end and the back end.

00:05:43 - John Papa

So I'm going to ask the question. Ward started asking in the intro, which is kind of around what is it? Is it a framework? Is it a library? Is it a hammer, a nail? What is it?

00:05:55 - Anthony Campolo

It used to be called hammer. Hammer was the name before Redwood. Actually, funny enough, before hammer, it was called chainsaw. But that's a different story.

00:06:02 - John Papa

Wasn't HammerJS a motion library as well?

00:06:06 - Anthony Campolo

So the reason why they didn't call it chainsaw or hammer is because, yeah, they were already taken.

00:06:10 - John Papa

Ah, gotcha.

00:06:11 - Anthony Campolo

Yeah, it's absolutely a framework. It is definitely not a library. It's very much about building a framework by combining other libraries. So React is a library. React Hook Form is a form library. Tailwind is a CSS library. And what Redwood does is it gives you opinionated conventions to combine all these libraries into a framework. So it is very much a framework, an entirely integrated thing that you would want to build your whole project with. It's not something that you would want to eject from, like you wouldn't want to eject from Rails.

00:06:48 - Ward Bell

So clearly it has certain applications in mind and certain applications that it's not suited for. You wouldn't use it. I'm just going to suggest this off the top of my head. You wouldn't say, well, I want to write a game. So I think I'll use Redwood, right? I mean, I assume that I'm right about that. It's not a game development framework. It's some kind of forms-over-data application development. What's the target application audience for this?

00:07:17 - Anthony Campolo

Yeah. Forms over data is a great way to put it. It's very much about getting you connected to a database, getting you your inputs, getting your CRUD capabilities really quickly, and having all of that done in a way where you're not going to trip over yourself, and that also has essentially an entire ORM in it: Prisma. You don't necessarily need to use Prisma. But the main convention is to do lots and lots of forms-over-data web app stuff. The thing we talk a lot about is that almost every web application is tables, graphs, and inputs, so it's about trying to make it really easy to build those kinds of applications.

00:07:57 - Ward Bell

Certainly the sweet spot for the kinds of things I've done almost my entire life. And I think John and Dan, I think that's kind of been, you know, those are the kinds of people who pay us, are the people to build these endless forms over data kind of variety of things. So there's a big audience for whatever this.

00:08:13 - Anthony Campolo

You might actually find it useful then.

00:08:16 - Ward Bell

Who knows? You're going to have to convince me.

00:08:19 - John Papa

So I'm trying to understand this, and I'm walking through this from a very beginner standpoint, trying to figure out where Redwood fits into my toolbox. And I'm reading the README because right on the main page it says, hey, if you want to learn why we created this and what it is, let's go to the README. So I'm looking at the README, and one of the first things I see is here's a quick taste of the technologies a standard Redwood app would use. It says React, GraphQL, Prisma, Jest, Storybook, Babel, Webpack. And then I backed up. I go, wait, React. If I were using Redwood, wouldn't I not use React? Isn't it like one or the other? But then I read the opening paragraph because I don't read opening paragraphs usually. That was an insight for me. And I went back and it basically sounds like you're saying that Redwood is a way to use React and those other commonly popular tools all together in a cohesive architecture.

00:09:13 - John Papa

So it's kind of like you could build a React app with Jest and GraphQL and Prisma on your own, but using RedwoodJS, you're getting all those things in a way that kind of makes sense. That's kind of what I'm gathering by reading the README. Am I off base? And if I am,

00:09:29 - Anthony Campolo

That's certainly how I would describe it to people. It can be kind of hard to wrap your mind around when you're first getting into it, because as you're saying, it's a lot of different things kind of all integrated together. And a popular refrain of one of my friends, Christopher Burns, is he's always saying, I built Redwood before Redwood, and he's met lots of other people who have had this kind of idea, too, where a lot of people had React and Storybook and Jest and GraphQL. And then they would have some state management library and they would have some router, and then they would have maybe some sort of data tool to talk to their database. And they would wire all those things together to create whatever they need to do to create their project. But this is about, as you say, doing the integrations and also curation because you think about it. Part of the problem isn't that it's necessarily really difficult to integrate them all. It's the fact that for each of those different things that I listed, there's five different choices that could all be legitimate based on certain different use cases.

00:10:25 - John Papa

And so that creates a string of five different choices out there. It's time to make a choice. Pause for a word from our sponsors.

00:10:33 - Announcer VO

Hey, are you building apps in React, Angular, node or some other framework? Well, with Nx you can build your full-stack apps in a shared monorepo, integrate with modern tools, and reinforce best practices. You'll get advanced code generation and automatically configured tooling like Cypress, Jest and prettier. That will simplify your workflow and also helps you simplify the relationships between applications and shared libraries to make it easier to share more code and develop more consistently across teams. And the best part is, you'll build higher quality apps and spend less time on configuration. So visit nx.dev to get the Narwhal's popular open source toolkit for monorepo development today.

00:11:16 - John Papa

And we're back.

00:11:19 - Ward Bell

John has really hit something here. I've written my own libraries. And so I often launched right into the "what." I've sort of put the boat right into the weeds right away to tell them all about the technologies that are involved. And I start throwing stuff around because I forgot why I did it in the first place or what the thing is for. And I think we started this conversation that way. So I guess my sense is that it would be great if the README said, hey, here's your problem, here's the problem. At least here's the problem we face that we're trying to address. You know, we face the world like this. We were like, that's why we're talking about forms over data applications. The canonical. Maybe it can be used for other things, but what's it about? What's the main lane? The main lane is that I have to build a forms over data application.

00:12:12 - Ward Bell

And my problem is that I could grab all these other technologies, each of which have five different variations, which is where you were going. You were saying, not only is it composed of all these technologies, but for each of those technologies there's multiple choices and you can just go, "Ah!"

00:12:27 - Ward Bell

Right. So what we said is — and I'm making this up — we know we want to build these forms-over-data applications. We know we have all these technologies that we love to use. But nobody brought it all together and said, here's a whole pattern, here's a whole way of weaving them together so that it just makes my choices for me so I can get on with the business of building my forms over data. Now, I just said that. Does that make sense to you? Is that true of Redwood? And if so, my suggestion would be maybe that kind of pitch needs to be up front.

00:13:05 - Anthony Campolo

Yeah, I think you're right on the money there. And it's definitely something we need to do a better job of emphasizing. This is something Brandon Bayer, who has a similar framework, Blitz, does a really good job with. He starts all of his talks with a five-minute section where he talks about the problem he had doing the same thing, which is what you're saying. We're all trying to build applications that are forms over data, and we're all trying to do it in a way that makes sense for our project and makes it both easy to reason about and easy to work with, both from a debugging perspective. And it's not easy because of the React ecosystem specifically. This requires really getting into React and how it was created and what it was intended for originally. And again, this is going to be a whole long explanation. But let me make this a personal story, because this is something that I've lived myself. I'm someone who's a boot camp student, and I went through a program that was very React-focused.

00:14:00 - Anthony Campolo

A lot of the technologies that we're talking about here are technologies that I learned in my boot camp. And every unit we would have what's called a build week. At the end of the unit, we would have a week where we'd have a team of people that needed to build some sort of project that has users and forms over data. You're creating a bookmark app, you're creating a note app, you're creating any of these kinds of things. And I did three of these and saw a whole team of people work on it for a whole week, and none of those apps even shipped. None of them even reached MVP, to the point where they functioned and users could log in and create data and do anything. This is the type of thing that, by the time I finished the Redwood tutorial, I could build those projects by myself in a day.

00:14:50 - Ward Bell

And that's a solid pitch. And then you're ready for the next question people come back at you with, which is, 'Oh, it's just a toy. You can only do a to-do app.' And then you talk about your philosophy for saying, hey, you haven't lost track of all of the component technologies that help you do it. You can use anything that you know about those things, I'm guessing. I'll bet anything I know about React I can use in a Redwood app. Is that true?

00:15:15 - Anthony Campolo

So React is part of Redwood. So if you're using Redwood, you're writing React components. It just has conventions around the React components and how your project structure works and then how those React components talk to your database.

00:15:29 - Ward Bell

So if I'm skilled with React, I'm not going to lose anything. All you're going to do is sort of lay the groundwork there. But then I have all the other technologies that you're weaving together here that I can take advantage of, even if I don't happen to know them, like GraphQL or something like that.

00:15:48 - Anthony Campolo

I think it's really about the back-end. And this is why GraphQL is important to get into, because it's a full-stack. It's a full-stack framework. That's the thing that I always want to try and emphasize the most is the full-stack nature of it is that when you're learning React, it's only a front-end framework. It is the V in MVC. It is the view. It is part of your application. It is not your entire application. I feel like this is something that is getting lost in this transition from quote unquote, full-stack development to whatever this single page application SPA thing is that we've got going on now. And so the idea of even having a back-end with data that can be persisted is something that's almost not even covered in the boot camp, like we spent like a week on databases and it's like, that's not enough now.

00:16:31 - Dan Wahlin

I actually wanted to go into that a little bit because I'm looking through your docs here and I see authentication. That's a big deal, and that's something that is a lot of work to do on your own. But getting to the database side of it, I've done Mongoose with MongoDB before, so I kind of like the model approach. And with this, it's Prisma with Postgres. Now, how is the data actually handled? I don't know if any of us have used Meteor. I've played with it years ago, but it would kind of auto-sync. Does Redwood? So a couple questions here. Number one, does it auto-sync your data, or do you control it? I'm guessing you can control it. And then with GraphQL, I'm assuming that's how we're querying everything in our database?

00:17:19 - Anthony Campolo

Yeah. So there's a couple of things to go into there. First of all, GraphQL is the mediator between your front end and your back end. So if you guys know what a schema definition language is, your project will have a schema definition language in it. And then you are basically writing resolvers for your schema definition. The question about the database partly comes down to whether you're going to use Prisma or not, because Prisma, as you say, works with Postgres. It also works with MySQL and SQLite. And they're going to be adding Microsoft SQL Server. So it is currently really a relational-only tool. Sometime over the next couple of years, they are going to be able to work with document databases. That's a really long-term thing. They will get there, but it's going to take a while. You could, though, simply rip out Prisma and use any database you want and just write your own, import the client, and do all the Mongo stuff if you bring in Mongoose.

00:18:13 - Anthony Campolo

You can use whatever sort of back-end tool you want. You don't have to use Prisma. It's not tightly coupled in that sense. So your data story, you actually have a lot of flexibility there out of the box. If you follow the conventions, you're going to use Prisma and you're going to use it to connect to a Postgres database hosted on Heroku, Postgres specifically. So there's also the question of whether you're hosting it in Azure, on AWS, or on a platform like Heroku. So there are also questions of where you're hosting it as well.

00:18:39 - Ward Bell

You said that it favors Heroku, but I can use it against anything.

00:18:43 - Anthony Campolo

Correct. So basically the way it's set up is there's one canonical tutorial that will take you from start to finish with a deployed application. So when I say the opinions and the conventions, that's usually what I'm referring to. But then in the docs, there are all these kind of forking paths. Once you have the created project, you can follow the tutorial in a different direction. You can say, actually, I want to use Heroku, or I want to use an Azure Postgres database. So you go to a different part of the docs. It'll take you off of the main tutorial and show you how to integrate a different database. And so you have to look to see if whatever you want to host and whatever database you use is covered or not. These are all things that are kind of in motion, and different contributors are adding different things at different times.

00:19:26 - Dan Wahlin

On the sync, then just to kind of wrap that up, it sounds like it's kind of on you as the developer to make the GraphQL-appropriate calls to save the data, for example. Is that accurate?

00:19:37 - Anthony Campolo

Yeah. So you can have commands that will generate a lot of your CRUD stuff. If you're talking about real-time subscriptions and stuff like that, that's something I haven't gotten into yet in GraphQL. I can't really give you a super great answer on it, but it's using Apollo. So I would imagine Apollo probably has features that could deal with that.

00:19:58 - John Papa

And I wanted to go through just a couple of the technologies that are in here. I think most of the listeners out there know things like, hey, we know what React is, for example, but just not to make any assumptions. Could you just give maybe a quick 10 seconds on each of these technologies, GraphQL and Prisma especially, so people can get an idea of what they are? And you mentioned Apollo as well.

00:20:21 - Anthony Campolo

Yeah. So if you've never heard of GraphQL before, GraphQL is what you call a query language for APIs, which is actually a very succinct and really awesome definition. If you think about your REST API, you have an endpoint that has a bunch of resources. You hit that endpoint, you get the resources, and you do whatever you need to do with those resources. The difference is, with GraphQL, you can say, actually, I just want this data, and not only do I want this data, I want just these fields on this data specifically. So you can essentially say, I want this user and I want these parts of their profile. GitHub has a GraphQL API. And you could use that to create all sorts of nutty projects on top of GitHub and get all of GitHub's data. So that's GraphQL. And that's the mediator that your front end and your back end use to talk to each other. So your front end does queries to your back end. And it can also do mutations.

00:21:17 - Anthony Campolo

It's not just reading data. It can do all the CRUD. So GraphQL is a huge thing. It kind of takes a while to wrap your mind around. Once you kind of get it, though, it's a mental model that makes a lot of sense and is really nice to write in, and I really recommend it. Everyone should at least play with it. Okay, so I'll just...

00:21:35 - John Papa

Let me interrupt. We're starting at the client. We've got React. We're talking to GraphQL to then mediate to the server. Then the next technology steps in. What's that?

00:21:44 - Anthony Campolo

Yeah. So then that would most likely be Prisma. You import a Prisma client into your project. So it's like you import db from Prisma. And then you have db.findMany to find everything from the database, or db.findOne. So you have these Prisma commands that are in your back end. And then those are what's calling into your database through a Prisma model, like an MVC kind of thing.

00:22:11 - Ward Bell

So for people who don't know Prisma, you described it earlier as an object relational mapper ORM. Is that correct? You know, at least its own site seems to suggest that it's that.

00:22:23 - Anthony Campolo

This is a funny question. For years they refused to call themselves an ORM. They would say they're a query builder. And if you want to get into the technical definition between a query builder and an ORM, it is more of a query builder, basically meaning it's slightly lower level. It's closer to the database. But it's kind of in between a query builder and an ORM. So again, if you don't know any of these terminologies, this is complete gibberish and you don't really need to worry about it. The point is it writes your SQL for you. That, to me, is the most important thing.

00:22:54 - John Papa

You said that because right on the homepage of Prisma.io, it says in big bold letters next-generation ORM.

00:23:01 - Anthony Campolo

It didn't say that a month ago.

00:23:05 - John Papa

I wasn't making this up. I know I make a lot up on the show.

00:23:10 - Ward Bell

And I've actually written several ORMs in my lifetime, so.

00:23:16 - Dan Wahlin

And it's fun.

00:23:17 - Ward Bell

Oh, so much fun.

00:23:18 - Dan Wahlin

You should write an ORM.

00:23:20 - Ward Bell

And you take on godly hell for doing so because there's an anti-ORM movement, and they have a point.

00:23:27 - Anthony Campolo

That's why they don't call it an ORM.

00:23:31 - Ward Bell

That's why nobody wants to call their thing an ORM, because everybody knows that ORMs are bad. And I only do bad stuff, so I'm right at home there.

00:23:43 - Ward Bell

But no, I actually take the point about the resistance to ORMs, though. The idea that you would then turn around and say, 'What we really should be doing is writing an assembly language,' which is kind of what they mean when they say, 'Go ahead and write the SQL,' doesn't seem to me like an answer.

00:24:02 - Anthony Campolo

It's an interesting tangent here, actually, to go on about this. Another option is to use FaunaDB. I don't know if you guys know FaunaDB, but that's kind of its own database. That's a little bit Mongo-like, and you could use that instead of Prisma. I've built out some projects like that. So that's what's kind of cool about Redwood: even if you do hate ORMs, you don't need to use the ORM.

00:24:21 - Ward Bell

I wanted to switch to something that goes back to the origin point here, the origin story. I'm looking at your list of links on the tutorial page, and they don't talk about technology at all. They talk about problems. I want to build my client. I want to build my first page. I want to know how I lay it out. I want to know how I'm going to get my data. I want to know about forms. I want to know how I save. I want to know about authentication. It marches. It starts from the thing I want to build, a forms-over-data application, and it marches me through it. And the technology emerges as you dive into each of these, but the chapters are actually organized in terms of the problem I'm trying to solve. I like that a lot. I like that it's not, I mean, you go to React.

00:25:09 - Ward Bell

It's all about the React technologies, which is appropriate because React is a library to help you build any kind of application. No, this says, I got a mission. My mission is to build an application. There's a lot of crazy technology out here. Don't worry about it. Let me just get you there, problem by problem. I like that approach. It should sound familiar, John, because back when we were writing that tutorial for Angular, that was kind of the thing we did, right?

00:25:37 - John Papa

It was. And I'm sorry for all the questions here, but again, I'm self admitting I'm very new to this when I look at this, I like the solution approach and I'm thinking, okay, if I start a new project I go to these pages. And as Ward said, you see the problems and solutions. And if they match what I'm looking to achieve, great. This sounds like a great approach. But I'm also wondering if I go to this page and I start going down this road. It can be overwhelming to me personally, and I imagine to others to think, not only do I have to learn what RedwoodJS is, but maybe I don't know everything on that list. Maybe I know 1 or 2 of them. I'm a React developer. Yeah, I'm a React developer. Great. I can run with this. I get to the next one. GraphQL, man, maybe I haven't used it as much, but I know what it is. You start going down the list to other things.

00:26:24 - John Papa

And you said it was opinionated, meaning that, you know, we give you a list of things that work well together, which is great if that's what I want. But do I have to learn that whole list of things? And, you know, how do people go through that? Do they have to learn them all? If they don't, what do they do? Help me get over my fear of seeing a list of things I have to learn.

00:26:48 - Anthony Campolo

Yeah, this is a great question. And this goes back to my own personal experience going through these technologies. I came to Redwood, I would say, with a decent amount of familiarity around how to use Create React App. So I would say if you've never used Create React App before, you should not dive into Redwood yet. You should figure out how to get Create React App spun up, generate a very basic React project, get that deployed to either Netlify or Vercel. That needs to be your step one. After you've done that, then you want to mess around a little bit with a Gatsby or a Next, because those are going to be similar to Create React App. They're going to structure your front end in a slightly more coherent way. They're going to give you pages and a router. So that's really nice. So I say once you've kind of found the problems with Create React App, then you start looking at things like Gatsby and Next. Then when you realize, okay, but I need a database, I need authentication, I need all of that.

00:27:41 - Anthony Campolo

That's the point when you start going into Redwood, and you don't need to know anything about GraphQL or Prisma going into it, because Prisma is all baked into the Redwood CLI. You learn Redwood commands as you go through the tutorial, and those reach into Prisma. You don't really need to think about Prisma, and you don't need to think about GraphQL, because the generator commands write your schemas and they write your resolvers for you. By the end, you have a whole project. You haven't really written any GraphQL, even though you built a GraphQL project, because the generator commands are really nice. So you're able to get to the end of the tutorial with very little knowledge, but you kind of learn things as you go. This is why I talk about tutorial-driven development. They start you off on the front end. They get you deeper and deeper into the back end. They first have you generate a bunch of GraphQL stuff, then they have you build a form, and then you actually create your own inputs.

00:28:34 - Anthony Campolo

And it's basically structured in a way where I say, just start it and go beginning to end. By the time it gets to the end, hopefully most of it should make sense. And if not, then just go back and start diving deeper into any of the things that worked but didn't necessarily make sense.

00:28:49 - John Papa

Thank you for answering that. It sounds like you're saying to me in my head I'm imagining an onion RedwoodJS is an onion, and the way you structure the tutorials is you peel the outer layer first. I don't have to worry about what's in the other layers yet, but you're slowly peeling a layer at a time as you learn how this onion works.

00:29:07 - Anthony Campolo

I call it a spiral curriculum. This is an idea that I actually learned as a teacher. It's the idea of your learning as a spiral, and you go around a topic many times at deeper and deeper levels each time.

00:29:17 - Ward Bell

It's sticking with the onion analogy. You cry as you go. I couldn't resist, John. I'm crying. But they're happy tears. Tears of joy.

00:29:31 - Dan Wahlin

Well, I am happy because I was looking through, and as you mentioned, the CLI. Well, I think all of us are big fans of CLI in general, but it's pretty robust, it looks like. And as you just mentioned, it can generate all kinds of stuff. I'll let you maybe go into a little bit more about what you can do from a high level. But another thing I really like is there's a section in the tutorial called Redwood File Structure. I'll put it in the show notes. It provides convention. I like it. Every React team I ever went into at a company did it a different way. And if that team lead didn't have a convention, it was just chaos. And so it looks like this actually will give you a little bit more of a file structure. So anyway, tell us a little bit more about the CLI, though, because I think that's pretty compelling if you are new to these technologies.

00:30:27 - Anthony Campolo

Yeah, absolutely. The CLI is something that you'll be able to use to first generate your project and run your development server and do all of that. It's set up with a Webpack server, and it's going to watch for changes and do all that kind of stuff. So you don't have to do any configuration to get your dev setup going. So first off, that's a huge win. And then it has generate commands for basically all the different parts of your file structure. So as you're saying, it has a lot of opinions in the sense that your front end is going to have pages, it's going to have a layout, which would be something that persists between all the pages, like a nav bar. And then it'll have components, and cells, which will take a while to get into. But the point is that you're able to generate different parts of your project. So if you say, I want to create a home page or I want to create an about page, or I want to create a component that's going to display all of my blog posts, you can generate any of those things.

00:31:26 - Anthony Campolo

And then you can also do testing. So every time you generate anything, you generate a testing file also. So it kind of sets you up for TDD out of the box. And then you have Jest configured, so you can just run a test command and do tests on your whole project out of the box. And then there's a Storybook command. So for people who don't know, Storybook is this really nice tool for developing your components in a visual way, getting to easily see them on the page and scroll through different states they can be in. So it's also configured with Storybook out of the box, and you can just run a Storybook command. And every time, going back to the generators, the generators create a test file and a Storybook file with everything they generate. So you're already set up to do TDD and Storybook development with Storybook.

00:32:15 - Dan Wahlin

Can I actually then develop a given component right in isolation? I'm assuming it's not going to mock, for instance, the calls to the database, though. Those would be live.

00:32:26 - Anthony Campolo

So in terms of mocking and doing all that stuff with the database, that's stuff that is literally being released today. They just released the second tutorial today, which they've been working on for the last couple of months. So the last three to six months have been very heavily focused on mocking and what it means to mock these kinds of projects. So I can't give you a super good answer on that right now, other than there's a ton of work that's been put into it, and I'm going to be learning a lot over the next two months about that.

00:32:53 - Dan Wahlin

Awesome.

00:32:54 - Ward Bell

Yeah. I'm trying... I'm imagining how I might approach somebody, say a client came to me and said, 'Hey, we don't know what to do. We know we have this application. It looks like other applications we built in the past, maybe in traditional technologies.' And I can either walk in there and say, 'Well, I've got 20 technologies you're going to need.' Or I could say, 'No, I've got a pathway here that I know will work. It's made out of good things, so they didn't have to build all the parts individually. It's all parts you could hear about, read about, learn about independently.' But I'm pretty confident that this will lay a path of success for your organization in trying to accomplish this goal, because it's made from good stuff, but it's done in a way where you can take your developers and proceed in one framework to guide you, or one set of guardrails.

00:34:05 - Ward Bell

That seems to me to be the pitch for Redwood. John, does that ring a bell with you? And, Dan, does that ring a bell with you? Is that the, you know, do you see the. We all been in this problem where we have to walk into somebody who knows nothing and says, tell me how to build this thing. And we go, well, you know, and then we run out of fingers and toes, right?

00:34:22 - John Papa

You know, speaking of ringing a bell I hear a bell. Wait, I think that's that's the sponsor bell. Yeah. It's time to break for a word from our sponsors.

00:34:30 - Ward Bell

Are you building a web application? Need to deliver it soon and don't have the people to do it. Maybe you're not sure your company has the skill set or experience to do it. And maybe we can help. I'm your host, Ward Bell, and my day job is building applications for companies like yours. I don't do it alone. I'm president of IdeaBlade, a consultancy that specializes in enterprise web application development. We're particularly strong in Angular, RxJS, and Redux on the front end, and .NET and Microsoft technologies on the server. We're a small, tight-knit group of people hand-picked by me for their expertise, experience, integrity, and team spirit. Maybe we can help you with architectural guidance and hands-on development. And if there's something we don't know, and in our field really there's too much to know, we can draw on our personal connections in the Microsoft R&D, MVP, and Google GDE networks, as well as our international circle of really great developers, people we know and trust personally.

00:35:28 - Ward Bell

If you've got a project that's keeping you up at night, shoot us an email at info@ideablade.com. And now back to the show.

00:35:40 - John Papa

And we're back. Yeah, actually, Ward, it does ring a bell. I have to admit, though, I'm a little torn. I'm torn because I like the idea of having a set of guidelines and architecture and opinionated tool set that gets me on a path. And I feel like that's really great for teams. As Dan, you mentioned as well, you walk in and you have some kind of guidelines and style guide, whatever you may want to call things. But I also feel a little torn because I don't usually want those things until I really know where I'm going and what the bad options are, right? To have an opinionated architecture, often we come to these things once we realize we've done it the wrong way many, many times. So I'm also wondering, if I start with this kind of a thing, it sounds great on one hand that I can avoid a lot of those missteps, but what am I missing and not learning along the way?

00:36:40 - John Papa

If I don't make and learn some of those things on my own? So that's where I kind of wonder, and this is a question to all of you. Anthony, you've probably heard this from folks. Do people generally grab on to Redwood when they already have experience building applications, or is this more of a thing that you see people getting into when they're, you mentioned you're at a boot camp, you know, when they first come out?

00:37:07 - Anthony Campolo

I find that it can really appeal to both. And it's one of the things that I find so interesting about it. It was built by long-time Rails developers. The creator, Tom Preston-Werner, built GitHub with Rails, and a lot of people who come from that more full-stack back-end framework perspective, or from something like Laravel, find it very appealing. They look at it and say, okay, this is my foot into this whole front-end JavaScript world. That doesn't make a whole lot of sense to me yet. And then for me, I come out from the other end. I know all the front-end JavaScript stuff, but I don't know how to connect to the back end. So it can kind of meet you in the middle there, whether you know it well or not. And then in terms of how you should go about learning it, it's one of those things where I think people should build out small proof-of-concepts with all these frameworks, because at the end of the day, there are not really that many.

00:38:07 - Anthony Campolo

I think you should build a simple project with Gatsby, and with Next, and with Redwood, and also with Blitz and Bison, which I haven't really talked about. But I would say those are kind of the main five React frameworks that really matter right now. Wait, can you...

00:38:19 - John Papa

Say that again? Slowly.

00:38:21 - Anthony Campolo

Gatsby. So, GatsbyJS.

00:38:23 - John Papa

Yep.

00:38:23 - Anthony Campolo

And then Next.

00:38:25 - John Papa

Sorry. So let's kind of frame these. Gatsby is like a... well, I'll let you explain. Go ahead.

00:38:30 - Anthony Campolo

Yeah. Gatsby is more like a static site generator. So it's better for content and for blogs. It's for generating lots of pages. Next.js is for server-side rendering. If you're more concerned about having more dynamic server-rendered content, then you would want to use Next.js.

00:38:50 - John Papa

And Next.js is specific to React as well. Right.

00:38:52 - Anthony Campolo

All of these are built on React specifically, yes. There's a whole set of these for Vue and Svelte, which, if you want to know about it, I'd be happy to list as well. So you have Gatsby and Next. Those are old-school front-end React frameworks. Those have both been around for over four or five years. They're pretty old at this point. Whereas the newer stuff that's only been around for like a year or so is Redwood, Blitz, and Bison. These are all full-stack frameworks. The main thing you want to think about with Redwood is: do you want GraphQL or not? Do you want GraphQL to be the thing that has your front end and back end talk to each other? Or do you want to just do RPC calls straight into your database? Redwood is all in on GraphQL. Blitz.js does not use GraphQL. That's the main way you should think about how to distinguish those two from each other. And you've got Bison, which is a newer thing.

00:39:43 - Anthony Campolo

And that's not as well known. I'm just buddies with the creator and I think it's super-duper cool, so I tell everyone I can about it.

00:39:51 - John Papa

And what is Bison?

00:39:53 - Anthony Campolo

So Bison is kind of like a combination of Redwood and Blitz. It's another full-stack React framework, but it's built on Next. So this is actually the bigger point to explain between Redwood and Blitz: Blitz is built on top of Next.js. So I talked about Next.js. Next.js is built on React. Blitz is built on top of Next.js. So it's a meta-framework. Redwood takes the whole stack that Next and Blitz take up together. That's how you should think about how those two relate to each other. Whereas Bison is built on Next, but also uses GraphQL. So that's why I say it's like a combination between Redwood and Blitz. If anyone's interested in any of this stuff, I have an entire podcast to talk about all these projects called the Full Stack Jamstack podcast.

00:40:39 - John Papa

Cool. Well, please drop a link into the show notes for folks too, and we definitely like to cross-promote some podcasts out there.

00:40:45 - Dan Wahlin

Hey Ward, I'm just so excited that every single day there is a new choice for us to choose from. That's where I'm at with all this.

00:40:55 - Ward Bell

Yeah, I hear you. I'm feeling something different here.

00:41:04 - John Papa

Do you need a minute to go get a Tums or something?

00:41:07 - Anthony Campolo

And you don't need to go super deep into all these things. That's why I say you can get a simple project built with most of these in a couple of days if you're an experienced developer and you know how to code and you know how JavaScript works. It's not going to take you that long to wrap your mind around these. You just have to put the time in.

00:41:26 - Ward Bell

But you see, I want to go back to the problem set. So you gave me all those choices, right. But I don't want to be like, I know I don't want to build a static website, so why am I going to waste my time with your first two choices that you gave me?

00:41:36 - Anthony Campolo

But you have to use them first to know that. That's the problem.

00:41:39 - Ward Bell

No.

00:41:40 - Ward Bell

I'm coming to this podcast to learn what I should do and how I should think about these things. And I know when I come to this podcast, I know my problem. My problem is not to build a static website. If my problem is to build a static website... By the way, if coming to this podcast I would have learned that maybe I should use those, then I don't need to explore Redwood because I'm building a static website. Let me just use Gatsby. But I think something valuable for somebody listening to this, because they trust us, they shouldn't, but they do, and they come to us.

00:42:18 - Dan Wahlin

That's your first mistake?

00:42:19 - Ward Bell

Yeah, that's your first mistake, because you came to the podcast. But now that you're here and you're swallowing this stuff... No. I mean, we're here to help you cut through the chase. That's why people come, because it's impossible for everybody to know all this stuff. So the first thing to do is know what you're looking for. What's your problem? And now that you say, 'Well, I'm not building a static website. So hey, this Redwood thing seems like it's there, but is it safe?' It's the old Marathon Man thing: 'Is it safe?' Go look that movie reference up.

00:42:55 - John Papa

Yeah. I thought you were talking Gandalf here for a minute. There's a nice Gandalf reference about, 'Is it safe? Is it safe?'

00:43:02 - Anthony Campolo

The drilling into the tooth. Right.

00:43:04 - Ward Bell

Yeah, exactly. And because I don't have time to go try these things all out... Every time we or anybody says, 'Oh, just go try out these six frameworks and pick the one you like,' I'm like, who has time for that? John and I and Dan do, but nobody else does. Yeah, because we don't have real jobs. But... So there's got to be an element of trust here. And so I hear you, and I think that what Redwood was doing is not... So the people listening to this know, we're not saying, 'Oh, it should be Angular, React, Vue, or Redwood.' No. They're different. That's apples and oranges. Redwood is something different. It's meant to be a guide for building an application of a certain kind. If you've got that kind of application, then what you should be looking for is, in my view, the answer to two questions.

00:44:00 - Ward Bell

Is it built on things that are good and lasting? And second, am I going to be locked in in a way where I'm going to suddenly find myself in big trouble? As an experienced enterprise developer, when I'm confronted with things, those are the two things I'm looking for. Do I believe in the technology it's built from, and will I be locked in so I get stuck?

00:44:27 - John Papa

To live with this thing for a long time, especially in the enterprise, right? You build an application and you have to live with it for a couple of years. So, Anthony, do you feel like those technologies are ones that are going to stick around? And if so, I'm not going to hold you to it, obviously, because nobody knows these things. But the real question here is: do you feel that way? And then also, do you feel like it's easy enough to say that, let's say GraphQL wasn't here in a year, whatever replaces it, because things change, right, that you could swap something else into Redwood? Talk to our audience about folks who would make that bet on Redwood.

00:45:04 - Anthony Campolo

Both of these are really great questions. In terms of whether this is something that's going to be built to last, some would say that redwood trees last for a very long time. So that is definitely one of the goals in terms of wanting something that is going to possibly even outlive us, and that's where it comes with web technologies. At the end of the day, you're just kind of working with HTML and stuff like that. Even though you have all these crazy tools, everything gets transpiled down to something the browser does understand in the end. And in terms of lock-in, it's very much built to be portable. So I've kind of talked about how there are different ways to get online. There are different ways to deploy the front end. You could use either Netlify or Vercel. And then there are different ways to deploy the back end as well. Some people are spinning up their own servers on DigitalOcean to run it. So it's being made to be able to be used on as many deploy targets as possible.

00:46:05 - Anthony Campolo

And these two things correlate with each other. It's by using stable web tech that everyone understands that makes it more portable.

00:46:14 - John Papa

You know, I appreciate that as an explanation, but you're now inspiring me. You talk about libraries. At last I'm going to create a library called HouseflyJS. It only lives for 24 hours, and then your entire application has to be rewritten from scratch. In all seriousness, Anthony, thank you so much for coming on the show today to talk to us about RedwoodJS. We like to end the show with a final thought for our listeners out there. And this can be anything about RedwoodJS or just something else that's piqued your interest lately. I will start the final thoughts with my good friend Dan Wahlin. What's your final thought, Dan?

00:46:53 - Dan Wahlin

I have been thinking a lot lately, with everything going on in the world, and there's a lot going on, especially while we're recording this right now, about the concept of 'I am right.' And what I mean by that is if you think you are right, odds are you're probably wrong. And what I mean by that is I think everybody thinks they're right on technology, religion, politics, whatever it may be. But if we get to that point where we don't think we're so right that I can't even talk to other people, that's a good place to get to. You want to talk to other people. You want to hear other ideas. And if Ward says something I don't agree with, it doesn't mean I don't like Ward. It just means we don't agree. So I guess I would challenge all of us, and I say this because of what's going on right now, to stop thinking we're so right that we have to demonize the other argument or the other opinion or whatever it may be.

00:48:02 - Dan Wahlin

So that's kind of one that I need to work on. I think probably all of us do.

00:48:07 - John Papa

I think you're 100% wrong. Ward, what's your final thought for everybody?

00:48:13 - Ward Bell

Well, you know, I'm going to leverage Dan's perspective. And I do think it applies to technology because, again, we get people who get wrapped around a particular technology choice, and all they can do is figure out whether their thing is better or worse than somebody else's. And I think we're all developers of goodwill. I think development is a social activity in which we have to do things with each other. And that's, for me, the joy of it. I'm not the kind of guy who would like to sit in the corner and program all by myself forever. I enjoy hanging out with all of you and developing with all of you. And that's the pleasure of the work that we do, and you can only enjoy that pleasure if you do as Dan says and try to get beyond what you think is important to imagine, particularly with something that you think is maybe not quite right.

00:49:12 - Ward Bell

What were they thinking? And I don't mean that like, 'What were they thinking? What's Dan thinking?' No. I mean: who is Dan? What is his thought about this? How did he come to that place? How do we use that to evolve together to some new place? So I'm going to just piggyback on you, Dan.

00:49:29 - Dan Wahlin

I'm with you. Anthony, what are your final thoughts?

00:49:36 - Anthony Campolo

Yeah. I just really want to thank you guys for having me again. I'm really passionate about podcasts because I spent a long time learning a lot of this stuff on my own, and being able to listen to podcasts by guys like you really provided me so much knowledge and mentorship. And the value of it I really can't overstate. So thank you for all the work you guys have done over all these years. It's really incredible. And I would also say, I hope that it wasn't too overwhelming for anyone listening. I know these guys are long-time developers and they can hang, so I wanted to cram as much information as I could into this. But like I said, I really came at all of this from a very low level of knowledge of all this tech. And I was able to get into it and I was able to enjoy the process and be invigorated by it, and not be beaten down by it like I was by the stuff I was learning before Redwood.

00:50:32 - Anthony Campolo

And so I really just encourage anyone to reach out. If you find this interesting, we have a forum, we have a Discord, we have an incredibly active, vibrant community of a lot of really great people who enjoy building, enjoy helping other people build, and want to answer your questions and help you grow and make cool stuff.

00:50:50 - Ward Bell

Thanks for that, Tony. Yeah, I think we're all on board with that.

00:50:54 - John Papa

Thank you, Anthony, for those final thoughts. And I'll also just add my thoughts here. Recently I was faced with a situation at work where we were talking about how to approach a problem, and one of my first instincts was to talk about everything that was wrong with the situation and what we needed to fix. And Dan, you made me think about this. You talked about what's right. Luckily, I've made that mistake enough times where I was able to stop myself and say, well, wait a minute, who am I talking to? Who's my audience here? And I started realizing the audience was actually the people who created the thing. So instead of coming at somebody... Imagine you created something and the first thing they do is come at you and you hear all the things that are wrong with what you did. We're all humans, okay? You can say it in the kindest way possible, but sometimes it's just not what you want to hear, or how you want to hear it.

00:51:50 - John Papa

So then I often reflect on: what do I want to have happen out of this? What's the outcome that I want? And that outcome can change based on the situation. Sometimes I want the outcome to be that there is a plan to make these changes, or that there is a plan to communicate why things are built this way, or I want the outcome to be fill in the blank. When I figure out what that outcome is that I want, it really helps me figure out how to have the conversation. And so I want to just leave that out there for folks to think more about: what do you really want to have happen when you're in these conversations with people at work, in GitHub comments, on Discord, or if you're visiting Ward Bell in the redwoods? So with that, I want to thank you all for coming on the show today. We had a lot of really dry wood humor out there today, enough that you could shake a stick at. So, plenty of puns.

00:52:42 - John Papa

Thank you for listening to Web Rush for yet another week, and you'll hear from us every Thursday morning. See you next time.