RedwoodJS with Peter Pistorius

Episode Description

Peter Pistorius, core maintainer of RedwoodJS, discusses the framework's origins, its cell abstraction, GraphQL client flexibility, and the future of build tooling.

Episode Summary

This episode of the FSJam podcast features Peter Pistorius, a core maintainer of RedwoodJS, sharing his programming origin story and offering a deep technical look at the framework's architecture. Peter recounts how he stumbled into coding as a teenager in South Africa, bluffing his way into a job after fixing a game bug at a LAN party. The conversation traces Redwood's evolution from early prototypes called Spielplatz and Chainsaw through to its current form, revealing the collaborative naming debates and design decisions behind its features. A significant portion of the discussion centers on cells, Redwood's abstraction for handling data-fetching states, which Peter explains is simply a higher-order component enhanced by a Babel transformation that removes branching logic developers would otherwise write manually. The hosts and Peter then explore the decision to decouple GraphQL clients from Redwood's interface, motivated by the Apollo 2-to-3 migration challenge, and note that a community member has just contributed a React Query provider. The episode also covers the potential for swapping out build tools like Webpack and Babel in favor of faster alternatives like Esbuild and Snowpack, with Peter outlining a strategy of keeping Babel only for "magic" file transformations. The conversation wraps with candid thoughts on TypeScript adoption and excitement about reaching version 1.0.

Chapters

00:00:00 - Introduction and Peter's Background

The episode opens with a playful discussion of the Tower of Babel myth as a metaphor for language and empire before the hosts introduce Peter Pistorius, a core maintainer of RedwoodJS based in South Africa. Anthony describes Peter as the "Rosetta Stone" of Redwood, someone who has touched more of the codebase than anyone else, though Peter acknowledges that parts of the project have grown beyond any single person's knowledge.

Peter shares how he got into programming as a teenager trying to impress his friends by building websites, starting with FrontPage and Dreamweaver before learning PHP. A pivotal moment came at a LAN party where he fixed a scripting bug in the game Tribes 2, which led the computer college owner to offer him work. He began coding professionally at 17, staying up late to solve problems and sleeping through school the next day.

00:05:22 - The Origins of RedwoodJS

Peter recounts how Redwood began while he was working at Shutterbug, a company co-founded by Tom Preston-Werner. They developed productive patterns using React, GraphQL, and Storybook, and Tom initiated the idea of packaging those patterns into a framework. The first prototype was called Spielplatz (German for "playground"), which eventually fizzled out before being revived under the name Chainsaw, then Hammer Framework, and finally Redwood after discovering naming conflicts.

The discussion highlights the collaborative nature of Redwood's development, where naming conventions and feature designs often involve weeks of deliberation among contributors. The hosts reflect on how the community has grown significantly, with the changelog now reflecting contributions from dozens of developers rather than just Peter, and figures like David Price playing a key role in fostering that community growth.

00:11:10 - How Cells Work Under the Hood

Christopher asks Peter to explain the technical implementation of cells, one of Redwood's signature features. Peter reveals that cells are fundamentally just higher-order components—a well-established React pattern. The "magic" is limited to a Babel transformation that automatically wraps cell files (identified by their exports of success, loading, and query) into this higher-order component, eliminating the manual import step developers would otherwise handle themselves.

The conversation contrasts cells with the traditional approach of using Apollo hooks, where a single component file balloons in complexity due to branching logic for loading, error, and success states. Peter introduces his personal philosophy of "dummy-driven development," which aims to minimize code branches. The hosts acknowledge that while cells are conceptually appealing, some developers like Jason Lengstorf have found the abstraction disorienting, raising the tension between convention and transparency in framework design.

00:17:17 - Router Magic, Lazy Loading, and Developer Experience

Peter explains how Redwood's router automatically imports page files based on naming conventions, handling asynchronous loading and Suspense boundaries behind the scenes so developers write less boilerplate. He acknowledges that these conveniences come with trade-offs, particularly around TypeScript integration, where the framework must generate types to make auto-imported pages visible in route files.

Christopher notes that even in its pre-1.0 state, Redwood has consistently saved him development time. The discussion transitions into authentication, with Peter recalling how Christopher was the first community member to contribute a custom auth provider using Magic Links, proving the flexibility of Redwood's useAuth hook even when others doubted it could support diverse authentication systems. This leads into a broader conversation about how Redwood's opinions on things like deployment targets have evolved from Netlify-only to supporting Vercel and beyond.

00:20:24 - GraphQL Clients: Apollo, React Query, and Flexibility

Anthony steers the conversation toward Redwood's GraphQL client strategy, asking why Apollo was originally chosen and why alternatives are being explored. Peter explains that Apollo 2 was the gold standard at the time, but the migration to Apollo 3 introduced breaking changes that highlighted the need to decouple the client from Redwood's developer-facing interface. This abstraction allows users to stay on whichever client version suits them without being forced to upgrade.

The hosts discuss bundle size and cache management as key evaluation criteria, and Christopher announces that a community developer named Marcelo Alves has just contributed a React Query plus GraphQL request provider for Redwood. Peter reflects on the fashionable nature of web development, where developers readily jump between technologies, but argues that overall the ecosystem has become dramatically better and more capable over time.

00:29:07 - Build Tools, Esbuild, and Swapping Out Webpack

