RedwoodJS Brings Fullstack to Jamstack
Anthony Campolo joins JS Jabber to discuss the benefits of RedwoodJS for modern web development and its position within the evolving JS ecosystem
Episode Description
Anthony Campolo introduces Redwood JS, a full-stack React framework using GraphQL and Prisma, and explains how it compares to Next.js and other Jamstack tools.
Episode Summary
Anthony Campolo, developer advocate for Redwood JS, joins the JavaScript Jabber panel to explain what Redwood is and why it matters in the evolving JavaScript ecosystem. The conversation begins by distinguishing Redwood from Next.js: while Next excels at client-side rendering and routing, Redwood provides a complete full-stack solution with strong opinions about database connectivity through Prisma and front-end-to-back-end communication via GraphQL. Anthony walks through the framework's architecture—a monorepo with a web folder for React and an API folder containing GraphQL schemas, resolvers, and Prisma models—and explains how Redwood's "cells" concept makes data fetching declarative. The discussion covers the project's origin story, tracing it back to Tom Preston-Werner, creator of Jekyll and first CEO of GitHub, who started Redwood in 2019 to bring Ruby on Rails-style conventions to modern JavaScript development. The panel explores deployment via Netlify and Heroku, current constraints around SSR and NoSQL support, and how Redwood fits into the broader "third age of JavaScript" alongside frameworks like Blitz.js and Inertia.js. Anthony emphasizes that Redwood's core value is enabling a single developer to build and ship a complete application quickly, drawing on his own bootcamp experience as proof.
Chapters
00:00:00 - Introduction and Guest Background
The episode opens with the panelists checking in from their respective locations before introducing guest Anthony Campolo, who expresses his enthusiasm for appearing on the show. After a brief sponsor message, the conversation turns to Anthony's background, including his nontraditional path into software development from music education and running a performing arts summer camp.
Anthony explains how he attended the Lambda School bootcamp, learned React, and eventually discovered Redwood JS, which gave him both a productivity boost and a mental model for thinking about full-stack applications. He shares that he was invited to join the Redwood core team as developer advocate, setting the stage for a deep discussion about the framework and its place in the JavaScript ecosystem.
00:03:26 - Redwood JS vs Next.js and the Jamstack
Aimee asks the central question of how Redwood compares to Next.js, the dominant React framework. Anthony explains that while Next provides excellent client-side routing and page-based conventions, it lacks opinions about database connectivity—something Redwood addresses through its integration with Prisma as an ORM. Dan then steers the conversation toward defining the Jamstack, and Anthony traces its evolution from static site generators like Jekyll and GitHub Pages to the modern paradigm of globally distributed front ends that need back-end capabilities.
Anthony positions Redwood as the framework that brings full-stack development to the Jamstack world, extending the reliable deployment paradigm of static sites into the entire application stack. This framing establishes Redwood's unique identity: not just another front-end tool, but a complete solution that bridges the gap between front-end Jamstack conventions and back-end functionality.
00:06:36 - Architecture and Technical Deep Dive
Dan asks Anthony to explain the actual architecture of a Redwood application. Anthony breaks it down: a monorepo with a web folder for the React front end and an API folder containing both a GraphQL schema with resolvers and a Prisma database layer. The front end communicates with the back end through GraphQL, and Prisma handles the object-relational mapping to the database. Steve asks clarifying questions about the folder structure, and Anthony details the DB folder's Prisma schema and the src folder's GraphQL definitions and services.
The discussion also addresses how Apollo Client and Apollo Server are embedded within the framework but abstracted away so developers write "Redwood code" rather than thinking about individual tools. Anthony explains how the entire back end gets bundled into a single Lambda handler, acknowledging it's somewhat of an anti-pattern but one that works effectively for the framework's use case.
00:11:45 - Deployment, Cells, and Data Fetching
The conversation shifts to deployment, with Anthony explaining the current workflow of deploying the front end to Netlify and the database to Heroku Postgres. He discusses Tom Preston-Werner's vision of a "Universal Deployment Machine" where pushing code to a git repo is the entire deployment process. Dan then asks about SSR and static site generation, and Anthony explains that Redwood is optimized for interactive web applications rather than content-heavy sites, noting that some developers use a "headless Redwood" approach with Next.js on the front end.
Anthony introduces Redwood's "cells" concept, a declarative data-fetching pattern where developers write a GraphQL query and define four states—empty, loading, error, and success—similar to React Query. This convention eliminates the repetitive boilerplate of handling asynchronous data states. Dan asks about the React-side implementation, and Anthony explains that the framework handles the internal plumbing through higher-order components so developers can focus on their application logic.
00:22:30 - Developer Experience and Getting Started
Dan asks about Redwood's core value proposition, and Anthony answers decisively: enabling a single developer to build a complete application quickly and reliably. He illustrates this with his Lambda School experience, where teams of developers couldn't ship working apps in a week, but after learning Redwood, he could build any of those projects solo in a day. AJ pushes back, noting that every framework makes similar claims, and Anthony acknowledges this while emphasizing the mental model Redwood provided him.
The discussion turns practical as Dan asks how to actually start a Redwood project. Anthony explains the tutorial-driven development approach and the CLI-based workflow with extensive generator commands, drawing parallels to Ruby on Rails' scaffold commands. He notes that while developers need some React knowledge before starting with Redwood, the front-end learning curve is minimal for anyone with React experience—the real learning happens on the back end with GraphQL and Prisma.
00:33:43 - Ownership, Constraints, and the Broader Ecosystem
Dan asks about project ownership, and Anthony explains that Tom Preston-Werner funds development through Preston-Werner Ventures while keeping all code fully open source. The conversation then explores constraints: Prisma's current limitation to relational databases, the lack of session management beyond JWT, and the framework's optimization for interactive apps over content-heavy sites. Anthony shares his experiment of replacing Prisma with FaunaDB, demonstrating the framework's flexibility.
Anthony broadens the discussion to frame Redwood as part of a larger movement in JavaScript, referencing the "third age of JavaScript" concept and comparing Redwood to related frameworks like Blitz.js and Inertia.js. Steve draws parallels to the historical pendulum swing between monolithic and decoupled architectures, and Dan observes that despite changing techniques, developers are still fundamentally building CRUD applications. The episode wraps with picks and Anthony promoting the Full Stack Jamstack podcast.
00:45:16 - Picks and Wrap-Up
Dan takes over hosting duties as Aimee and AJ have stepped away, and Steve shares his pick of the classic 1956 Hitchcock film "The Man Who Knew Too Much" starring Jimmy Stewart and Doris Day, also mentioning the 1997 Bill Murray comedy spoof. Dan picks the State of JS 2020 survey results, highlighting the dominance of Webpack, React, TypeScript, Express, and Jest while noting the podcast's sixth-place ranking in the survey.
Anthony shares his picks, including the Full Stack Jamstack podcast he co-hosts with Christopher Burns, which covers frameworks like Redwood, Blitz, and Bison along with tools like Fauna and Prisma. He also points listeners to his prolific blogging on Dev.to under the handle AJCWebdev. AJ briefly returns to apologize for missing most of the episode due to a client issue, and Dan wraps up the show at the 00:53:18 mark.
Transcript
00:00:06 - Aimee Knight
Hey, everybody. Welcome to another episode of JavaScript Jabber. This week we have our panelists. We have Dan Shapiro.
00:00:13 - Dan Shappir
Hi from Tel Aviv, where it's actually winter.
00:00:15 - Aimee Knight
We have AJ O'Neil.
00:00:17 - AJ O'Neal
Yo yo yo. Coming at you live. I don't think it's still winter.
00:00:22 - Steve Edwards
Steve Edwards, hello from Portland, where it's definitely winter.
00:00:27 - AJ O'Neal
It's still snowing. It's winter. Sorry.
00:00:29 - Aimee Knight
Yeah. Check outside. I am Aimee Knight, coming at you from Nashville, Tennessee. Our guest today is Anthony Campolo. Do you want to introduce yourself?
00:00:39 - Anthony Campolo
Hello. Coming at you from Pleasanton, California. It's sunny but pretty windy. It's nice. Thank you for having me. I'm a huge fan. I feel like I'm a guest character on one of my favorite TV shows right now.
00:00:52 - Aimee Knight
We're happy to have you.
00:00:54 - Charles Max Wood ad read
When I went freelance, I was still only a few years into my development career. My first contract, I was paid 60 bucks an hour. Due to feedback from my friends, I raised it to 120 bucks an hour on the next contract. Due to the podcasts I was involved in and the screencasts I had made in the past, I started getting calls from people I'd never even heard of who wanted me to do development work for them because I had done that kind of work, talked about it, or demonstrated it in the videos and podcasts that I was making.
Within a year, I was able to more than double my freelancing rates, and I had more work than I could handle. If you're thinking about freelancing or have a profitable but not busy or fulfilling freelance practice, let me show you how to do it in my Dev Heroes Accelerator. Dev heroes aren't just people who devs admire; they're also people who deliver for clients who know, like, and trust them. Let me help you double your income and fill your slowdowns.
00:01:46 - Charles Max Wood ad read
You can learn more at Dev Heroes Accelerator dot com.
00:01:50 - Aimee Knight
Today we're going to be talking about Redwood JS. Do you want to give us an intro to yourself and then an intro to Redwood JS?
00:02:00 - Anthony Campolo
I come from a nontraditional background in terms of how I got into coding. I was a music teacher and spent a while after that running a performing arts summer camp. I got really into admin work, running events, doing logistics, that kind of stuff. It was great and I learned a lot, but I wanted to get into something more creative and more interesting in terms of what you can learn and build.
I eventually found my way to coding and did the Lambda School bootcamp, which is a remote bootcamp. I learned a lot of React and eventually found my way to this framework, Redwood JS. It's a full stack framework for React, and it's basically a tool to help integrate a lot of the things you need to do when you're building a modern React application. I was really struggling with that at the time, going through the bootcamp and trying to build these applications while also just learning what code is in the first place.
00:03:04 - Anthony Campolo
I found that it gave me a boost in terms of what I could build, but even more than that, it gave me a mental model. That's kind of where I'm at right now. I was asked to join the core team as the main developer advocate. I get out and communicate about the project and talk about it with people such as yourselves.
00:03:26 - Aimee Knight
That is awesome. That's also, I don't know, it's impressive. I love hearing success stories like that. The first question that comes to mind, and what we were talking about before this started, is that Next.js is kind of the go-to for React. How does Redwood JS compare to that?
00:03:49 - Anthony Campolo
Next is a fantastic framework, and it is good for creating really sophisticated client-side apps, doing your routing, and giving you nice page-based conventions around how your components match your pages. So there's a ton of great stuff that Next gives you. But what it really doesn't give you is any opinion in terms of the database. Now, some people will call it a full stack framework because it has a server side, and this is true, but it doesn't have something like an ORM. It doesn't have something like Ruby on Rails has with ActiveRecord.
That's the main difference that I like to stress with Redwood: it has a very strong opinion about how it connects to your database because it uses a tool called Prisma. We can get into that a little bit as we go, but basically it has an easy way to connect your front end to a back end.
00:04:46 - Anthony Campolo
So it's a full stack framework, kind of like Ruby on Rails. Not exactly, but it gives you the full front end and back end all contained in your project.
00:04:56 - Dan Shappir
I understand that it's definitely in the category of Jamstack frameworks. We mentioned Next, and there are obviously other Jamstack options. Jamstack is kind of everywhere. Maybe it's worthwhile, even before we begin to talk about Redwood specifically, to talk about what Jamstack is and how it's different from things that aren't Jamstack.
00:05:20 - Anthony Campolo
If people want to know about the Jamstack, one of the best resources is actually an episode you guys did back in 2016 with Matt Biilmann, CEO of Netlify. He kind of laid out back then what the Jamstack is to him. But for me, what it really is is an evolution of static sites and static site generators.
If you think of Jekyll and GitHub Pages, Jekyll was this really great static site generator that was written in Ruby, and then it integrated really well with GitHub Pages. So you could use Jekyll to generate a simple web page and then use GitHub Pages to get that site on the internet really, really simply. The Jamstack was kind of the idea of, okay, we have this really nice deployment paradigm for these static sites, and we get a ton of reliability and security and availability from the globally distributed CDNs. But what we don't have is a back end. How do we do all the things we need to do with the back end?
00:06:23 - Anthony Campolo
So Redwood is about how do we take this really nice deployment paradigm we have in our front end Jamstack world and extend that into the entire stack. That's why we say we're bringing full stack to the Jamstack.
00:06:36 - Dan Shappir
But what does that actually mean? Does it mean that there's just a whole bunch of standard APIs that are provided in the back end? Do I need to learn a whole lot of things? It seems that based on your initial description, it's kind of opinionated, but I'm not exactly sure what the bigger picture is.
00:06:57 - Anthony Campolo
Let me break down the architecture for you. It's not super complicated. It's definitely opinionated. It's a convention-over-configuration kind of idea, but it's still more like strong opinions loosely held. You can change things and move them around.
Let's talk about the canonical Redwood stack, and then we can talk about how to modify it later. The canonical Redwood stack is a monorepo with a web folder and an API folder. Your web folder is basically your React front end. You can think of it like your Create React App or like Next. That's your web folder.
Your API folder has two things: your GraphQL schema and resolvers, and your ORM tool, which is Prisma.
00:07:56 - Anthony Campolo
So your front end speaks to your back end through GraphQL, and then it speaks to your database through Prisma. That's the high-level architecture.
00:08:07 - Dan Shappir
So you're yet another GraphQL poster boy.
00:08:11 - Anthony Campolo
Big fan of GraphQL, yes. I don't think GraphQL is the solution to all problems, but I think it is a very nice way for the front end and the back end to speak to each other and have a coherent language, so everyone doesn't have to create their own bespoke JSON APIs. That's really what I see GraphQL providing. It's a way for the front end and the back end to talk to each other in a more coherent way.
There are obviously lots of benefits in terms of not over fetching and things like that. You guys have done tons of episodes on GraphQL, but for me, it's the mental model of how front end developers are able to write GraphQL that makes it so appealing, because it makes it easy to write queries or even write mutations without necessarily knowing the entire back end and how it works or how to interact with it.
00:09:09 - Anthony Campolo
You can just give them a simple convention for how to write these queries and mutations to access the back end without learning the entire back end to do that.
00:09:18 - Dan Shappir
Oh, sorry. Go on.
00:09:20 - Aimee Knight
I was going to ask, before we pick up steam too much, about the origin stories of Redwood JS: how long it's been around, who started it, and all that good stuff.
00:09:33 - Anthony Campolo
The history of the project is one of the things that really drew me to it in the first place. I spent a lot of time blogging about it and drawing out this whole history in a long, multi-part series that I wrote about it, and I'll link it in the chat after I finish.
The history is that Tom Preston-Werner was the creator of Jekyll. He was also the first CEO of GitHub, so he's connected to all these ideas in terms of static site generators and how all this fits in. Tom was creating a company called Chatterbug with a friend of his named Peter Pistorius. This was in 2018. Chatterbug is a language learning platform, and it was a React front end speaking GraphQL to a Rails back end. Because Tom was an old school Rails developer, he built GitHub with Rails, and that was what they were familiar with.
As they were working with all this React and GraphQL stuff, they saw a lot of benefits, but getting it to all work together was really hard and took a lot of time and specialized knowledge. They were thinking, how could we figure out a nice framework to give us Ruby on Rails-like conventions, but for this modern JavaScript paradigm we're working with?
In 2019, they started the project. They started a repo in June of 2019 with a README, because Tom is known for README-driven development. He's the one who coined that term. They were working on it by themselves, just the two of them, for close to a year. Then March of 2020 is when it really launched and went public. That was version 0.1. So we're getting close to about a year from the 0.1 release, and we're aiming for v1 within the next couple of months.
00:11:40 - Anthony Campolo
That's kind of the history of where we've been, where we are, and where we're going.
00:11:45 - Aimee Knight
Awesome. Thank you.
00:11:46 - Steve Edwards
I have a question real quick. I want to go back to the structure of the application. You said you'll have a web directory for your front end, and then you said you'll have GraphQL. Tell me about the two directories for the back end as well.
00:12:01 - Anthony Campolo
Absolutely. Your back end splits into two folders. There's your DB folder, which is Prisma, and it has a Prisma schema. If you've never seen a Prisma schema before, it's basically a way to define both what database you're using and your models at the same time. So you can say, I want this to connect to a SQLite database or a Postgres database or a MySQL database. It doesn't do NoSQL right now, but it's on the roadmap.
Then you write a model. It would be like model Post, and that post would have an id, title, body, createdAt. So that's your DB folder. It's just a Prisma schema.
Your other folder is an src folder, and it has your GraphQL schema. Your schema will be very similar to your Prisma schema. You'll also have type Post and it'll have id, title, body, and createdAt. Then you'll define your mutations and your queries and all that. If you don't know what an SDL is with GraphQL, that's something you learn as you go along with the project.
00:13:09 - Anthony Campolo
Then you also write your services. You can think of them like back-end controller logic a little bit. It's not quite the same, but that's the idea. They're kind of like resolvers. Then you import your DB, so you import the Prisma client, and that's what's doing the object-relational mapping.
There's one file that stitches all that together and shoves it into one giant GraphQL Lambda handler. We call this a Lambda. The entire thing is like one giant monolith shoved into a Lambda, which is, in some ways, a bit of an anti-pattern, but it works. That's how the back end is stitched together. Does that make sense?
00:13:56 - Steve Edwards
So the front end is only communicating with GraphQL. GraphQL is using Prisma for the actual communication with your database. Is that correct?
00:14:04 - Anthony Campolo
Yeah. You got it.
00:14:06 - Steve Edwards
Okay.
00:14:06 - Dan Shappir
And the GraphQL backend implementation is part of the framework itself. You're not relying on anything like Apollo or something like that.
00:14:16 - Anthony Campolo
Yes and no. The framework is an assemblage of tools, Apollo being one of those. So it does have Apollo Client and Apollo Server in it, but you never really write Apollo. It's one of those things where, because of how all the tools are integrated, you write Redwood. You don't think about any of the tools that make it up until you hit problems, of course. But the main thing is that it takes things like Apollo and Prisma and integrates them so you don't have to think about the tools too much. It should just work.
00:14:47 - Dan Shappir
And in terms of deployment of the back end, what you've said is essentially that it runs on the AWS platform. It runs as Lambda functions or services.
00:15:02 - Anthony Campolo
That's exactly right. So what happens is, if you go through the tutorial, which is how most people are going to build out a Redwood app, you deploy your front end to Netlify. Netlify is what deploys your front end, and Netlify is what handles the AWS Lambdas for you, because you can have a Netlify Functions folder that does that. Then your back end is a Heroku Postgres database. You take that environment variable and put it into your Netlify dashboard.
So you just have a Netlify front end connected to a Heroku Postgres back end, and you don't have to think about the AWS stuff. Now, what we want is the whole thing to be deployed in one single area. If we can get the front end and the functions and the back end all on AWS in one dashboard, it's nice and easy to use.
00:16:04 - Anthony Campolo
That's kind of the dream and what we're working on right now. Right now it's still somewhat distributed, where you need two dashboards and you need Netlify and Heroku and to integrate those two together. The integration is ridiculously simple, but it's still a little bit of manual effort.
00:16:21 - Dan Shappir
So essentially you're leveraging the fact that Netlify is kind of becoming the go-to solution for various Jamstack offerings, bridging the gap between the cloud service providers and CDNs and the Jamstack platform of your choice. Right?
00:16:42 - Anthony Campolo
Yeah. It's worth mentioning here that Tom was an early investor in Netlify. He's been involved in Netlify since the very beginning. He has an idea that he calls the Universal Deployment Machine. This idea is that you should be able to write your code on your computer, push it up to a git repo, and that is it. The website goes live. Everything is done. That is the entire deployment process. That is what he is aiming at with the idea of the Universal Deployment Machine.
Then getting that to deploy to the world is the next level. How do you get the Universal Deployment Machine to not just deploy to US East 1?
00:17:24 - Dan Shappir
In terms of being Jamstack, usually what's associated with that is static site generation and, recently, SSR. Some Jamstack platforms support it; some don't. What's your attitude toward this?
00:17:42 - Anthony Campolo
If you're looking for static site generation or SSR, you should be looking at tools like Gatsby or Next. That's really what those are optimized for. This is why some people are actually taking Next and attaching it to a Redwood back end. Some people are doing what I call a headless Redwood, where they don't use the Redwood head. They don't use the Redwood website; instead they just use the Redwood API side, the back end that I was explaining to Steve. Then they attach any kind of front end they want to it, in this case a Next.js client, because Next.js gives you really nice SSG and SSR. It has a lot of stuff baked in. They've been optimizing that for years.
That type of stuff is making it into Redwood. There's a lot of work being done on that from the team, but it's really more aimed at data-intensive interactive applications, more about this idea of web apps over websites.
00:18:41 - Anthony Campolo
This is something that Shawn Wang, who some of you may or may not know, talks a lot about. He says Svelte is for sites and React is for apps. To me, Redwood encapsulates that idea of using React for apps.
00:18:56 - Dan Shappir
If I'm just using Redwood, then currently what I probably would build is a back end which effectively serves an empty web page, with the whole rendering done with client-side React talking to the back end using a Jamstack GraphQL API. Alternatively, if I want to do it with server-side rendering or static site generation, then I might be using Redwood, for now at least, as a sort of headless CMS and hooking it up with something like Next.js.
00:19:37 - Anthony Campolo
It's kind of a question of what you need to build and how sophisticated it needs to be, because you wouldn't have to go that far. You could bring in something like React Snap into your Redwood project, and that could do your pre-rendering for you. There's a lot of flexibility here in terms of how you can do all of this.
Let me explain Cells. I think this might help explain the data-fetching aspect. Redwood has a convention called a cell, and this is the way your front end speaks to your back end. We were talking about GraphQL. When you write GraphQL, you define a query or a mutation in your schema. Once you define it, you can write those queries really easily.
A cell is where you write the query at the top, and then you have four states that your data can be in. It will know whether it's empty, whether the data is loading, whether you've gotten an error, or whether you got the data and you got success. If anyone has worked with React Query, this is a similar kind of idea. We want to make data fetching declarative.
Once you have the cell set up, you basically write the query and then your success state. The other stuff gets handled for you. You can put in a nice spinner or something for loading if you want. Once you get the data, you can do whatever you want with it.
That's why I say you can bring in something like React Snap and figure out the pre-rendering yourself, and eventually the pre-rendering will be baked into the framework, so you don't have to do something like that.
00:21:23 - Anthony Campolo
That's kind of how we are right now because we're not at v1 yet. That's the last piece of polish we're still working out.
00:21:30 - Dan Shappir
So in order to implement that, what do you provide on the React side? Is it custom hooks, higher-order components that you wrap your components in, or how does it look from the perspective of the React developer?
00:21:45 - Anthony Campolo
From the perspective of the React developer, they don't really have to think about it. This is all internals in the framework, the quote-unquote magic. That can make some developers uncomfortable. If you ever have to source dive into it, then they're like, what if it doesn't work?
The main thing is that it's doing the internal plumbing for you in terms of figuring out whether you got an error or not. None of this stuff is super crazy or difficult. It's just obnoxious to have to constantly write all these conditionals and handle what happens when you get the data, you get the error, you get a success. It's giving you nice conventions for that.
I believe it's using higher-order components. That's really more of a question for Peter than for me.
00:22:30 - Charles Max Wood ad read
Hey folks, if you love this podcast and would like to support the show, or if you wish you could listen without the sponsorship messages, then you're in luck. We're setting up new premium podcast feeds where you can get all of the episodes released after Christmas 2020 without the ads. Signing up will help us pay for editing and production, and you can go sign up at devchat.tv.
00:22:49 - Dan Shappir
First of all, I would say that people who really hate magic, what are they doing using frameworks in general and React in particular? Half of React itself is magic to a lot of the people who are using it. It's interesting to me that so many solutions out there try to solve essentially the same problem of how to easily create a React-based user interface that asynchronously loads data and is able to show some sort of progress indicator or an error message in the case of failure. It's interesting to see how many solutions out there are trying to solve essentially the same problem. It turns out that it's a difficult problem, apparently.
00:23:35 - Anthony Campolo
That's definitely the main thing. We're trying to come up with conventions because we see everyone doing all this repeated work and trying to figure this stuff out. We're like, why don't we just come up with nice conventions that we can all agree on? So you're right that there's a lot of duplicated effort going on right now.
00:23:52 - Dan Shappir
From your perspective, where is the heart of the Redwood JS offering? Is it this front end library, is it this back end wrapping and conversion of GraphQL into the database, is it all of the above strung together, the fact that it's integrated? What's the core value proposition?
00:24:21 - Anthony Campolo
The core value proposition is that it will allow one developer to build a complete application quickly and reliably. That is the value proposition.
I can speak to this as someone who went through a bootcamp and tried to assemble all these technologies myself in our build week. To give some context here, we have what are called build weeks at Lambda. A build week is where you are put into a group. Everyone is at different points of the program: some people are just at the beginning learning HTML and CSS, some people are learning React or Redux, some people are learning Node. All these people are brought together in a team and, for one week, they have to create a project. These projects are things like saving bookmarks or a note-taking app, your basic CRUD application with users.
I did three of these build weeks, and in all three of them we had a team of people working on it for a week, and none of those applications ever shipped. None of them even got to the point where they functioned as they were supposed to in terms of the requirements. Once I had learned Redwood and saw what it could do, I realized I could build any of those projects by myself in a day. That is the value proposition of Redwood.
00:25:41 - Dan Shappir
Okay, so let's say I'm sold, and it does sound like an excellent value proposition.
00:25:47 - AJ O'Neal
I've got some pushback on that.
00:25:50 - Dan Shappir
Okay.
00:25:51 - Anthony Campolo
Go for it.
00:25:52 - Dan Shappir
Go for it. Go for it.
00:25:53 - AJ O'Neal
Because that's what every tagline is for every framework ever.
00:26:00 - Anthony Campolo
I know, and that's why I can say I lived it and that's why I say it's true. I actually lived it and experienced it myself. Maybe it won't work for everyone else, but for me, that is what happened.
00:26:11 - AJ O'Neal
It jives with your brain style.
00:26:13 - Anthony Campolo
It did, yes. Frameworks are not tools for your code. Frameworks are tools for your mind. This is what I've gotten from Redwood more than anything else: it gave me a mental model to think about my app.
00:26:25 - AJ O'Neal
Yeah. And you were going to say something?
00:26:26 - Dan Shappir
My question is really, forget whether I'm sold or not. Let's say I want to try it out. What's the process? How do I start a Redwood project?
00:26:36 - Anthony Campolo
What's really great about Redwood is that Tom started README-driven development ten years ago. The idea was that you should start by writing your README and then write your code to make your README true instead of the other way around. What we are doing with Redwood now is what we're calling tutorial-driven development. It's the same idea: you first write your tutorial, and then you write your code to make the tutorial work.
This is partly why I say it really jives with my mental model. Not only is it a good way to think about your app, they have an incredibly well-done sequence of tutorials that teach you how to use it. It walks you through how to build up a Redwood app progressively to reveal the framework to you as you're building it. They start by having you build pages and layouts and do your routing, all your front end. Once you get that worked out, you create a Prisma model and start doing database stuff and migrations.
00:27:42 - Anthony Campolo
Then you create a form and handle inputs, then you deploy it, and then you add authentication. For anyone who wants to get started, Redwood is very simple. Go to the tutorial, start at the beginning, and just go. When you hit any problems, come to the forums, come to Discord, ask for help. You'll get five people who will help you out almost immediately.
00:28:04 - Dan Shappir
Okay, but in more practical terms, is it like other projects and frameworks we've had as guests here on the show? Some of them take a CLI-type approach, like Create React App. Some take an approach like Svelte, where it's more or less just clone a git repo and start with that. So what's the practical process? Do I run a CLI? Do I do an npm install? What's the technical process?
00:28:37 - Anthony Campolo
It's very much in the Ruby on Rails demo style where DHH builds a blog in like 15 minutes with lots of scaffold commands. So yes, there's a CLI with lots of generator commands. You can generate pages, layouts, cells, services, almost anything you could possibly think of in a Redwood project. So it's very CLI-based. It's based around the idea that you should have to write as little code as possible. You should only have to write code when you absolutely have to, when we can't figure out how to write it for you with the generator.
So that's the main workflow for people who come from more CLI-based tools. They're going to be very, very comfortable in Redwood.
00:29:28 - Dan Shappir
And the design of the UI itself, is it usually, if I'm not using something like Next.js and I'm just using Redwood, mostly client-side rendered? How do I fit the designer into the process for building the actual UI?
00:29:48 - Anthony Campolo
When I think of how to fit a designer into the UI, I'm not thinking about rendering. I'm thinking about CSS. So I'm not sure I entirely understand your question.
00:29:56 - Dan Shappir
Well, look, CSS and HTML are the tools of the trade. What I mean is somebody needs to ultimately design the user interface so that it can be implemented by code. Portions of it are straight HTML with CSS. Portions of it are created by JSX. What's the process of constructing the front end?
00:30:23 - Anthony Campolo
It's the same as any React app you're going to build. You're going to build components in React. Then you can write some CSS. If you want to bring in something like Tailwind, you can do that as well. We have a Tailwind command that will configure it for you.
So the experience of working with the front end should be very familiar for anyone who's worked with React over the last three or four years. It's very hooks-based, very functional. We don't really do class components. The back end GraphQL and Prisma stuff is what you're probably going to have to learn. That's what's going to be foreign. But the web side should be essentially zero learning curve for someone who already knows React.
00:31:04 - Dan Shappir
Cool. That sounds like a really good value proposition.
00:31:06 - Anthony Campolo
For me, it was really cool because I learned so much React in my bootcamp. It was technically called a full stack web development program, but I felt like it was a front end program with a tiny bit of back end tacked on at the end. I was bitter about that at the time because I felt like I was getting gypped and not getting the full education.
I've seen the value in that because of the things I learned in Lambda School in terms of how to work with React. It allowed me to hit the ground running with Redwood because I'd already done all this stuff with Create React App. I'd already hit all these issues with React Router. I'd already tried out Gatsby and Next and tried to wire those up to databases and get them to speak to Postgres using some sort of Express API.
00:31:58 - Anthony Campolo
I'd already done all this. When I saw Redwood, I was like, okay, this framework is kind of weird. There are some tools that I don't really know, but the React stuff makes sense. I'm able to go through that.
As I started hitting more and more of the back end, as I worked through the tutorial, you start picking up more and more GraphQL and Prisma as you go, and it just kind of makes sense. If you've never used React before, you should absolutely not jump into Redwood. You should start with Create React App. You should figure out how to get a Create React App generated, make a basic project, and get that deployed to something like Netlify or Vercel.
I would recommend going through that whole process. Then, once you have some familiarity with React and the paradigms involved, you're basically good to go in terms of starting to learn Redwood.
00:32:48 - Dan Shappir
That's kind of funny though, because at the beginning you said that one of the selling points for Redwood is that you don't need to know much in order to use it to build a web app. But now you're saying you actually need to know all that stuff.
00:33:07 - Anthony Campolo
I'm saying you need to know a little bit. Knowing Create React App isn't that huge of a barrier compared to all the other stuff that Redwood is giving you. So I say generate one Create React App project and put that online. If you haven't done that, you're not a React developer.
It's not meant to teach you React. It's assuming you have at least a little bit of React knowledge, but a lot of people have a little bit of React knowledge and you can't do anything with a little bit of React knowledge. Redwood is saying if you have a little bit of React knowledge, we can at least get you somewhere.
00:33:43 - Dan Shappir
Now who owns? Sorry, I just wanted to ask who owns Redwood. Is it a totally open source project? Is there a company behind it who's supporting it?
00:33:53 - Anthony Campolo
It's a little bit of both. I say it's a passion project of an eccentric billionaire because that's basically what it is. Tom is funding it in the sense that he is very well off from the acquisition of GitHub by Microsoft, and he has Preston-Werner Ventures. Preston-Werner Ventures is funding a handful of the developers on the core team.
But all the code is open source. The project has been and will always be open source. That is the entire point. There is some funding behind it to alleviate the fears people might have of an open source project disappearing and falling off. But it's not like we're going with an open-core model. It's 100% open source.
00:34:42 - Aimee Knight
He gave me a good history lesson. I didn't actually know that the person behind Jekyll was the person behind GitHub.
00:34:51 - Anthony Campolo
He was also behind Semver and TOML.
00:34:53 - Aimee Knight
Oh, wow. Okay. That's a lot there. I did not realize that. I feel like maybe I knew about Semver but not TOML.
I had a question, and it escaped me. Okay, it's come to me now. You talked about what Redwood can do and the different tools that it sits alongside. Are there any specific constraints that people should be aware of before they decide to dive into this? Things that are common for front end developers that they wouldn't be able to use with Redwood? The answer might be no, but.
00:35:31 - Anthony Campolo
When I think of constraints, I start thinking more about the back end, because it's set up with JWT and we don't really have any session management right now. Some more advanced developers are running into that. They're looking to build out more sophisticated apps and want something that's not just a way to pass around a token.
In terms of the front end, like I said, Redwood is very forward-facing in the sense that it's meant to enable front end developers. You shouldn't hit too many constraints in terms of the front end, except for these types of pre-rendering, static site generation things we've been talking about and are still ironing out over the next month or two.
So the main thing is that it's still not really good for generating tons and tons of pages. That's just not what it's optimized for at this point. That's why you shouldn't use it that way.
00:36:20 - Aimee Knight
Now I'm looking at the docs too. When you were mentioning deploying to AWS and if you want a cloud Postgres instance or something like that, what if someone wants to do a document-oriented database? Is that a constraint?
00:36:38 - Anthony Campolo
Yeah. This is something I've spent a lot of time working on and thinking about. The problem is that we are using Prisma to do all of our database stuff, and Prisma only works with relational databases at this point. That will most likely change in the future. It's just hard to say when.
But the thing is, you don't have to use Prisma. I don't know of any Ruby on Rails developers ever ripping out ActiveRecord or if that's even a thing you can do, but that is a thing you can do in Redwood.
00:37:09 - Aimee Knight
It is. I know this and I don't recommend it. It was a learning exercise.
00:37:14 - Anthony Campolo
That's so funny. It's exactly how I put it. You guys know FaunaDB. You've had Evan on the show. I did a project where I ripped out Prisma and used FaunaDB instead, and basically wrote a bunch of FQL queries inside my services. I wouldn't necessarily recommend it, but if you have enough perseverance, you can get Redwood to work with any kind of database you want. We will eventually have first-class Mongo support and things like that, but we're not quite there yet.
00:37:44 - Aimee Knight
Okay, I'm going to say then to Anthony: is there anything that you really want to talk about that we haven't gotten to?
00:37:52 - Anthony Campolo
This isn't the only framework doing this. To me, I really see Redwood as just one framework among many that are a movement toward figuring out how to create these kinds of applications.
Going back to what I already mentioned, Tom has an idea called the third age of JavaScript, which is that JavaScript is going through a transition into its third age. The first age was just the creation of the language. The second age was the last decade, basically all of Node and all the front end stuff we now think of as React, Vue, and Svelte. Now we're entering this third age of JavaScript. This is frequently talked about with things like ESM and tools like Vite and Snowpack.
To me, I really see these frameworks as a huge driver of this transition into the third age. Some people call them full stack JavaScript. Some call it full stack Jamstack. Some people call it full stack serverless. We don't really talk a whole bunch about the serverless aspect as well.
00:38:57 - Anthony Campolo
The idea is that single-page applications are amazing and they've gotten us really far, but they're really hard to work with and really hard to reason about. We can create conventions that'll let us continue to work with single-page applications in a way that makes more sense. It's about doing all of this more coherently.
Blitz.js is another popular one in this area. Bison is one that not as many people know about but I think is really interesting and people should check out. I anticipate that we're going to see many, many more of these types of frameworks in view. I think people are going to take Nuxt and integrate it with some sort of ORM tool. I think we'll start seeing this in Svelte at a certain point.
It's not about this being the only way to make apps, or the one true way. It's just that for certain kinds of apps we want to make, this is a really, really nice way to do it and you should consider it.
00:40:00 - Steve Edwards
So are you familiar with Inertia JS at all?
00:40:03 - Anthony Campolo
Yes. Inertia JS is a huge inspiration to Blitz. When I talk about Blitz.js being another kind of version of Redwood, Blitz.js is much more monolithic. That's why I say it's a lot like Inertia, because Inertia calls itself the modern monolith. The idea is that we can have a monolithic development workflow and go back to this really nice Ruby on Rails convention-over-configuration idea.
I'm more interested in the approach Redwood is taking, because I think by decoupling the front end and the back end, but integrating them nicely with GraphQL, we can get that monolithic development experience without tightly coupling our front end and back end. The idea of things like Blitz and Inertia is that there is no API layer at all. They call it the no API layer. You're just writing function calls that go directly into your back end, and there's no API whatsoever except when that is being auto-generated for you by a compiler or something.
00:41:06 - Anthony Campolo
Those are super interesting projects. I definitely recommend people check them out. I'm good friends with Brandon, the creator of Blitz. We talk a lot. So I definitely think people see some of these different projects as competitors, but we really see each other as collaborators.
00:41:22 - Steve Edwards
So it's more a level of coupling, shall we say, that separates the projects, in terms of how tightly coupled they are.
00:41:30 - Anthony Campolo
Yeah, exactly. The benefit here is that for something like Blitz, you can host your whole Blitz application really easily on Render. On Render you can deploy your whole Blitz application. You don't need to do this whole dance where you set up your Netlify front end and your Heroku Postgres back end and then manage those two dashboards.
That's why there's a lot of benefits to this much more monolithic experience. That's what we're aiming for with Redwood, but without sacrificing the decoupled nature of the front end and back end. We're still trying to get to this single, one-dashboard deployment paradigm, and I'm pretty sure we're going to get there. But if you're looking for more of that old school monolithic development experience, that's where stuff like Blitz and Inertia is really cool.
00:42:13 - Steve Edwards
It cracks me up talking about subjects like this. Having started out back in the early 2000s in the Drupal world, where everything was a monolith, Drupal, WordPress, any type of CMS like that. Then you have the pendulum swing where, okay, here we're at one extreme where everything is a vertical stack, all or nothing. Then we swing the other way. Initially it starts the MEAN stack, and now it's MEAN asterisk, and plug in your own front end.
We're at the other extreme where now you can mix and match all your front ends and back ends. You can do Laravel on your back end with Vue or React or Angular on the front end. Then you have guys like Christopher and Andy who are no JavaScript at all, or minimal JavaScript or vanilla JavaScript. Now it's like we're swinging back toward the monolith side, but with conditions. It's a monolith but with flexibility in terms of how you do your front end and back end. So it's just interesting to watch that pendulum swing back and forth.
00:43:16 - Dan Shappir
That and the fact that at the end of the day, we just keep on building CRUD applications, right? The techniques change, but the basic needs more or less remain the same. The web was created as a document-viewing platform, and we've transformed it into an application platform. We're still paying some of the prices.
Anyway, I'm getting all philosophical here. Is there anything else you still want to mention that we haven't mentioned so far, Anthony?
00:43:53 - Anthony Campolo
Very community-driven. We really love getting people involved, having contributors helping out, people who are building projects with this. If you go to Redwood Community, you can find links to our Discord or our forums. So for anyone who thinks this stuff is interesting or who wants to check it out and jump in, check those out. I think it would be really cool to get as many people involved in the community as possible.
00:44:20 - Dan Shappir
Excellent.
00:44:21 - Charles Max Wood ad read
Hey folks, I don't know if you've noticed, but I've been working a lot on figuring out how to help people become the most valuable developers on their teams, or becoming the top 5% of developers in the field. If you're looking to level up, figure out how to contribute more, get the career you want, get the career that you want that will support the lifestyle you want, then you should check out the Most Valuable Dev Summit.
I've invited some of my friends across the community, people that you've heard of, people that have worked on systems that you use on a daily basis, people who have invented new ways of doing things over the years in programming. I've asked them one question: how do you become a top five developer? How do you become 1 in 20 of the best developers out there? We're going to have that conversation with them in interviews on the Most Valuable Dev Summit. You can find that at summit dot most valuable dev.
00:45:16 - Dan Shappir
Since we've apparently lost both Aimee, although she has provided us her picks in advance, and we've lost AJ because we understand we had some sort of a production issue, it's just me and Steve left with you. Steve, do you want to start with picks or should I?
00:45:38 - Steve Edwards
No, go ahead. I'm going to fall back into my picks of classic movies that I keep seeing on Turner Classic Movies on TV. My choice for this time goes back to, I think, 1953. It's Jimmy Stewart and Doris Day in The Man Who Knew Too Much.
It's about Jimmy Stewart vacationing in Morocco and running into a guy who turns out to be an FBI agent about an assassination plot. His kid gets kidnapped and taken to London to keep him quiet about the plot and everything that happens after that. So yeah, 1956, and I must say, Doris Day is definitely not unpleasant to look at. She is a very beautiful woman.
Interesting side note: there was a spoof made probably 15 or 20 years ago with Bill Murray called The Man Who Knew Too Little. The whole gist of that one is along the same lines, except he's playing a game and doesn't realize that he's fallen into some sort of spy story or something like that. 1997 was when that was made, so I haven't seen that one yet, but I've read all about it.
So anyway, classic movie, The Man Who Knew Too Much.
00:46:56 - Dan Shappir
Excellent. So now I'll go with my own pick. My pick is a pick that, on the one hand, is really interesting and deserves to be picked. On the other hand, I'm slightly ambivalent about it, and it's the State of JS survey results for 2020, which recently came out.
On the one hand, it's really useful to know where the market is at, what technologies are being used, and what your colleagues and other people in your field are thinking about and using. It is a strong indicator of things you need to know in order to be attractive in the workplace, if nothing else. But on the other hand, I always think that they can use whatever tools they want and I'll use the tools that work for me. So it's interesting, but I take it with a pinch of salt.
What I found especially interesting is that in the section on technologies, there is something like a big four or four-and-a-half or five technologies that kind of dwarf all the rest, which are Webpack, React, TypeScript, Express, which is still interesting that it's still way up there, and also Jest for testing.
00:48:17 - Dan Shappir
These are at the top right-hand quadrant, far above everybody else. All the others are either on the left side, technologies like Angular and Gulp, or on the right side but lower down, technologies like Vue, Rollup, or at the bottom of the left side, the technologies that are apparently dying out like Ember and ClojureScript and Meteor. I know people are trying to revive it, but apparently not so much traction yet. So it's interesting in that regard.
Also interesting is that they have a rating of podcasts, and we are at number six at the top. On the one hand, that's really cool, but on the other hand, it means we have something to aspire to. So if you're a faithful listener, please tell your friends about us and make sure they listen as well. Hopefully they'll enjoy it, and next year we'll be higher up.
00:49:17 - Dan Shappir
So that would be my pick for today. Anthony, what about you? What are your picks or pick or whatever?
00:49:24 - Anthony Campolo
Hook into what you said. I'm not at all surprised to see Express on the list, because when I learned Node in my bootcamp, and when you learn Node in any tutorial, they all start you off with Express pretty much off the bat. No one is really taught how to use Node HTTP. You are just given Express from the very start. So that's why a lot of people don't even know how to write Node without writing Express. That's why Express is not going away for a long time.
00:49:50 - Dan Shappir
I'm not surprised at all that it's at the top in terms of have used. What is interesting is that so many people still have such a positive view about Express, way more than many other technologies like React Native or Puppeteer or even Vue.js. That's the part I find interesting: not only is Express so commonly used, it's still so well loved.
00:50:25 - Anthony Campolo
I think it's just because of the simple API. People like simple APIs. It's going back to why we like Redwood.
Thank you guys so much for having me. I've been listening to this show for so many years and have gotten so much value from it. Thank you for continuing to do what you do, for creating such a fantastic resource for JavaScript developers.
In terms of my picks, I will pick, I was talking earlier about how we have a lot of different frameworks in this kind of area, and I think of the full-stack Jamstack as the big bucket. I'm doing a podcast with a friend of mine, Christopher Burns, called FSJam, the Full Stack Jamstack podcast. If you go to FSJam.org or if you go to Twitter, you'll be able to find us. We're talking to a lot of people involved in Redwood, along with other frameworks like Blitz. You've had Brandon on a couple times, and we've had Chris Ball on for Bison. It's really fun.
We're getting more people on from companies like Fauna and Prisma and people on the Amplify team. I just think there's so much interesting stuff happening here, and that's kind of our hub for where a lot of that activity is happening.
Aside from that, just check me out on Dev.to. I blog a lot. My general handle is AJCWebdev, and that's also my Twitter handle or anything like that.
00:52:03 - Dan Shappir
Cool. I'm browsing the list of episodes on your podcast and it's definitely interesting, and I'll give it a listen. Thank you very much for that. I see you've got 12 episodes so far. We are at episode almost 500, so you definitely have something to aspire to.
00:52:22 - Anthony Campolo
We're going at two a week right now because we got so many guests. So we'll see. I might eventually start to outrun you guys. We'll see.
00:52:29 - Dan Shappir
Good luck anyway. You did give your contact information, so that's excellent. And I guess, AJ, I see you're back. Do you have any picks for us before we wrap up?
00:52:40 - AJ O'Neal
No, I don't.
00:52:41 - Anthony Campolo
Well, thanks for coming.
00:52:42 - AJ O'Neal
For the last five minutes.
00:52:43 - Anthony Campolo
Thanks for always being a contrarian voice. I really appreciate it. I was hoping I would get more pushback from you.
00:52:49 - AJ O'Neal
Yeah, I'm sorry. If it weren't for the issue with my client that they kind of need. Well, everything always feels urgent with them, but sometimes it is. You never know. That's a good way to manage people. Just tell people it's urgent and they get it done. So anyway, yeah. I'm sorry I couldn't participate more.
00:53:08 - Anthony Campolo
Yeah, it's all good.
00:53:09 - Dan Shappir
Okay, then with that, I guess I'll wrap up the show. So thank you, everybody, for listening, and bye-bye.
00:53:15 - Steve Edwards
Adios.
00:53:18 - Charles Max Wood ad read
Bandwidth for this segment is provided by CacheFly, the world's fastest CDN. Deliver your content fast with CacheFly. Visit cachefly.com to learn more.