Ben: Hello, and welcome to PodRocket. Today we're here with an extremely exciting guest, Tom Preston Werner. Tom has created a lot of the most well known developer tools that you probably all have heard of including being a creator of RedwoodJS, co-founding GitHub, inventor of Semantic Versioning, and also creator of the static site generator Jekyll, So quite a resume of accomplishments there. Welcome Tom. Tom Preston Werner: Thanks. Thanks for having me. Ben: And so today I think the main topic we're all excited to dive into is Redwood. We had David Price and Amanda Jane Elliot on the show previously to talk about Redwood, and that may have been six months a year ago. It's been a bit so really excited to hear about some of the recent developments with Redwood. Ben: So maybe you could give us first, a quick overview in case folks missed those previous episodes of what is Redwood? Tom Preston Werner: Yeah, Redwood, we call it the web app framework for startups. So we're really trying to design this as a full stack, open source web app framework, JavaScript type script for people that are building startups or at least an ambitious project. So, the reason that we talk about startups is to get in people's minds that Redwood really is designed for the long haul. It's about maintainability. It's about creating multiple clients that can all talk to a common GraphQL backend and all of the things that go along with a large project or something that's going to move fast and need to scale quickly. All of that is wrapped up into what Redwood is and what it tries to make it easy for you to do from a web application framework. Ben: Got it. And as I remember, Redwood, it's kind of a collection of like best of breed technologies for each part of the client and network and middleware stack. So as of today, what are those technological underpinnings of Redwood and maybe you could talk through kind of why each one is the choice you made. Tom Preston Werner: Yeah. It's based on React, so you're going to be creating a React based web application, and that is going to be talking then via GraphQL to the backend. The backend is all written in JavaScript or type script. And using Prisma that backend will then talk to your database using any of the databases that are supported by Prisma. And so that's sort of the basic collection of technologies. Tom Preston Werner: We also bring along Storybook and Jest that both work out of the box. So you can be able to prototype components on Storybook or create a design resource. And then with Jest, we've done some really tight integration with the framework so that you get really nice mocking of your backend. So when you're designing your components and you want to have a component that is doing data fetching, then we have a really easy way with Jest to be able to mock that out so that you're not actually doing any sort of call over the wire, but you're getting back the data that you would be getting back in GraphQL from these mocks that you've created. So things like that we integrate to really make this a beautiful experience. Tom Preston Werner: A lot of Redwood really is about the integration. So yes, we're mostly using pieces off the shelf and the hard work is in doing the integration. We've built some things like the router ourselves that we didn't like the way that other people were doing it and we wanted to go a little bit of a different route on that. But for the most part, these are the tools that are commonly in use by people already. A big reason that we wanted to do Redwood was to avoid wasting time. We figured if we could do a lot of this integration work up front, not everybody would have to do that and this is what I've seen so much of is everyone kind of rolling their own framework based on these bits and why are we all doing that over and over and over and over and over again. Ben: I'd recommend folks go back and listen to our previous episodes on Redwood to dig into kind of more of the architecture and things like that. But in terms of like the last year or so, what's new in Redwood, what's exciting? Let's talk about that. Tom Preston Werner: Yeah. So we shipped the 1.0 In April, a couple months ago, we just shipped the 2.0 a few days ago, which may shock you. But I'll have to say that our approach to versioning, and I wrote a blog post about this, about avoiding the tyranny of major versions and what they sort of coerce us into doing, which is to actually ship minor versions with breaking changes and that's something that we really don't want to do. We really want to use Semantic Versioning the way that it was intended, which is the way that I wrote it. So I figured that authoring the Semantic Versioning specification I should probably try to actually follow the rules as much as possible or people might look at me sideways. And so really we're trying to take this to the next level and saying, when we break things, you will know because we will ship a major version and we're not going to do that only once a year and tie it to a big marketing event and a whole new set of functionality. It's really going to be that if we break some interface, then you're going to know about it because we are incrementing the major version, it'll be in the release notes and you'll have more of a heads up than I think most people do. Tom Preston Werner: Another reason to do this is to not be saving features and bundling them all up into one giant shippable major version like you see in Ruby on Rails for instance, which I have a lot of experience with, GitHub was built with Ruby on Rails. And one of the really big downsides that we found is when you only have these major releases once every year or several years, the burden of upgrading to that release is significant, and it would take us months sometimes to do that upgrade for the GitHub code base and it was brutal. And sometimes it would fail and we would have to start over because underneath sort of your application is moving along with new features, meanwhile, someone's very lucky has been tasked with trying to upgrade the code base while the code base is changing. If it takes you weeks or months to do it can sometimes get out of hand and you have to start over with a different approach. Tom Preston Werner: This is something that I don't want to have happen with Redwood. I would rather ship breaking changes more frequently in smaller chunks so that you can do them piecemeal a little bit at a time and not have that like month long procedure once every year and a half or two years, that really gets you into trouble. So that's the Redwood versioning. I got a little bit off on that tangent. Tom Preston Werner: But really the things that are new in Redwood, there's not actually that much, that was new in Redwood from the 1.0, it was really just drawing the line in the sand and saying that everything that's in Redwood now is production ready. And so it's sort of what we designed as the comprehensive set of tools that you need to really build a startup. So, that's the main sort of cycle of building a web application framework includes pre rendering. Tom Preston Werner: Let me talk about some of the missing bits that will be coming though, which I think maybe is more interesting for people. And that is.... SSR is a piece that is not currently in the framework that we're working on right now. So replacing also webpack with Vite and bringing along everything that can bring. Vite's such an amazing tool and the SSR tooling that it makes possible is really powerful. So, that's one thing that I'm most excited about. That was the one thing that really didn't make the cut for 1.0, that I feel strongly needs to be in the framework to really be as comprehensive as people want it to be. Tom Preston Werner: We also have things like self-documenting GraphQL API, so the documents that you put into the SDL actually end up being producible as a documentation resource. Integrating biometric authentication with the DB off provider that we have. If you're running your own authentication and sewing things in your database, you can then leverage, for instance, the fingerprint scanner on a laptop or face recognition on Apple devices, et cetera. That's a piece that will be going in shortly. Things like code sharing across sides, so we have the website and we have the API side, being able to share code across those right now is kind of challenging. We'd like to make that much smoother. Tom Preston Werner: We'd love to actually provide a mobile side out of the box. This is something that we've been intending to do since day one, which is to have multiple sides and this is why the API is abstracted out in the way that it is. And when the reason that we use GraphQL is because we expect that most companies will have multiple clients to their backend. And we think that the best use of your time is to write your backend once, all of your application logic, business logic, in your backend once as a GraphQL API, and then be able to consume it from multiple different clients, probably a web client, but also probably a mobile application, maybe a desktop app, maybe a command line tool, maybe something else, who even knows. We have all kinds of different clients, smart home things. All of these different things are going to want to talk GraphQL. You write your backend in GraphQL you've solved that problem from day one. But we'd like to ship the ability to write your mobile client as easy as we make writing your web client and have that be a part of Redwood itself. So that's something that we're investigating at the moment. Tom Preston Werner: Things like dynamic pre-renderer, where right now you can only pre-render pages that have no route parameters, where there's no dynamic information in the route. But soon, let's say you have blog posts for instance and you have a bunch of them and you'd like to pre renderer all of them. With dynamic pre rendering, you'll be able to say, hey, I want to, pre-render all of these routes that are underneath a single route but you change the slug of the title or whatever. You'll be able to pre-render all of those out of the box and have those delivered statically. Tom Preston Werner: Things like dealing with React 18 Suspense and server components and exploring how those can be used as well as being able to create a rest API that you might want to ship along with your GraphQL API. If you need to do that, a lot of people are still using Rust and we'd like to make it a first class experience, make it really easy for people to do that. That's been a frequently requested feature. So these are some of the things that we're working on now, as far as what's coming over the next year or so. Ben: Got it. Yeah. All super exciting. Redwood, I know recently brought in some new funding, a million dollars of funding for Redwood. This is maybe a silly question but is Redwood a for profit company now or still an open source community project or what is kind of the long term state of like the organization of the folks maintaining and building Redwood? Tom Preston Werner: Bringing in funding is maybe not the correct way to put it. So I have been supporting some people to work full time on Redwood for a while now and so the million dollars I have pledged is essentially me saying, I'm going to continue doing that and do a little bit more of it. So I'm just, self-funding this at the moment, this is a project that I really wanted to see exist in the world and I wanted to put together a team and see if we could build something that was really special that people could use to build their startups more quickly with a set of web technologies that was already sort of commonly used. So from the beginning, it's really been about that and commercialization, monetization has been secondary to that because I wanted it to be pure in the way that I think something really only can be if you're not constrained by the economics of it at first. It's been a very interesting experiment. Tom Preston Werner: Now, I would love to monetize it in some way, because I'd like to expand the team and in that I'm funding the whole thing myself, I'd rather find a way for it to become more self sustainable so that I'm not having to do that over time with a growing team. So that'll be a project for this year as well is to start thinking about what are the right ways to do that are, really supportive of the community that we've built, supportive of all the open source contributors that we've had who have worked on the framework. Really do right by all of those people and create something that allows Redwood to be sustainable in the right kind of way, and not in kind of a predatory way that will sometimes happen with venture capital backed companies. Where they start to feel the crunch, they have to do something or they're not going to make another round of investing. Tom Preston Werner: I don't want to be thinking about those things right now. I don't know where Redwood will go in the future. We take venture funding for Redwood at some point, it's possible. I'd rather try to not do that because I like bootstrapping, I like the freedom that gives you, and really the focus on the customer that gives you. If you are supporting it with the payments that your customers are making then that's what you really have to focus the most on. So right now it's not a commercial venture, it's just an open source project that I happen to fund out of my own pocket. And that's how it will remain for now and we'll see where it goes in the future. Ben: Got it. And I guess if you were to think about long term, some of the business models of other tools in this space, I mean, I know one is hosting, could you offer a better hosting experience for Redwood apps than some of the more generic hosting platforms like Appify or AWS or Google or wherever people host? If you did your own hosting could you improve upon the experience if it's tailored to Redwood? Tom Preston Werner: I think the answer is absolutely, yes, we could. And there are definitely things about Redwood that are challenging to make work well on the various deployment platforms that we have. And you can deploy across six or seven different platforms now, whether they're serverless or server full or even we have a deployment we call Baremetal, where it's like if you want to co-locate servers somewhere and deploy that way, you can do it with Baremetal. We want to make that work really well but at the same time, it's challenging to try to keep the future set in a place where it can be the same across both server full and serverless. And so this year, I think you'll also start to see that breakdown a little bit where certain features are only going to work in one deployment arena in a server full environment. You can do things that are just not possible in a serverless environment, but in serverless you get certain advantages as well. So, really, it depends on what you're doing. Tom Preston Werner: But the architecture of Redwood makes it possible that right now you can switch from one to the other with almost no code changes at all. You can start serverless and the flexibility of that can be really nice, but maybe the performance isn't what you need. At that point you can say, well, maybe I want to deploy to Render or I want to deploy to my own AWS setup or whatever it happens to be. Then you can make that change very, very easily with almost no code changes. That's sort of happenstance of the architecture, that just fell out naturally from Redwood's architecture. And do we want to create our own host? Maybe. We've talked about it. We've actually experimented with it. I think we want to make sure that's something that we really want to do if that's what we're going to do, because it's a non-trivial thing to be hosting people's code. Tom Preston Werner: Another route could be that we help orchestrate people's deployments on AWS or something like that, where it's not hosting as such, it's more the logistics around it. We could also do things like what Tailwind does in offering kind of pre-made bits of code that help you do what you're doing. So maybe there's a SaaS starter pack that works on Redwood to say, here's basically everything that you need already written to build a SaaS application. All of the account management and selection of the CSS. Like maybe it uses Tailwind and it has all of these things that are built in so that you can just be like, oh, I don't have to build my like account management stuff. That's the worst. I hate building that stuff, done it a million times. Every time it seems like a waste because it's not differentiating. Like, why am I wasting my time doing that? Tom Preston Werner: So, we could sell starter packages, things like that, different kinds of memberships or educational things. There's a lot of different things that we could do. We really wanted to get the framework in a place where we were confident that it was going to be successful before we went down the route of spending a lot of time on that. So I think we're still in this sort of transitional point where we're deciding what a monetization might look like, but certainly hosting could be one of them. Ben: I'm curious how you think about the... I'm hesitating to say the word competition, but I guess it's kind of competition. Generally, a new startup is going to choose one technology stack and that's kind of what they stick with. So when you think about Next.js and they're probably the biggest, but then all the other competitors. Who is Redwood best for and why is it better for that set of customers or users? Tom Preston Werner: Well, I think our strong point is really a dedication to long term maintainability and anticipating how your application is going to need to grow and change in the future. Where things like Next are really amazing for prototyping, and of course you can build huge companies on Next but you end up building essentially your own framework at the end of the day. It doesn't come with much, it is a building block but at the end of the day, you're doing most of the integration work yourself. Tom Preston Werner: So if you want a set of competent tools out of the gate that are going to last you for the lifetime of your project of your startup, then that's where I think Redwood really shines. Because we've chosen a set of technologies that will work at any scale and especially GraphQL is part of that. So a lot of frameworks are trying to make the API layer disappear because it's easier for the developer, which is true in the beginning. That's true. If you don't have to worry about your API and you're essentially doing function calls and you're getting your data back directly and you're not worrying about any of that, then you can get your prototype out much more quickly. Tom Preston Werner: The problem is a year down the line when you want to create a new client, or you have to start teasing apart bits of your application to pull into different kinds of servers because some of them need to be optimized. Now you start having trouble because you don't have a standardized protocol to use to communicate between the different parts. So that's why we've chosen GraphQL and really worked very hard to make Redwood the best possible place that you can create a GraphQL server. I think that's one of the things I'm most proud of is how easy we've made it to build a GraphQL serve, you write your business logic as a set of services and you don't worry about the GraphQL part almost at all. All of that's taken care of for you. You write your SDL and you write the implementation in JavaScript, and that's pretty much it. And all of the rest of it's done for you. It gives you such a solid foundation in a multi-client world that everyone pretty much is in, that everyone needs to anticipate to be in. Tom Preston Werner: That to me, the number of times that I've created something in Rails and then later on realized that I need a GraphQL API for it, because I'm going to build a native mobile client or something, and now I've got two backend APIs. I've got sort of the Rails version of a back end, which, it's all server rendered so it's also the front end. I've got that and then I've got now a re-implementation of the parts of that I need in GraphQL and now every time I want to change something, I have to change it in two places. It's the worst. I hate it. I hate it so much. I want to live in a world where everything is just a GraphQL call. Tom Preston Werner: So that's really what Redwood is about is anticipating that future, really drawing the lines clearly between front ends and back ends so that as your company grows, and as people start to specialize, you have teams that can very easily work on each of those parts independently. Where in Rails, those things get mixed together. Like in the V files in Rails you've got both presentation and logic. If you're not extremely well disciplined, which basically nobody is, then you've got these files where you might have your front end people going in there and really having a tough time dealing with all of the logic that's in there, all the code logic that's in there. Tom Preston Werner: At the same time, you've got developers that need to go in there and they've got so much presentation layer in there that they're having a hard time teasing apart where to make the changes that they need to make. This is why I love React so much. React is such a beautiful separation of those things. You hand them a data structure and say, all right, like here's everything that you need. Here's your data, here's your props, and here's a little bit of context maybe that comes in and that's everything. And then you can take that and you can put it in Storybook and you can work on your components in total isolation from your actual application, which is another amazing, beautiful thing that I've been trying to make happen in web application development for probably 10 years. That idea that you can work on your visual layer in isolation without having to try to get your running application and database into a state where now the components are rendering or whatever the view is rendering in a certain state so that you can like work on it, I've done a lot of that in my life too and it's awful. You get into some deeply nested thing where the database has to be just so, and you're like, oh my God, this is going to take me forever. Tom Preston Werner: And then you have to try to figure out like, well, maybe I can extract it to some other place where I don't have to go through such a rigamarole, but like that's a whole other can of worms. So Storybook and React and what they are finally make that possible. And that to me is such a magnificent thing and then you add to it, the data fetching, how Redwood does data fetching via what we call cells, which are essentially a declarative way to do your data fetching. So you kind of declare what your GraphQL query's going to be and then you have separate components that a file exports for loading, failure, success, for the different states and those are also just React components. So you're not doing any of the logic to decide between what happens, the framework itself does that for you. So the cell is just saying what you want to have happen, the framework takes care of orchestrating it and making it happen. And because of that, you can work on your cells in Storybook as well because of the mocking that comes along with Redwood. Tom Preston Werner: So all of your application, you can put into Storybook and work on them in there in isolation. It's not going to give you a lot of extra velocity at first, again, Redwood is really optimizing for the long term. These things slow you down a little bit at first, if you do them. A lot of people aren't going to do their Storybook files initially because you're just like trying to get something, anything to work. But if you're building a startup and you want long term maintainability and long term velocity, these are the things that you do that really help. And Storybook is one of those things that is a magnificent way to keep yourself moving quickly over time. Emily: Hey, this is Emily. One of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right, back to the show. Ben: Changing gears a bit, I saw you recently launched the Redwood Startup Fund and sounds like this is a fund you're committing another million dollars to invest in startups in the Redwood community. So can you tell us a bit more about your goals there and why you decided to make that commitment and any progress so far with startups you funded? Tom Preston Werner: I do a lot of angel investing and I've been looking for ways to sort of combine the different things that I work on and care about. So in my life, maybe the three biggest things that I do with my day are I do Redwood, I work on Redwood, I do angel investing and I have a family foundation, we call Preston Werner Ventures. It's sort of the umbrella over everything, but we have a family foundation, my wife and I, where we do a lot of grant work around climate. So both from a political angle as well as direct funding to different organizations that are working directly in the climate space. Tom Preston Werner: So, these are kind of the three different things that I spend my time on. And I was thinking about how I could maybe combine those interests a little bit. And so the idea of the Redwood Startup Fund came to me, which is to say, what if I extend the funding that I do to also work for Redwood startups to encourage people to use Redwood, but to also be able to provide, in addition to all the different support that we provide, like let's go the extra mile and even provide funding for startups that are using Redwood and also reinforcing sort of the startup mentality and branding that we have for Redwood. Then give it a couple of reasons why we might prioritize funding. One of those reasons is climate. So if you're building a software climate tool or application of some sort with Redwood, then you'll automatically go to the top of the pile for consideration for funding. So that's kind of how I combine all three of those interests together. Tom Preston Werner: Now, another reason that we might prioritize applicants is for diversity. So we also have in the Redwood community, as in many of the communities around code and especially in open source, primarily white and male representation and I'd love to see that change. So I'd love to prioritize women founders, people of color that are in the space and want to work on a startup. If that looks like you, then I want to see applications from people of those sorts so that I can try to change the demographics of what I'm seeing in the Redwood community right now. Tom Preston Werner: So those are kind of the reasons that the fund exists and also I thought it would be fun and allowed me to diversify my portfolio a little bit and make sort of smaller investments. So the intention is to do 25 to 50K checks into startups, and maybe they haven't even incorporated. I would love to have people come in with just an idea and say, all right, I've been hacking on this thing with Redwood and here's my idea. I don't even have time to work on it right now, but if I had 50K I could really spend six months working on this and get it to somewhere that's interesting. And maybe that person doesn't have opportunities to do that through traditional venture capital and I want to be the person that can make that possible. Ben: I'm curious within climate specifically, what are some of the general themes you're seeing where software entrepreneurs can make an impact in the climate sector through software? Because I often talk to people and they say, oh I'm a software engineer. I want to help with climate change, but I don't know how to build solar panels or DAC or whatever it is. So like what can software people do and where are you seeing software engineers having success building startups that help the climate? Tom Preston Werner: This is an excellent question, one that I am myself researching now because the answers are not as immediately obvious as sort of the hardware plays tend to be. But there's a lot of startups that are doing analysis for energy companies for instance or for consumers that want to be able to track and change their own behavior or looking at their own solar installations or optimizing when they're electric vehicles charge. So there's one that is really cool called Optiwatt, Optiwatt. So if you have an electric car and you want to be able to charge it economically or at times of the day that make better sense for the grid, then you kind of want something smart to orchestrate that. And so what Optiwatt is, is a piece of software that you install on your phone and then you can essentially authorize it with your Tesla for instance. When you plug your car in now the Optiwatt is able to change the schedule for when that charging happens dynamically based on a lot of different things like the weather, the price, the energy is costing at that current time. And it can intelligently then reschedule when that charging might happen and give you some really great metrics of how that works over time. Tom Preston Werner: So a lot of it looks like control applications for the energy that you might be using or for energy plants themselves to try to do orchestration. Or I think as time goes on and more and more people have electric cars, there's a really cool opportunity to orchestrate those distributed battery storage potential across geographic locations and onto the grid where you have essentially a distributed giant battery across all of these vehicles. And if there are power outages or the grid needs some temporary storage, well, there's a lot of that available in a distributed vehicle centric set of batteries. These batteries are quite large right in these vehicles and what if we could leverage those better? And that's really a software challenge. Tom Preston Werner: There's many more. There's things that are strictly behavioral for people. How can we change people's behaviors of what they're doing in their lives? And even more than that, that's really not where I would focus. I would focus on businesses. How can we change businesses, behavior? Because that's really where the scale is going to happen. How can we get businesses using cleaner technologies? Understanding how they're using energy and how they can do better and still do it economically. How can we use software to change the big users of energy? Ben: So, one thing I'm curious about is, I mentioned in the beginning, you've worked on a bunch of quite successful developer focus projects from Jekyll to GitHub. So I'm curious, what are a couple of the key learnings that you took from those previous projects and companies that you're now applying to Redwood and things you'd recommend to folks building developer tools? Tom Preston Werner: I think the biggest thing always is developer experience. It's thinking about how the developer meets the tooling and how it makes them feel and how it changes their everyday work experience to reduce the everyday friction of programming, for instance, or the barriers to entry to begin with. And also how can you reduce feedback cycles? Like those three things are, to me, three of the most fundamental things to think about when you're building tooling that are going to make people's lives better. So GitHub was definitely that. We talked a lot about how do we reduce the everyday friction? How do we lower the barriers to entry? How can we make something that is fundamentally a challenging technology, Git, a complicated technology, how can we make it more approachable? How can we make it more usable? How can we make it easier for people to collaborate? Tom Preston Werner: At the end of the day it wasn't even about Git, it was about collaboration. That's where I think where the real magic of GitHub comes in is, Git of course, is amazing but the real value of GitHub is not that precisely. It's the bringing together of large groups of people to be able to collaborate on a common project. Like that's where the magic is. And for things like Jekyll, Jekyll was just a personal project that ended up being used for GitHub Pages and that kind of brought it the popularity that it has enjoyed. And again, I think it's about better ways to do things, better ways for developers to use their times, or to have better assurances for how they do things. Like really the reason I wrote Jekyll was I was tired of losing MySQL database that was WordPress on some random server somewhere, which I did several times, and thinking like, how ridiculous is it that I'm writing blog posts in a web application that's going to be stored in a database on a server somewhere, like they're just text files. What am I doing? This is craziness. Tom Preston Werner: There's so many layers of complexity that you're adding between the author and the publishing bit there. At the end of the day, we're just producing HTML, why is this so complicated? So how can you remove all of that? So I think reducing complexity is a big part of this as well. And really all of building things, programming, is about managing complexity at the end of the day. That is always the thing that bites you at the end. Of course, all of our things always become more complex and Redwood is the same, right? Redwood is becoming more complex. So like a lot of what I think about is like, how do we manage that over time and keep Redwood sort of concise in what it's doing so that it's easy to understand, but it's still solving a robust set of problems. Tom Preston Werner: This is always the challenge of a growing software project. You always want to add to it, which is always going to make it more complicated, and how do you manage that complexity? And this is where, like the long term maintainability, building it for scale from the very beginning, these are the things that I always think about because GitHub really taught me those lessons. That if you take shortcuts in the beginning, they're going to become very, very painful in the long run and you'll really regret having made those shortcuts in the beginning. You need to either start with a better foundation or realize that and change them as quickly as you can once you start to reach some of those bits of scale. So those I'd say are lessons from GitHub and Jekyll. Tom Preston Werner: Open source is another thing. Open source is why I am who I am. I would not be anything without the opportunities that open source has given me and the area that it's let me explore and the people that I've been able to meet through it. That has been the reason that I've been able to accomplish the things that I have. And so another learning there is to just get into open source, do whatever's necessary to carve out some time at work or at home if possible, and just build something and put it out there. Tom Preston Werner: It's amazing, people are always, I think, a bit fretful about what can I possibly contribute to the world of open source it's already so vast, there's already so many options. Yet the things that I've built are all just the Nth iteration of those things. Like Jekyll, how many ways have we had to publish content to the web before, right? Like Jekyll's just another one of those. Or TOML, which you didn't mention I'm offended. TOML, the configuration language, which is now used by quite a few projects is the Nth configuration file format. Yet people found something better and different in these things. And I think that's always there, but you'll never know if it's there if you don't at least try. Ben: I'm curious, like on the topic of dev experience, one of the things I've often seen or what is often a common debate when you're talking about building for developers is like trying to build something that's both caters to like a power user and I feel like the typical developer is like the ultra power user. But then on the other hand, we have more and more new developers who need something that's approachable and easy to use and get started with. How do you think about supporting that spectrum of users from first time developer to uber power user? When you're thinking about a new experience you build, how do you balance for those two personas? Tom Preston Werner: Documentation is a big one, I think. And we think about this a lot with Redwood, because Redwood is fairly complicated. You need to know a lot about a set of technologies that is going to take you a while to get to. Like knowing React and JavaScript and GraphQL and Prisma, all of these things are things that you have to learn. So a young developer, an early developer, may not know everything that they need to know to do that. And I think the solution for us there is to really become an educational tool that people can use to learn those things with Redwood, because those things are all easier to learn in the context of Redwood. Tom Preston Werner: Learning GraphQL in isolation kind of sucks because you're like, okay, I'm going to build a GraphQL server from scratch, I guess. Doing that is non-trivial. And it's like, I want to put SDL files in multiple different files and it's like, good luck, that's going to take you like a month to figure out how to just split up your SDL files into multiple files and have like Apollo server read them in and serve them. It's something that you would think would be really easy, that is not at all easy. Especially because JavaScript, doesn't natively have a thing that'll import a glob of files, which is honestly insane and ridiculous. So we've had to create and invent and like put those things into Redwood that are non-trivial to do. Tom Preston Werner: So what I'd love to do, something I'd love to work on with Redwood is like learn GraphQL with Redwood. I'd love to write something that is the guide that takes developers through that journey, so that if they like what Redwood represents, I want to build a startup, I'm a developer maybe I'm a early developer I've come out of a bootcamp, but I have an idea and I want to do this. How do we help those people get started with Redwood because it is a bit more complicated than just Next for instance. Because Next is this much smaller bit. It's this much smaller thing to have to understand all at once. And some of the conveniences that it offers really are incredible. I have nothing against Next. Next is an amazing tool. I think for a specific job, just like every tool is great for a specific job. But if the specific job you want to do is build a startup, then I think the challenge is on us to make Redwood approachable to do that. Tom Preston Werner: But at the same time, not every tool can be a tool that you can just pick up and then be productive with in 10 minutes. It's not a reasonable thing to expect out of the world. I don't want to make Redwood less useful for experienced developers if the trade off is that we have to do that in order for it to be better for early developers. I would love it to be both, but I'm not going to compromise on our main point, which is we let you build a startup more quickly. Our tools are going to be power tools, and you're going to have to do some learning in order to use them properly. Ben: Outside of Redwood and React and GraphQL, outside of kind of those technologies that you actively work on, what are you most excited about in terms of developer tools or developer companies? Tom Preston Werner: I'm really excited about some of the tools that help the developer setup experience. So Gitpod is a company that I've invested in before and is in a space where there's been so little innovation over the last couple of decades that it's really astonishing to me what Gitpod has made possible. And GitHub Codespaces is kind of in the same place. But to me, Gitpod is really pushing the frontier there. Tom Preston Werner: And that idea that you can work on any project in an instant without having to worry about what your setup on your laptop is currently. Like, I'm constantly fighting, or I used to constantly fight with my machine that was always in the wrong setup for doing some piece of development. So I'm like, oh, here's an open source project. I want to like work on and make a poll request to fix this certain thing and it's like, okay, I'll just clone it down locally and I'll like do the install. And then it's like, oh yeah, I'm sorry. You can't do that. You have the wrong version of like these seven different things that are system installed things or whatever. I'm like, oh, come on. This is ridiculous. There's so much pain in that. So much friction. Tom Preston Werner: Again, talking about everyday friction and barriers to entry where we're like, hey I'm sitting up here being like work on open source and then a person tries to do that and the first thing that they encounter is, oh, you can't run this because your developer environment is wrong. And they're like, okay, let me figure out why my version of icon V isn't compatible with this tool. Now you're down this rabbit hole for three hours trying to figure that out and then you give up. Tom Preston Werner: So things like Gitpod that make it so that you can just get started without worrying about any of that stuff. And so with Redwood, we use Gitpod really effectively to help people contribute to the framework itself, because you can go on there and you can say, all right, I'm going to open a poll request. I'm going to work on something and Gitpod makes it possible that you can have the framework and alongside it an example, Redwood application so that as you're working on the framework, you have a Redwood example and I think we use an example blog for this. Where the changes that you make to the framework are immediately seen in the example Redwood application itself, which is of course what you want. You're like, I'm going to change the framework and this is going to be reflected in my actual app that I'm building. Building that and doing it locally is so monumentally painful and we spent many months working on this. Tom Preston Werner: If you know Node and you've worked on packages in Node before, then you may know that trying to do this and get something to use, the framework that you're going to be working on locally is like a monumental nightmare. Because Node expects it to come from like NPM, from package management system, and you're like, no, I want it to come from this other place that's local on my disc. And it's like, I have no idea what you're trying to do. Like nobody's ever tried to do that in the history of the universe. Why would you want to do that? And you're like, I don't know, because everybody needs to do that, that's working on a package. Why is that so hard? I don't know. But with Gitpod, we've been able to make that easier. Tom Preston Werner: So, these are the kinds of ideas that to me are really revolutionary where it takes something that used to soak up hours and hours of time and are just like, oh yeah, you don't worry about that anymore. Do this and it's done. So, that's one that I'm really excited about. I think there's a bunch of databases out there that are becoming really interesting things like PlanetScale that are taking MySQL and making it just trivial to scale across the world. Tom Preston Werner: Or there's another database called EdgeDB that I've been looking at recently, that is like a totally different model. It's a much more object based model and a graph kind of a model for your data where it tries to match your data storage to the paradigms that we use in development. It's not relational in the way that you're like select star from whatever. You're like, that's not how I want the data in my code. My code doesn't think about data that way. I want a user and I want their set of blog posts to just be an array of this other thing automatically. Why am I having to select these things out and then like stitch them together with an ORM. EdgeDB is like, no, it is the way that you already want it in your code and it's just a graph and you can pull this and it just pulls stuff automatically and stitches them together for you. I think those things are really cool. Tom Preston Werner: So I do a lot of in investment in the database space and developer tools overall. It's really cool. There's a lot of really cool things. It can get a little overwhelming sometimes trying to figure out how we should build things, given all the opportunities that we have, but also it's an embarrassment of riches in that. We live in a great time to be in this industry and discovering how should we build things? Ben: Well, Tom, it's been great having you on the podcast and continuing to see the success that Redwood has had. We will put a link to the Redwood website in our episode description. Any other resources you'd recommend for folks who want to learn more or try out Redwood? Tom Preston Werner: I'd say go to the website is your main one. If you are interested in Redwood, the number one thing that you should do is do the tutorial. We've spent thousands of hours making the Redwood tutorial the best tutorial that you'll ever come across. It is amazing. There are videos that one of our guys Rob has done to go along with it. So you don't even have to do it. You could watch Rob do it on YouTube. So go watch the videos. It'll show you exactly the things that I'm talking about. It'll give you a really good sense of what Redwood is. Definitely do the tutorial. Ben: Great. Well, thanks again, Tom. Tom Preston Werner: Thank you. Speaker 4: Thanks for listening to PodRocket. You can find us at PodRocketpod on Twitter, and don't forget to subscribe, rate and review on Apple Podcasts. Thanks.