Anthony asks whether Redwood could ever swap out foundational tools like Webpack and Babel in favor of newer alternatives like Esbuild, Snowpack, or Rome. Peter outlines a practical strategy: keep Babel as the "magic layer" for special file transformations like cells and routes, while routing standard JavaScript through Esbuild for performance gains. He notes that Redwood's architecture, with its discrete API and web sides, is well-suited to this kind of modularity.

The discussion touches on complications around Storybook's dependency on Webpack, though Peter and Christopher note that Storybook's architecture could accommodate alternative bundlers for user components. Christopher brings up Turborepo and Jared Palmer's work in the ecosystem, and the conversation briefly covers TSDX as a tool for packaging TypeScript libraries before transitioning into a broader discussion about TypeScript itself.

00:35:26 - TypeScript, Version 1.0, and Closing Thoughts

Peter shares his candid perspective on TypeScript, describing himself as someone who writes JavaScript annotated with types rather than a dedicated TypeScript developer. He distinguishes between "design time" benefits, where editor tooling aids productivity, and "compile time" correctness, which he finds more challenging. Christopher humorously contrasts developers who meticulously type everything with those who use "any" and ship to production faster.

The episode wraps with excitement about Redwood reaching version 1.0 in 2021 and expanding TypeScript support, with Peter noting that a PR enabling TypeScript route files was opened just the day before. The hosts close with a lighthearted exchange about whether anyone has seen a real redwood tree, with Christopher pledging to visit one in Wales once lockdown ends. Peter thanks the hosts and humbly asks listeners to take his TypeScript opinions with a grain of salt.

Transcript

00:00:00 - Anthony Campolo

And Chris, the Tower of Babel is a story from the Bible about a tower, about creating one language the whole world could speak. That's the idea, because there was what was called the confusion of tongues, an old Mesopotamian myth from about 2,000 years before the Bible. And it's this idea of whether the world would be perfect if we all spoke the same language.

00:00:20 - Peter Pistorius

These people spoke one tongue. Then they constructed a tower to reach the level of the gods. Then God was like, you know what? I don't like that you're doing this. So he waved his hand and then everyone spoke a different language. And that's why we all speak different languages, because we were trying to make ourselves gods or something like that.

00:00:38 - Anthony Campolo

It's a story about empire and how empires try to homogenize the world. Let's get to the conversation. Do you want to introduce him, Chris, or do you want me to? Yeah.

00:00:57 - Christopher Burns

Welcome back to the FSJam podcast. On this episode, we have Peter Pistorius, core maintainer of RedwoodJS and entrepreneur, who is also building a developer application. Let's get to it. How are you doing, Peter?

00:01:15 - Peter Pistorius

Thanks, Chris. Thanks for having me here. I'm doing pretty well. It's simmering hot here in South Africa. I am currently in an incredibly warm room without any windows open because it's very loud outside.

00:01:28 - Anthony Campolo

Yeah. Thanks for being here, Peter. We're really happy to have you. I've been thinking about getting you on before we even started this podcast. When I gave my first Redwood talk, I referred to you as the Rosetta Stone of Redwood because you have written far more of the code than anyone else. And Chris has made jokes about this, that when there's a serious problem in Redwood, he knows I need to poke Peter. And anytime we get into a conversation on the podcast where no one knows what's going on, the conversation always ends with, well, I guess I'll have to ask Peter about this. So we're really happy to have you here.

00:02:00 - Peter Pistorius

Thanks. I like to joke that I love to touch every single file in RedwoodJS, but over time that's not true anymore. So there are parts of Redwood that I just don't know anymore. I guess that's going to continue being true as time passes.

00:02:18 - Anthony Campolo

Yeah, it's funny you say that. That's something I was curious about, actually. If there are any parts of the codebase that even you don't feel like you know anymore, because that means no one person has the whole codebase in their head anymore, is what that means.

00:02:29 - Peter Pistorius

Totally. Yeah, I think it's gotten to that point. There's an Ethereum authentication provider that's just been added, and I have very little interest in blockchain technology. So I glazed over it, and there are many more. I can't think of them off the top of my head, but they exist. And I think that's actually a really good sign of open source software, when there's not just one person that's responsible for the majority of the code. It's more like a group of people getting together and building something that they enjoy.

Yeah. And that's actually been, I think, the most enjoyable part about Redwood: the community more so than writing the code. Don't get me wrong, the code writing is super fun, and I never, ever thought I would build a framework. But getting to know everyone here and in the Redwood community is amazing.

00:03:16 - Christopher Burns

This is one of the questions I've brought up in the past on the podcast: where does a project live and die? Does it die with the person who no longer wants to maintain it? Do we get forks like Node, or does the same person always stick with the project? Does it die?

00:03:37 - Anthony Campolo

Yeah. [unclear].

00:03:39 - Christopher Burns

DHH with Ruby. Or is it more like an organization that manages it? Is it like Facebook or just a group of random people pulling together to keep something moving forward? As I've seen Redwood go on, the community is getting bigger, and the changelog is starting to get a lot of new names on it. It's not just, here's everything Peter's done in this update. It's now, here's everything 20 people have done to push it forward.

00:04:15 - Peter Pistorius

Totally. Yeah. And I think on the founding team, we have David Price, who's really pushed the community to where it is right now, and without his efforts, we wouldn't have half the people contributing. Anthony as well, Christopher, you as well, FSJam, and I feel like a whole community has sprouted up around Redwood. Not everyone is in these isolated groups, but we kind of know everyone. And when Anthony interviews someone, I'll be like, oh yeah, I know exactly who he's talking about. I'd love to hear their podcast and things like that. So I'm not answering your question, am I?

00:04:50 - Anthony Campolo

There you are. That's awesome. And this is exactly why I made the podcast and why Chris and I have made the podcast, because we really wanted to have a way for all of us to get more connected and to hear what we're all working on and know what ideas we're all thinking about so we can all learn from each other and grow together. I'm really happy to hear you say that, so that's really cool. Before we get too deep into all these topics, I would love to know, how did you learn to program and how long have you been programming for? Because I have to imagine it's a long time by now.

00:05:22 - Peter Pistorius

For those who are wondering, I'm 38 years old. I'm getting there in my days. So how I learned to program was back in the early days, I had a misguided idea. I thought I could impress my friends by writing code and showing that to them, and I thought that that was something that would give them joy. But they were more gamers, and they weren't really interested in websites.

And back in the day, I actually started out using FrontPage and eventually I moved to Dreamweaver. And then I read a PHP tutorial, and the whole idea was to try and build websites that I could show off to my friends just to impress them. So when I was 17, I had done a PHP tutorial, I think the week before, and I was playing games at a computer college. I'd actually gotten a Tribes 2 CD in the mail, which was amazing because no one ever sends anything to South Africa, and if they do, it probably wouldn't arrive through the post.

[00:06:19] But I got this Tribes 2 demo CD, and we were trying to play it at this LAN party at this computer college, and it had a bug. And I looked at the code and it looked somewhat similar to PHP, and there was a line with an error. It had a scripting language, and I modified that line. I read the code, modified it, and the game booted up and launched. And the guy who ran the computer college was really young. I think he was 24 or something, and he was like, whoa, man, can you code? And I was like, yeah, yeah, I can code. And I completely lied. He was like, cool, we might have some work for you.

And I was 17 at the time, so I was still finishing school, but I said, hey, can I do it? And my mom said, sure, that's fine, you can. I just started coding and going to school, so at night I'd stay up really late trying to figure out what the problems were.

[00:07:04] The next day I'd go to school and sleep, essentially. Yeah, that's how I got into programming. I like to say that I kind of fell into programming. I didn't really pick to be a programmer. I was just totally misguided in what I thought was cool. I realize now, in retrospect, that I've never been cool to my friends, but it didn't matter.

00:07:22 - Anthony Campolo

So I know a lot of people who dispute that.

00:07:25 - Christopher Burns

I was in what we call ICT in the UK, Information and Communication Technology lessons. I would go on to the school website, pull up an HTML editor, change all the staff names to bogus, and spread it around the class, trying to be the jokester. But, you know, I thought that was funny. But then as soon as someone else would reload the page or go on the website, they'd be like:

00:07:54 - short split/interjection

You didn't really change it.

00:07:55 - Christopher Burns

It's not.

00:07:55 - short split/interjection

There.

00:07:56 - Christopher Burns

You know it's not there. So it's not really a big deal.

00:07:59 - short split/interjection

You're not a real hacker and you're like, oh, I am.

00:08:03 - Christopher Burns

I am. I've been learning WordPress.

00:08:06 - short split/interjection

Yeah.

00:08:08 - Anthony Campolo

So we've already talked about the history of Redwood with both David and Tom. So we've gone over this a little bit, but I'd love to get it from your perspective. When do you feel like you and Tom first kind of started kicking these ideas around? And how did it turn into something real?

00:08:23 - Peter Pistorius

I was working for a company called Shutterbug that Tom co-founded, and I built the mobile app in React Native. We decided to start using React on the front end with GraphQL, and we kicked around some ideas, and we really liked the patterns that we had come up with. But coming up with those patterns took a ton of time and it was a ton of effort. Webpacker in early Rails was not a pleasure. After we had done that, I don't know how we got to the point where we were saying, hey, maybe we can turn this thing into a framework. It was really Tom who initiated that. And I was just like, yeah, I'd love to do that. That sounds like fun. And we created this thing called Spielplatz, which means the playground in German. We started putting together the basic pieces of what a framework would look like, and we had some key choices, like we wanted GraphQL, we wanted this client-server separation, we wanted Storybook, things like that.

[00:09:19] Like the things that we felt made us super productive in React. We wanted to have that in a complete framework. I guess that was maybe even two years ago. And then we kind of let it die. It just fizzled into nothing. I don't remember why, but then after a while, we picked it up again and we renamed it to Hammer Framework. Oh no, it was called Chainsaw.

00:09:38 - Anthony Campolo

Chainsaw.

00:09:39 - Peter Pistorius

I forgot about Chainsaw, and I remember at the time I was like:

00:09:42 - short split/interjection

Hey man, I kind of like trees. Chainsaws, super destructive. And he was like, okay.

00:09:49 - Peter Pistorius

And he was reading a book about Thor's hammer, how it's constructed. And he was like, this is the perfect metaphor. He decided to use that. He wrote up this big README in Tom's amazing README-driven development style. Yeah. And then we realized that there was a JavaScript package with about a million installs called Hammer.js. And then we realized that's not going to work either. So that was really the beginning of all of this quite a while ago, I think almost two years ago.

But really in the last year, there's been a significant effort in making it something completely usable. And I think what everyone sees now is the result of tons of discussions around what things should be called and how they should work. And I don't think everyone sees that whenever we come up with a feature, there's usually three or four weeks of us talking about what we should name this thing, how it should work, how the developer experience should work, and it's a super collaborative effort from all the developers' sides.

00:10:45 - Anthony Campolo

Yeah, this came up in a conversation about scenarios, which is kind of this new Redwood testing thing. Someone was like, why did you name this scenario instead of fixtures? And because the scenario is like a collection of fixtures, it's something like that. And so I was like, anytime we come up with a new name for something, we usually have a good reason or at least a reason.

00:11:02 - Peter Pistorius

Yeah. And then it's long forgotten and we're like, why did we call them scenarios or why did we call them cells?

00:11:07 - Anthony Campolo

Hence this podcast oral history.

00:11:10 - Christopher Burns

So one of the biggest parts of Redwood is Prisma 2. We've spoken about Prisma 2 so much, so we don't need to talk about that. Another part is all of the abstractions that allow the amazing developer experience to happen. What I understand about the cells is probably a lot less than what Peter understands. The cells, if you didn't know, are compiled through Babel, with a lot of magic being removed by the end user. How complicated was it to build the prototype for the cell?

00:11:53 - Peter Pistorius

I think it would surprise you to know that it wasn't complicated at all. A cell is a higher-order component. It's an old school higher-order component. And basically that means it's a component that wraps another component. You know what? I need to double check that. So if that's not true.

00:12:14 - Christopher Burns

What is it now?

00:12:15 - Peter Pistorius

It's still a higher-order component. So what would happen originally was you would create this cell file, you'd export success, loading, the query, all those things. And then you would actually, in the file where you wanted to load the cell file, you'd say import * as cell from Cell. And then you would have an object that contains loading, success, query. You'd pass that object into this higher-order component, and the higher-order component would have props. So the props would be query, loading, success.

So that step where you're importing * as cell from Cell, we take away. The moment we see a file name called cell that has a success and a query export on it, we make Babel do that for you. So we make Babel wrap it in this higher-order component for you. That is the magic that is happening.

00:13:10 - Christopher Burns

If you've never tried Redwood before, the easiest way to understand what cells are doing is when you look at frameworks like Apollo Query and Apollo Hooks. I think it's hooks now. Apollo Hooks got merged into Apollo Client and something like that. Your normal React component would have a hook at the top that would have a loading state, an error state, a data state, and a few other variables that then you would call later on in your component. So you would end up with this one functional component being really big and complex because it would have an error state in there. So it would need to show some JSX for error, JSX for loading, JSX for before it's loaded, and then the results. And that was one massive file component. Yeah, you can still use that today.

00:14:12 - Peter Pistorius

And not only that, but you had all that branching logic in there. So you were like, if loading, show loading; if error, do error. And I don't know if anyone remembers this, but I often joke that I have a development methodology called dummy-driven development. And one of the things that I try to fight against is branches in my code. And I know people are like, how do you do that? That's crazy. But cells are something that takes that away. You don't have to branch anymore. So the moment you remove a branch, you remove a path that you need to test and a path that you need to change or parse in your mind. You don't have to think about it anymore.

00:14:52 - Anthony Campolo

Yeah. Anytime I explain cells to people, they get it immediately. Anyone who has worked with any of this stuff, they've had to do all this conditional logic and deal with all these different ways to figure out what to do with your error and what to do with your success. So some of those things that when I explain to people, they instantly are like, oh yeah, that sounds like a great convention that I would love to have. But then when I showed it to Jason with Learn with Jason and we were coding it out, he was like, oh, I don't know what to do with this. Like, I don't know how to debug this. There's too much magic here. He got all freaked out by it.

So I think it's interesting that it's conceptually something that we definitely all want, but developers are still wary of having that done for them.

00:15:29 - Peter Pistorius

Yeah, I think if you consider it on the other end, if you're using a hook, for instance, how do you debug that? Like if there were something internal to the hook that you weren't sure of, how would you even begin to do that? A cell is something that you could consider on the same kind of level. It's something that you can trust is going to work. And if you needed to debug it, then there's something really wrong with the way that we've written it, not necessarily how you're using it.

00:15:54 - Anthony Campolo

Test your code. Don't test the framework.

00:15:57 - Peter Pistorius

Yeah.

00:15:57 - Christopher Burns

And what happens if it goes wrong? Well, it should spit something out in the error part if something is wrong. If it's not, it should go somewhere else.

00:16:10 - Peter Pistorius

Yeah, totally. And I think there are valid arguments against magic. But I tried earlier to explain the implementation of it and maybe I wasn't very clear, but it is really just React under the hood. The only magic is that we automatically wrap this import of a cell into another component. We pass the props to another component.

00:16:32 - Christopher Burns

How I imagine it sometimes in my head is when you want cleaner imports of files, you tend to have two files, your foobar component, and then an index.ts file that imports the foobar file as the default export. And you have to think that's a wrapper to make it cleaner. Well, if you think of it just like Redwood, that's also a wrapper making it easier. So you have to worry about fewer of the abstractions. It's interesting that I bring up files and file routing because that's something else Redwood really does help with, as well as importing files.

00:17:17 - Peter Pistorius

Yeah. So in our router we automatically import all files in a folder called pages that end in page. And the idea behind that is that if you're trying to map a string for your route against a component that should display that route, we can just remove that boilerplate for you and automatically handle that in a nice way. So we also asynchronously import those so you don't have to wrap those in an import and a Suspense block and all that other stuff.

00:17:48 - Christopher Burns

We're lazy loaded by default.

00:17:51 - Peter Pistorius

Yeah, totally. So we're trying to make your development experience more optimized and so that you have to read less code. And I know we have to deal with the consequences of those choices all the time when we're building the framework. So like when we're trying to integrate TypeScript, we have to generate types in order to make those pages available in that route file. There are definite arguments against it. And whenever you shy away from the norm, there's a little bit of a tide that you're going to have to swim against. But hopefully Redwood is doing all the heavy lifting there. Or at least, to go along with the metaphor, there's a boat that you can hold on to.

00:18:27 - Christopher Burns

In all my time of working with Redwood, it's always been, to me, it's not fully ready yet, but it's already saving me time. So no matter what, it saved me way more time doing this for me than me doing it myself later. I can't remember the number quite off the top of my head right now, but I was on 0.17, I think, of Redwood.

00:18:53 - Anthony Campolo

That's when I started, 0.11.

00:18:54 - Christopher Burns

It was the one where Magic Links got involved, that kind of thing.

00:18:59 - Peter Pistorius

Yep. I think Burnzie was the first person to contribute a custom-made authentication provider, which was amazing because when we built out that useAuth hook, we weren't even sure whether it was possible because a lot of people were like, that's crazy. You can't integrate thousands of different providers using a single interface.

00:19:20 - Anthony Campolo

You're telling me I can't integrate a JWT token?

00:19:23 - Peter Pistorius

I was like, let me just try.

00:19:25 - Christopher Burns

This is the thing. Magic doesn't even use JWT tokens.

00:19:29 - Anthony Campolo

How do you pass around the auth?

00:19:30 - Christopher Burns

Then it's like some different kind of token.

00:19:33 - Anthony Campolo

Okay, so it's a token.

00:19:36 - Christopher Burns

It's just not a JWT token, I understand.

00:19:38 - Anthony Campolo

Or it could be.

00:19:39 - Christopher Burns

I don't know, but it decrypts itself. But the big point here was that Redwood started as opinionated in every way. And as it's gone on, its opinions have changed on things like deployment. When Redwood first came out, it was Netlify-only. Now it's Vercel.

00:20:01 - Anthony Campolo

It was never intended to be Netlify-only. That was just the first one, right?

00:20:05 - Peter Pistorius

Yeah, that's totally correct. Although Christopher is also correct, our opinions have changed and they will continue to change. None of us want to die on a hill anywhere. We're just going to.

00:20:16 - Anthony Campolo

Strong opinions. Loosely held.

00:20:18 - Peter Pistorius

Yeah, we're just going to keep going where we think it makes sense, where people are going to enjoy building software.

00:20:24 - Anthony Campolo

This is a good segue into what I want to get into in terms of opinionatedness and opinions. There has been a lot of discussion recently around swapping out different clients for Redwood, so possibly taking out Apollo Client for a different client. And this is something that I really, really wanted to talk to you about because you were tweeting about this months ago. You were talking about looking at different clients instead of Apollo. And I remember tweeting back at you like, could you take some notes as you're doing this evaluation? Because I have no idea what the difference between GraphQL clients are. And I would love to hear how you're evaluating these, what types of trade-offs you're looking at, what one thing is good at versus another. Like so many questions here. So why did you pick Apollo Client and why are you looking at other clients?

00:21:07 - Peter Pistorius

Originally we picked Apollo Client, Apollo version two, because I think at the time that was sort of the gold standard of what people were expecting a GraphQL client library to do. It was easy to use. Most people understood it. It just ticked all the boxes. There was only one box that just wasn't great, and that was the fact that it has a very large bundle size.

In the meantime, we stuck with Apollo 2. Eventually Apollo 3 came out and they bumped the version number, which meant that they introduced some breaking changes. So as a framework and having several people actually using Apollo 2 in production, we wanted to upgrade to Apollo 3, but we had this issue. How do we get you to upgrade and then also introduce these breaking changes? And then you have to change a whole bunch of your code. So I realized that we could decouple the actual client, the GraphQL client, from the interface that the user is using. So we did that for exactly the reason that I just spoke about, which is that you could, in theory, still be on Apollo 2 but use a much later version of Redwood, except that you decided to stick with Apollo 2 because that was the best decision for you.

[00:22:18] You didn't need Apollo 3. Or if you didn't need Apollo 3, you just decided to use something much, much simpler that doesn't have all the shiny bells and whistles. So the idea with decoupling the interface that the developer uses from the client library that's bundled with Redwood is so that you have maximum flexibility and that you don't have to abstract those imports for yourself. So I think one of the things that a lot of developers do, or should be doing whenever they use a third-party library, is you don't necessarily always import directly from the library. If possible, you create a separate abstraction of this library. You import those modules and use that in your codebase with a standard interface that you can adhere to.

00:23:05 - Anthony Campolo

Very Unix kind of mindset. Right? Like single responsibility principle kind of thing.

00:23:10 - Peter Pistorius

Yeah, I think because there's always the risk that the library is unmaintained or you want to upgrade it at some later point. It happens all the time, and if you have control of your own standard interface, you can kind of switch them out, see what works for you. You can mock them, all kinds of things. There's huge benefits there. So we wanted to do that for you, give you a single interface with the ability to switch it out whenever you want it, and then you don't have to modify much or all of your code in order to make that happen. Because if you're using a GraphQL client library to fetch data, that's pretty much going to touch every single part of your app. And having to switch that out at some point is really not going to be nice if you have a very large app. So that's why we did that.

And in terms of evaluating other clients, we're really looking at two things. We haven't actually made a decision. We're still sticking with Apollo.

[00:24:02] We're looking at the bundle size. That's super important. And we want to simplify the way that people update the cache when you've performed a mutation. Yeah, I'm somewhat naive to the complexities there. And I need to educate myself.

00:24:16 - Anthony Campolo

Yeah, we've talked to both Dom and Zwick about this exact topic because Zwick is really into data store, which is how he's managing the cache instead of Apollo's cache. So yeah, I agree, this is something I want to learn more about. And it's like I keep hearing people talk about as this huge pain point that is really confusing. And I'm just like, I've never gotten to the point of having caching issues. So I don't know exactly what's going on here. But yeah, this is something that I hear talked about just constantly.

00:24:43 - Peter Pistorius

Yeah. And I think most of the time you're just going to use the library and it's going to work for you and you're not going to fight updating the cache. You're just going to be like, that's how it works. I'm done and you accept it. But there are times when you just need a higher level of control, and it would be great if that control was much simpler, because otherwise it's like, let me write some GraphQL to update my cache. It just feels really strange. It's not something that I enjoy doing.

00:25:10 - Christopher Burns

Fresh off the press, 11 hours ago, a developer by the name of Marcelo Alves integrated a React Query plus GraphQL Request provider for Redwood, abstracting React Query to be used instead of Apollo. This is fresh. None of us has looked at it yet, and it's something I wanted to give a go myself.

00:25:43 - Peter Pistorius

Oh, that's awesome. Yeah. So we made that possible, and then it happened.

00:25:48 - Anthony Campolo

I remember when you were first talking about this, when you were evaluating different clients. I can't remember exactly if there were specific ones you were looking at. But I remember you also tweeting about how you were very jealous of React Query, because React Query is just so nice, and you're like looking at React Query like, I want some of this React Query goodness for Redwood.

So it's really interesting to see kind of the long-term progression of these things, and I agree. I hear so many people talk about React Query and how amazing it is. And I've watched a lot of Tanner's talks. I think he seems like a really fantastic developer and like he's got a good head on his shoulders. So I'm really happy to see this, and I'm excited to see what types of stuff people start building out with that.

00:26:27 - Christopher Burns

I'm excited to give it a go. I'm going to plug that into my Redwood app as soon as this podcast is over. I'm plugging that in and seeing if it makes it any faster. And if it does, I will die on that hill as like, I don't need Apollo. This is good right now.

00:26:45 - Peter Pistorius

Yeah, I think web development and development actually is incredibly fashionable. We jump from one ship to another quite easily, and that's actually what I think a lot of people say, that they have never seen a bunch of web developers who run in one place and go nowhere, just switching from technology to technology. But I think overall, web development has become way better. It's so much easier to do things now, complicated things, than what we were doing back in the day. And certainly there are things that we are doing that are really not great. But I really love that we're so fashionable and we're jumping from Apollo GraphQL to React Query to big bundle sizes to single page apps to, you know, you can't stop us. We're just doing whatever is great.

00:27:35 - Christopher Burns

The big reason why is, this is nothing bad in the industry, but we all go on Twitter and there'll be a tweet that has a thousand likes that says, I've replaced my Webpack bundle with esbuild and it took it down by two minutes, and you think, hmm, I could go do that quickly. And then you do it and you go, you were right, it's down. But you've made a change in five minutes that has reduced your build time, and you've totally jumped ship on the bundler of Webpack.

And that's kind of happening now with React Query and Apollo. If it literally takes five minutes to jump overboard to get a better, more performance solution, why wouldn't you? Why would you stay? I thought when you said you've gone to South Africa for four months, you were becoming one of the old people that when it gets cold in Europe, you go, I'm just going to go live in a hot country for four months. Let Europe get really cold, and then I'll just come back in the summer.

00:28:40 - Peter Pistorius

You know, one of the things that I think about quite a lot is that if you are lucky, you're going to live to be like 80 years old. If you're lucky, you're going to have 80 summers in your entire life. That's not a lot of summers. So I try to maximize the amount of summers that I'm going to get in my lifetime. I am going to be one of those old people who's going to move like a sparrow.

00:29:07 - Anthony Campolo

So we've talked a little bit about switching out the client and how to make that kind of more modular. I think this is one of the things I really enjoy about Redwood, is that it's getting you a really tightly integrated, almost monolithic development experience, like made up of kind of decoupled pieces. But something else that I know Chris and I are curious about is if there are ways to, as JavaScript continues to develop, possibly upgrade the tooling aspect. So would there be ever a way that Redwood could be architected in a way that maybe you could switch out Webpack or even Babel? Are these things so tightly integrated that you would have to completely rewrite Redwood to bring in something like Rome or Snowpack? Or do you think that those are things that could one day be incorporated into Redwood?

00:29:53 - Peter Pistorius

This is actually something that I've been thinking about a lot lately, because there's this new class of build tools all powered by Esbuild, and everyone really loves them. And of course, who wouldn't want faster boats? I've been playing around with some proof of concepts for switching out the Babel compiler for the parts that don't have magic to Esbuild, or completely switching out Webpack and just throwing in Snowpack.

The way that we've architected Redwood is that we have these two discrete sides, the API side, the web side, and we want to introduce more, such as mobile with React Native. But there's nothing stopping us from introducing an adjacent web-Snowpack side, or just taking Webpack out of there and then plugging Snowpack in there. There are some complexities around the integrations that we've performed for Storybook because Storybook uses Webpack. There's a boundary there, but why wouldn't someone build a Snowpack version of Storybook? I think that would be really great for the way that we intend to use Storybook. Like, for me, Storybook is a development environment where I can build components in isolation, and then I can build that and show it to my team.

[00:31:03] I don't use a lot of the plugins, and I don't use the testing stuff that they have integrated in there, so anything is possible.

00:31:09 - Christopher Burns

One of my favorite features of Snowpack is you can import a URL, like, mind-blowing.

00:31:17 - Peter Pistorius

It's really cool.

00:31:17 - Anthony Campolo

Yeah. What you said about Storybook and Webpack, I think that's really interesting. I think that's worth taking a second on, because this is what worries me about trying to switch out something like Webpack or something like Babel. Webpack and Babel are such huge dependencies, not on just Redwood. They're huge dependencies on all the pieces that make up Redwood. All these things are so tightly coupled that I just wonder where we start to hit these types of boundaries by switching some of these tools out. Because it's like you say, by taking out Webpack, we can get that to work with Redwood, but what if it breaks Storybook? Then what do you do?

00:31:51 - Peter Pistorius

I'll give a breakdown of how I look at these things. So the foundation of Redwood is Babel. It transpiles all our code, and what we try to do is whenever we introduce a piece of magic, we try to anchor it on a file name. So in other words, like a file called Blitz.js or [unclear] auto-import things there. So in Redwood we could keep Babel as the magic layer for things like cells, for things like routes, and for everything else where you're just writing standard JavaScript, we could switch in Esbuild.

That is my theory of how that would work. So we could say, all right, if it matches this file, and we could do it via Webpack too, because then you're getting the performance benefits. So if it matches this file, stick with Babel. If it doesn't match this file, go with Esbuild. And that's how we can try a whole bunch of different things. I think that will work.

00:32:43 - Christopher Burns

Maybe it's just a matter of time with things like Storybook. In their current repository, they are discussing multi-core support. What that means is Webpack 4 and Webpack 5. I think they upgraded to Webpack 5, and that cut off all the Webpack 4 users. So they're looking at being able to use both of them. Storybook uses Webpack 4 or Webpack 5. And if they got that core functionality working, to what I understand, then they could look at adding Snowpack as well.

00:33:18 - Peter Pistorius

Yeah, I think Storybook has a very interesting architecture in that they have two parts. They have this main part, which is the UI on the outside, and they have the other part, which is your UI that you want to render. So they have these two instances. I'm probably naming them incorrectly. So the one they could totally manage themselves, and the other one they could say, all right, that's your Webpack config. And that's actually what you do is you say use my Webpack config to build my own components and display them in your UI that you build with Webpack config. Yeah, I could totally see how they could do that.

00:33:51 - Christopher Burns

One of the questions that we're talking about with config is we're really seeing this third generation of tools, third age JavaScript as swyx calls it. We're seeing loads of things pop up like Rome and Snowpack. One of the ones I wanted to highlight, that I don't know if you know much about and it's still mysterious, is Turborepo. What do you think of that? Are you an insider or an outsider?

00:34:19 - Peter Pistorius

I am very much an outsider. I would love to see what it's about. I'm very excited to see all these fancy new build tools coming out.

00:34:27 - Anthony Campolo

Okay, so this is Jared Palmer. So Jared Palmer, for anyone who doesn't know, was the creator of Razzle and Formik. And he's done a lot of work in the React ecosystem.

00:34:37 - Christopher Burns

My favorite package he's done is a tool for building other things. So say if you want to release a React component to be installed by someone else, and you want to write it in TypeScript, that basically gives you a template that you can build your component in and then it will be exported. Easy for uploading to the internet.

00:35:04 - Peter Pistorius

Okay, cool. Is it like a package template?

00:35:07 - Christopher Burns

Yeah. It's TSDX, a zero-config CLI for TypeScript package development. You want TypeScript plus your repo code to be packaged up and stuck on npm. TSDX is probably the best place to go for TypeScript.

00:35:26 - Peter Pistorius

Nice. It's like Create React App for packages, for packaging and publishing.

00:35:31 - Anthony Campolo

Yeah. Can we talk about TypeScript? I've heard that you got very into TypeScript this year, this last year. Peter, is that true? And why did you jump ship?

00:35:38 - Peter Pistorius

I didn't jump ship. Let me put it this way. I'm a firm believer in always bet on JavaScript. And I think as soon as JavaScript adds native types, which they might, may or may not do, I think many people will jump the TypeScript ship, but maybe we're too far. That just can't happen. I don't know, hot take.

00:35:59 - Anthony Campolo

I say bet on the specs. I always say bet on ECMAScript. ECMAScript is what you should bet on.

00:36:05 - Peter Pistorius

Yeah. So the way that I think about TypeScript, and I think I just co-opted this opinion from a whole bunch of other people, is that I write JavaScript and I annotate it with types, which happens to be TypeScript. And that often puts me in a scenario where I will solve an issue in JavaScript and it works. And then I need to add some kind of level of generics, or I need to add TypeScript fanciness to it, and I just can't make it happen. I'm actually not the best TypeScript developer. I'm actually pretty bad at it, to be honest. It's not my favorite thing. I love the DX that it gives you. No doubt there, but I don't enjoy writing TypeScript.

00:36:43 - Christopher Burns

It's very much like an ocean. I think TypeScript is. It's like you can go so far deep, but then you realize you're still in the shallow waters of the ocean. It can go so deep and you can spend so much time working on it. And then you look over and your mate has just put any on everything, and his code is already in production. And your code that's typed perfect is still waiting to get past the tests.

00:37:16 - Anthony Campolo

It's almost like the types don't actually matter or something.

00:37:19 - Peter Pistorius

I mean, yeah, there are these two.

00:37:22 - Christopher Burns

You have to find a middle ground.

00:37:23 - Peter Pistorius

There's these two concepts, right? I think they have what they call design time, where you want to have your Visual Studio Code helping you out when you're trying to do refactoring or so that you don't have to reference the documentation all the time. And then there's compile time, where you want to have the correctness of your types throughout your entire project so that you're confident that you have typed everything correctly and then things are working. I struggle with compile time correctness. I really enjoy design time correctness or design time checking. That's where I'm at.

00:38:00 - Anthony Campolo

Awesome. Well, we are getting close to the end of our time here, so I'd just love to know we're at the beginning of 2021 here. What are you excited for Redwood in 2021?

00:38:10 - Peter Pistorius

I'm really excited to hit version 1.0. I'm excited to actually get TypeScript support into Redwood.

00:38:17 - Christopher Burns

I can't wait for more TypeScript. My only question with Redwood fully supporting TypeScript is, will I be able to convert my Routes.js file to Routes.ts?

00:38:31 - Peter Pistorius

So that PR was actually opened yesterday. Yeah, yesterday was Sunday. There's a PR that fixes that for you now. So you can do that. I think in the next version.

00:38:41 - Christopher Burns

TypeScript is such a big thing that I feel we'll spend years working on it for someone else to just be like, hey, look over there. They're using no types and it's great. And you and everyone would be like, why are we using types again?

00:38:56 - Peter Pistorius

Yeah, I think you hit the nail on the head that there is so much work involved in creating an open source framework that supports TypeScript in the way that we want it to be supported across these sides that we've built and things like that, that it's actually a huge amount of work. And some of the early decisions that we made in Redwood are making it super difficult. So we're trying to work around those. So if anyone is a TypeScript expert and has created TypeScript packages that they share with other people on the internet, I'd really love your insights and some of your help.

00:39:31 - Anthony Campolo

Yeah, it's a great place for contributions for sure.

00:39:33 - Christopher Burns

The final question is, Peter, have you ever seen a redwood tree in real life?

00:39:40 - Peter Pistorius

I have actually. I was in California and I think I went to the place where you go and see them. I can't remember what it was called.

00:39:50 - Anthony Campolo

It's like the Santa Cruz Mountains kind of area is usually where you would go, like Sempervirens or Big Basin, that kind of area.

00:39:57 - Peter Pistorius

They're beautiful, I think. There's actually a place somewhere in England where they have one as well. It's not very big.

00:40:03 - Anthony Campolo

Somewhere in China too. Yeah. There are a couple places elsewhere in the world as well.

00:40:07 - Peter Pistorius

They're just like some random person was like, we shall plant one here, and that's where they are.

00:40:12 - Christopher Burns

If there is a redwood tree in the UK, I will make it my mission when lockdown is over to get a picture with it. Wales. It's not even in England, it's in Wales.

00:40:25 - Peter Pistorius

It's in Britain. Britain?

00:40:26 - Christopher Burns

No, Britain. Britain is the squiggly part, Wales is the lefty part and Scotland is the top part.

00:40:34 - Peter Pistorius

Is it in Britannia? No, I'm just kidding. I'm sorry.

00:40:36 - Christopher Burns

I don't even.

00:40:37 - Peter Pistorius

You know what, I'm being—

00:40:37 - Christopher Burns

Annoying.

00:40:39 - Peter Pistorius

So it's in the UK.

00:40:40 - Anthony Campolo

Well, thank you so much for being here, Peter. I can say quite definitively that Redwood would not be what it is without you. Thank you so much for your contributions, for helping build this awesome thing that so many people love and have enjoyed using. And thanks for being on the podcast. I look forward to getting you back and asking you the other 9990 questions I had.

00:41:01 - Peter Pistorius

Yeah, thank you for having me. It was super fun, and I hope my TypeScript opinions are taken with a grain of salt because they are ill-informed and from a person who hasn't spent much time in the TypeScript world.

[00:41:14] - Anthony Campolo