[0:00:00] P: Hi, Tom. Welcome to Software Engineering Daily.

[0:00:03] TPW: Thanks. Happy to be here.

[0:00:05] P: Great to have you. Let's dive right in and explain what is RedwoodJS?

[0:00:10] TPW: RedwoodJS is a full stack JavaScript and TypeScript framework for building web applications using modern technologies. It's a more opinionated, more complete web application framework. We try to build in everything that you need in order to really build the sophisticated SaaS application using React, GraphQL, Prisma, and everything that goes along with that; testing storybook. Try to include everything that you need to get started and to maintain it long-term.

[0:00:45] P: How did you get into programming and what were your first steps in the software industry? Where did it all started?

[0:00:52] TPW: I guess, I really first started programming when I was maybe 10-years-old. My dad had bought a TRS-80 computer. It had no real operating system. It would boot to basically, a prompt. Then you would write a program with BASIC. You had to tell it everything that you wanted it to do. I loved it. I loved writing programs in by hand, copying in programs from magazines that I would find. I just really loved the wins that you get from making the computer do something that you wanted to do and being successful and overcoming all of the inevitable bugs and missing syntax that you do when you're a kid.

I really love that feeling of success over and over. You get something working and then you have an idea and you can implement it and see that success right away. That's how I got started. Then, I actually thought I was going to be a physicist, theoretical physicist. Very into physics. Still read a lot of physics. But in college, it turned into just math, like pure math, very abstract pure math. I don't like math, maybe quite that much. I pivoted to computers, because I've always done that as a kid growing up in high school and everything. Thought that I wanted to be able to affect people's lives more directly.

If you're a physicist, you might make an important discovery once in your lifetime, or something. It might take you 20 years to get there as a theoretician. I thought it would be nice to impact people's lives more directly, more often. Computers, as I talked about, are a way to do that, to get to those wins right away. That pivoted me into computer science. Then I got hired as a startup. I dropped out of college to join a startup right during the dotcom boom in 2001. Then a string of random startups that did not very well brought me to San Francisco eventually, worked on GitHub, started GitHub there, and the rest is history.

[0:02:51] P: Before RedwoodJS, you have, as you just said, you have a co-founded GitHub. You've also created Gravatar. You have created TOML, which it’s an acronym for Tom's Obvious Minimal Language, correct me if I'm wrong.

[0:03:03] TPW: Indeed, it's correct.

[0:03:04] P: Also, Jekyll and a language learning platform called Chatterbug. I was wondering, what motivates you to start a new project? Do you follow any specific process that helps you to decide what are you going to work on next?

[0:03:18] TPW: I think for me, I love creating things. I always have some project that I'm working on. In the early days, I was doing some consulting. This was after I got laid off from one of those random startups that wasn't doing very well. I was doing consulting and just laying around in my bed and trying to – I stared at the ceiling. I was trying to think of something to do in the blogosphere. That's where the idea for Gravatar came from. Just an idea that people could use it. It would be useful for them. I just created it and hacked it up. It turned out to be something that people wanted. People liked it.

It's always just that. It's always just wanting to contribute. I ended up selling that. That's what freed up my time to work on GitHub, actually. I was working a full-time job as well at a startup called Power Set at the time in San Francisco. That was like a search engine. Then I was working on GitHub on the side. GitHub was a project that I decided needed to be able to make money, unlike Gravatar. Gravatar never made me a single cent. Other than, except when I sold it. Running it, it didn't have a business model.

I wanted whatever my side project was going to be to have a real business model, so that if it became successful, then I could actually work on it full-time. That's why GitHub had a business model built in from the beginning, because I wanted – that was a filter criteria for me for new side projects to work on. It's always just that. It's just born out of what needs to exist that doesn't exist yet. What problems do I have that I can see a solution for and then just follow those threads?

Right now, I have a couple of side projects. I mean, RedwoodJS, I work on quite a bit with a team. I'm also working on a social media thing called Spoke, that's a social media for people building things, builders. As well as I have an electronics project. I've been trying to get back into electronics. I used to do that a lot as a kid as well. Getting into microcontrollers, modern day microcontrollers. I have a smart speaker controller that you use with NFC cards to activate and play an album. Who knows where those will go? I don't know. Maybe they'll go somewhere and maybe they won't. Just like all of my projects.

When we started GitHub, I didn't know if it was going to be a thing. I had no idea that it would become what it has become at all. I thought like, this would be cool for my friends and I to use together to share code and work on stuff that looks better and gets better than the version. It's always just chasing threads, interesting threads, following curiosity. That's really what it's born of, every project.

[0:05:49] P: At which point with GitHub did you know, because you said in the beginning, you didn't know if it's going to be successful or not. You just built it mostly for yourself and the friends and other people that wanted to use it. At which point did you know that, “Oh, I'm onto something and that this is going to be big”?

[0:06:03] TPW: I think we started to have a sense of that fairly early. We were really deep into the Ruby community in San Francisco at the time. This is 2007 or so. We'd go to Ruby meetups and we'd start showing early versions of it to people and people really liked it. I mean, Subversion, for any of you out there that have experience with Subversion, Subversion was not delightful, let's say. Lots of problems. Seeing something with a better branching and merging model was pretty eye-opening for people.

I think we really knew once we had the early version through the first version that we released after about six months of working on it. Then we started charging for it. We opened up the – we had a private beta and then we opened it up for people, public beta and started charging for it. People started paying for it right away. People were begging to pay for it even before you could pay for it, because they wanted it to exist. They wanted more of what it already was. That, I think, is an amazing sign when people are reaching out to you saying, “Hey, can I pay for this? Because I'm going to use this for my business and I want to make sure that I have support and that this is going to exist over the long term.” That was pretty obvious at that point. Then it just started growing. We had very strong confidence that we were onto something.

[0:07:28] P: Why did you start working on RedwoodJS? When sketching out the initial features, or the shape of RedwoodJS, and did you take any inspiration from any other frameworks, or any other languages?

[0:07:42] TPW: Absolutely. Yeah, really it comes from my background in Ruby on Rails. I love Rails. I mean, that's why GitHub is written in Rails. We were part of that community. Everyone I knew was doing Ruby, Ruby on Rails. I loved it. It's amazing. It's still amazing. It comes out of really two separate threads. One thread is I've been involved in Netlify, the hosting company for a long time. Sort of an early investor, an angel investor in their first round. I was with those guys in the dog patch when they were first starting. That really came out of my work with Jekyll, the static site generator.

Netlify was doing static site hosting, plus more. That's why I got involved. As they brought more features into Netlify, and especially when they brought in really easy to use Lambda functions, so you could just write a Lambda function, put it in a specific directory, push it up to Netlify. Now you’d get your static hosting, but you’d get your Lambda functions for free, essentially. You just put them in a directory and push them up. Using AWS's tools, it was annoying. You had to create a zip file and push them somewhere. There was no control. It's like, how do you keep track of this over time? Just not much good tooling to make that happen. A lot of friction.

I was thinking later on, and this is during Chatterbug, while I was working at Chatterbug. That's one thread. I thought it would be cool to create a framework that would leverage that set of technologies in the back of my mind, always. Meanwhile, at Chatterbug, we're building Chatterbug language learning software with Rails. We're using React on the front end, and then we build a mobile client. For the mobile client, we start using GraphQL. The mobile client consumes just GraphQL.

Once we had a sophisticated GraphQL backend API, then we started consuming that GraphQL API from the front end. Because if you have a GraphQL API, it's really a joy to consume and use as a front-end developer. Front-end developers loved using GraphQL, and so now we started using less and less Rails. It was really the GraphQL Ruby API and React consuming the GraphQL directly. Rails wasn't doing much anymore. I started thinking, why are we using Ruby at all if we're writing React in JavaScript? Why aren't we writing the backend in JavaScript as well? There's a lot of tooling around GraphQL, JavaScript, GraphQL libraries that were really great. But there was nothing that looked like Rails, like a framework that was all put together and integrated nicely. I thought that was a place that could use improvement. Everyone was using disparate tools. Everyone was integrating, doing their own integrations and doing them badly, because that's not what you really want to spend your time doing when you're building a company. You want to get to work writing the business logic, the interesting useful stuff of your company, not figure out how to integrate just testing with Prisma. That's just not a good use of time.

Coming from the Rails world, it seemed ridiculous to me that there wasn't a corollary to Rails in the JavaScript and TypeScript world. That was the beginning of that idea. I combined these two ideas, like how could I build this framework that made it possible to create a full stack web application and deploy it on Netlify using lambdas and the CDN, delivering Jamstack principles?

Hey, here's React, and it's React and GraphQL-based framework that could fit that model. Where now you're delivering your React application, SPA statically via CDN to the browser, and then you run your GraphQL API on lambdas that can be deployed around the world. You still have to solve for the database part. That was an exercise to be completed. The basic architecture seemed like it would work in a Jamstack architecture. We've deviated from that now. We could talk about that later how RedwoodJS has evolved over time.

That's where we started, right? We have nothing to do with Jamstack anymore. it's not Jamstack specific. We do a lot of things with servers. You can deploy to AWS, etc. At the time, those were the problems that I was trying to solve. That was the impetus for RedwoodJS to exist in the first place.

[0:12:08] P: What do you think as a full stack application developer within the JavaScript world, what do you think are the biggest challenges for developers that come and they try to start, build an application at the moment?

[0:12:22] TPW: I think choice is very challenging now. Maybe not some of the simple choices. It's very easy to reach for NextJS, because that is – it's a simple framework. You can go from nothing to something deployed, some web application deployed on the internet, especially with Vercel, they make it really easy. You can do that very, very quickly. That choice, I think, is easy. 

The harder choices come later once you decide that, “Hey, I need to actually do testing now,” or “Wouldn't it be nice to host my own database and what am I going to use to consume it? Maybe I need a mobile client at some point in the future. How am I going to – like, what kind of API am I going to use? Should I use GraphQL? Should I use REST? Should I use Jest? Should I use V-tests? I got to figure out my bundling situation now to make these things work together. Am I using Vercel's stuff, because that's where I'm going to deploy? But what if I don't want to be locked in, and maybe I should use something else and do my own thing and get off of Next completely and build my own framework?” This is often how it goes in the JavaScript and TypeScript world.

There is an inclination to just bolt things together. I'm not sure why that is. I think it just comes out of the general history of JavaScript and TypeScript that they've had such a long evolutionary history, but that Node.js is really not super old and mature and that we've all been discovering things together. There's the Cambrian explosion of possibilities that have been happening and JavaScript is so popular and technology is moving so quickly. There's so many different ways that you could do things that it's hard to settle down and say, “All right. Let's package these things up together.”

I think that we have reached a moment in time where that becomes very valuable, that that reuse, that that reuse of knowledge across projects and even across companies. That was something really nice with Rails, too, is that if how to work on a Rails project, you know how to work on any Rails project in its basic form. Of course, you're going to have differences between applications, depending on what you're doing, but you know the basics of what it means to work on a Rails app.

In today's world of commonly how people were building things, you'd have something like Next and sure, if you know how do you use Next, you know to use Next. But Next is just a very small vertical section of what a web application needs to be. Then you end up bolting on huge amounts of random stuff, randomly arbitrarily chosen things. Every Next application looks very different from each other, because you're choosing from the very large grab bag of excellent possibilities. There's a lot of great software out there.

At some point, you might want to just choose a set of technologies and know how to use it and solve your problem that way, so that you can go from company-to-company and just solve problems, instead of always jumping to newer and newer technologies and never really know what anything is doing.

[0:15:30] P: I was always comparing the JavaScript the landscape into more like a zoo, where you enter and there's like, each single animal is completely different. I didn't do much with Ruby and Rails programming. I don't have much experience with Rails, but I worked with Swift and with iOS development quite a lot in the past. Over there, when in the Apple world and just do as Apple does, and most of the problems and the decisions were solved before. There was very little wiggle room, where you could just go straight in and focus on what you're actually building.

When I came back to JavaScript world, it was rather stressful and I still, when I freelance a contract and I moved between projects, I always think that, okay, within the next project, somebody might be using completely different and testing library, completely different, or M4 the database. They might have completely different patterns on the front end. They might use React. They might use Vue. There's just so many possibilities, that even as a JavaScript developer, even moving between projects is already – and there's a learning curve sometimes, and before we get up to speed. I do understand this kind of, it's great to have those choices, but –

[0:16:38] TPW: Right. Choice is good, but too much choice can be paralyzing. I think that we see some of that. I imagine trying to come in and be a JavaScript developer today as a young person and the amount of choice that is possible there. This is the exact opposite from when I got started. When I was started, there was one thing I could do and that was write programs in BASIC. That's what I did. I didn't stress about anything. I just learned how to program. That choiceless thing can be powerful, because you just do it. You have no choice. You just go. Yeah, you just get to it. Pluses and minuses. Like in technology, it's always pluses and minuses.

[0:17:22] P: As a developer, so if I would be entering this entire zoo of possibilities and all the technologies that I could choose, why would I choose RedwoodJS and for my next project?

[0:17:32] TPW: I think if you want to build a web application, if you're serious about building something, this is today and we'll talk about the future of Redwood where we maybe make it easier to get started on random projects with Redwood. Today, with the setup that RedwoodJS has, if you're going to build a real project and you want long-term maintainability and you like the idea that you're going to have a framework that provides a lot of great integrations for you. Things like Storybook. I think Storybook and the ability to create React components in isolation, and as you're developing them, build them and be able to put them into any state that you want, so that you can see every possible state that your component can be in. Trying to do that inside your application can be quite challenging, especially over time as your application gets more complicated.

Being able to use Storybook to help you do that is amazing. I think one of the most undersold amazing-nesses of React, if you use React, like you have that available to you. Something as simple as integrating Storybook with your application, if you're doing that from scratch, if you start with Next, or whatever and then you want to integrate Storybook, you're spending some amount of time doing that. Depending on how well it goes, and sometimes it goes better than other times, depending on your setup and how complicated it is and if you're doing anything weird, that could take you anywhere from a day to a week, or two weeks. Getting testing integrated into your application, especially if you want to do things, like mocking out your API from your front-end to your back-end, things like that, those are really time consuming. You end up needing to do them eventually.

You might choose RedwoodJS, because you've done this before. You've built a web application before. You know that there's a lot of challenges there. How much time you spend working on the framework, versus working on your application code. With RedwoodJS, we as the Redwood team spend a lot of time doing all of that work that you would otherwise end up doing yourself. We have beautiful integrations between GraphQL and the Jest testing and Storybook and Prisma and generators to help you build out your pages and deal – work through the boilerplate that otherwise, you don't have something to help you do, and the ability to customize those things.

We've been doing Redwood JS now for three, almost four years. There's a lot of tooling there, a lot of sophistication and a lot of people that have been down these roads that can help with patterns that all apply into the RedwoodJS world. Really, it's about building together and access to a community of people that have been there before and probably hit some of the challenges that you're going to have in a similar way. Things like, where should I deploy my app to, if I have these specific characteristics? How should I upload photos somewhere?

We have developed so many patterns around building web applications that are going to make it easier if you like the basic set of components that we use right now. If you like GraphQL, if you like Prisma, if you like JavaScript, TypeScript, if you like React. If those are technologies that you gravitate towards, then I think you're really, really going to like Redwood JS. Even if you don't, even if you're not super familiar with GraphQL, Redwood is probably the best and easiest way to learn GraphQL and get comfortable with it, because we make it so easy to create your GraphQL API backend and deal with tricky things like authentication and permissions and security. Those are things that if you're doing those on your own, you're going to spend a long time getting that right.

[0:21:21] P: Recently, you've released a new version of RedwoodJS. It's called Bighorn, right? It's called Bighorn. You have announced that you are going full-on on React Server Components. I was wondering if you could maybe explain a little bit what are React Server Components and how does RedwoodJS use them?

[0:21:39] TPW: Yeah. This is not actually released yet. We've announced the next big epoch of RedwoodJS. The current epoch covers versions one through six. We're on version six right now. We did just release version six, which has some really great stuff. Bighorn is going to be probably version seven or eight, I'm guessing. It's not quite there yet. But we wanted to give people a preview of where we were going and that is exactly as you said, React Server Components.

React Server Components are a new way to think about your React Components. Traditionally, React Components are executing on the browser, on the client. You deliver down some JavaScript to the browser that contain your React Components. Then the browser executes those and you might do some data fetching client side to pull down data and make that available to the components. The challenges there are, you have performance issues. Because you're transferring down a lot of JavaScript, you have to wait for that to happen. You have to execute that JavaScript. Then there's challenges around things like open graph tags, so OG tags.

If you want to unfurl something on Twitter, for instance, and you have a pure single-page application, SPA, React application, then your index page is just a blank page with some JavaScript with a JavaScript tag on it, and no actual content, no place to put meta information, like OG tag information. Also, can be challenging for SEO, search engine optimization, right? Google's going to pull that page, it's going to have no content on it, and Google's going to have to execute the JavaScript on that page in order to get the content and they don't like doing that, so they'll penalize you for that. You want to be able to deliver more static information to the client.

The way that we have solved this before is doing some server-side rendering and then using hydration on the client side. You actually do rendering. You can render the page server side, and then you deliver HTML to the client. At the same time, you're also delivering that same JavaScript that you would that represents the page, like the whole page, everything on the page. The client will download that. The client can show the static version very quickly that was server rendered, and then rehydrate it by executing the JavaScript and essentially, replacing everything on the page with the dynamically generated stuff that is rendering client side using your React components. Now you have that same React page that you would have, even without server-side rendering. That's one way that you can solve for these problems and deliver real HTML to the client with the first page load. This is, I think, frameworks like Next have been doing this for a long time.

The React team themselves are looking at some of these problems and these patterns that people are using and wondering how they can improve React to make those patterns a little more first class and more flexible. React server components are a type of React component that is intended to render on the server and then be able to make that – the use of React components and this idea of hydration a little easier, because you really don't need to rehydrate parts of the page that are always going to be static. That's the idea with a React server component is that something in a React server component really is always going to be static. It's not really intended to change.

If you want something to be interactive and changeable, then you have your React server components, those get rendered server side and sent down as static HTML to the browser. Then nested within those at some point in the leaves of the tree of React components, you'll have then client components and you tell your framework which of your components are intended to be client components. Those will then be sent down as – well, they will actually be rendered server side first if you allow it and you can – there are ways to tell your framework to not render those.

But generally, the server is going to attempt to server render even your client components, send down that content and then the browser will rehydrate just those client components. It's not sending down JavaScript for components that don't need to change in the browser. It's being more efficient about the hydration process, essentially.

[0:26:15] P: Would it be that, for example, within and just if I understand it correctly. For example, within the server side, rendering the website would serve the HTML, but then would be hydrated with the JavaScript code that's inside. With React Server Components, only the parts would be hydrated that really need to be hydrated. Then the rest is already rendered on the server side.

[0:26:37] TPW: Essentially. Yes. Along with this comes streaming as well. Streaming and Suspense. Suspense has been something that we've waited for a long time in React and Suspense is now a real thing that you can use. The cool thing about Suspense and Streaming is if you put a Suspense tag around a chunk of your code that you want to deliver to the browser, because you're going to do some data fetching within something that's inside the Suspense boundary, you can still have that execute server side.

Let's say, you have a server component that needs to do some data fetching that's going to take two seconds. You want to be able to ship down most of the page without waiting for that piece of data, but you don't want it to be executed from the client. You don't want the browser to have to do that data fetching. You'd still want to do that data fetching on the server. You can have a React server component and put a Suspense boundary around it. React, if you're using React server components and Streaming, then the server will skip over where your Suspense boundary is. It'll render as much of the page as it can without the stuff that's inside your Suspense boundary. It'll ship that down, that's your initial page load, but it keeps the connection open.

When the content of that server component that is within that Suspense boundary, when that completes and renders, that will use that same connection that's still open and it will send down the rest of the content that is from inside that Suspense boundary. React knows how to receive that and then insert that into the page in the correct location to complete the content that was within that Suspense boundary. You can do some really nice things for usability, things that make a page feel like it loads much faster. You can do it on your own terms.

We're leveraging a lot of these things to do some of the things that we already do in Redwood. We have this pattern called cells for data fetching; client-side data fetching using GraphQL, that we will adapt to use React server components instead. You'll have the choice of doing something like that on the server side and even doing GraphQL fetching all server side, where you're still using GraphQL if you have a GraphQL API, but you won't need it anymore. I'd love to talk as well more about that if you're ready for me to dive into some of that.

[0:29:06] P: Absolutely. Yeah, so this is what the React server components are still thinking. It's quite about new technology, so we're still adapting to it. Just in general, do you see any limitations for React server components? Did you see any parts of it that you didn't like, or didn't agree with?

[0:29:25] TPW: There's always challenges when you're trying to be able to execute something on the server and the client that you get into trouble, because you're using something that might be server only, or client only. For instance, if you want to read, get access to the headers of the request, for instance, that's something that the server can easily do, but that doesn't really make sense to the browser. You have to be very careful what you're doing in your components, so that they can execute in the correct context and hopefully, execute in both. You spend more time, I think, thinking about execution contexts than I really prefer. It's an additional complication. It allows for these really nice and very efficient systems to work, but you can get yourself in trouble where you don't realize that you're using something that is, say, a client-specific API.

Then the server's trying to execute your component server side to be able to generate your first static page. Now it has to complain to you that, “Hey, you can't use this.” Then you're like, “Oh, you're right. I have to think about –”

[0:30:36] P: For example, if you use a window, like a reference to the window. A local storage and something like this. Yes.

[0:30:43] TPW: Yeah, exactly, exactly. There's whole classes of things that won't work in the opposite execution context that you have to think about. Coming from Rails, everything was server-side and it was just like, I don't know, you didn't think about any of that. You didn't think about execution context at all, really. There is simplicity in that, but there's also limitations.

React Server Components are trying to take the best of both worlds, the best of both server execution and client execution and giving you the flexibility to say, where you think execution is best done for your user experience. I love that it gives you that power. You can make really, really great UIs that way. Because sometimes you want a very client-heavy experience, like for a music player, like Spotify, for instance. You want that whole thing to be client-side, because you're constantly interacting with it. You need to be able to replace portions of the page, or the whole page without stopping the music playing, so you can never do a full-page refresh.

Things like that are not possible, or very challenging to do with a fully server-side model. But with React Server Components, you can carve out different parts of your application and say, this part is going to be heavily server-side, because it's mostly statically delivered content that doesn't need to change. The user's not changing stuff all the time. These other parts are very highly dynamic, because maybe once you log in, then you want a very dynamic admin panel that you're changing lots of stuff all the time and that makes more sense to be in the client, because it can be very responsive, because all the code is executing on the client.

It really is about your use case and choosing the technology to best fit your use case. React Server Components are codifying that and saying, here's a common way that everyone can do this to give you that reusability across companies and projects.

[0:32:45] P: With the new release of RedwoodJS, so what other plans apart from the React Server Components, what other aspects are changing, or improving?

[0:32:58] TPW: That's a big part of it, but we also have things like real-time GraphQL that are coming in. Those are actually in the current version six release. You can start playing with those already. Real-time, so you can do GraphQL subscriptions and you can do live queries, which is a similar technology, but slightly different depending on what use case you're going for. Those are coming in.

We also have some really great developer time diagnostics that we're working on with a product called Studio. Redwood Studio is going to be an application that you run alongside your RedwoodJS application as you're building it. We instrument the framework with open telemetry. Then you can point your Redwood Studio at your application and say, “Give me the stats of my application.”

Let's say, you have a SQL query that you want to inspect. If you're using Prisma, it can be a little challenging to get and see what is the actual SQL that's executing and how many queries are being generated for a specific Prisma statement that you execute. Studio allows you to introspect that and see a request and everything that goes into that request and the timing and dig into what the SQL queries were and how long each of those took to execute. Everything that's happening server side, you'd be able to introspect with Studio. It's a new relic, for instance; one of these observability platforms, but you have it during development very easily and completely for free. There's things like this that we're doing, that really make the platform much more sophisticated than you would expect a framework to be.

[0:34:40] P: Would it be end-to-end? For example, from the API call, or the GraphQL call that I'm executing, could I track it with Studio all the way down to the database? If for example, I happen to have a bottleneck, which not necessarily comes from the database, it might come from the business logic?

[0:34:55] TPW: Yeah. Oh, yeah. Everywhere in the stack, it's all instrumented with open telemetry. Every part of everything that we can wrap in open telemetry. Once you get into your specific code, then you might have to – you'll have to add some open telemetry stuff into your own business logic if you want to be able to see deeper within the business logic that you are writing. But automatically at the resolver, if you're using the GraphQL stuff, at the resolver level will give you that information and everything below into when it goes back into the framework via Prisma, or other things.

[0:35:29] P: Could you speak a little bit more about the GraphQL, about the real-time updates that you said in the live queries? How does it work? Is it mostly to replace, for example, the use of sockets, possibly for an application that has to run within the real-time?

[0:35:44] TPW: Yeah. It doesn't use web sockets. I didn't implement this. There's the other technology, like server sent events, something of that nature. I'm sorry, I don't remember the specific name of it, but it's the HTML way, the HTTP way to do that. It keeps a socket open and it sends events over that stream. You need something that is a persistent server. This is where we get away from serverless. Their lambdas are getting to the point, where you'll be able to do more of these things soon, I think.

Honestly, lambdas haven't evolved as much and improved as much as I thought they would when we started the project. I really thought that lambda would improve and evolve much more quickly. Oh, server sent events, I think is the name of that technology. You needed something that looks a server, right? React Server Components, obviously need some kind of a server to execute the server components. A lot of the new versions of Redwood are leaning more towards dedicated server deployments, though we will still make them work on Netlify and Vercel. Obviously, Vercel, the only place that you can really do React Server Components today in a real way is via Next and deployed to Vercel.

Obviously, you can do it. That's all serverless. Obviously, it can be done, right? They just are using serverless functions to act as the server part of that. We need to build the right adapters to make it work in serverless environments, which we will do. We're not optimized for that anymore. In the beginning, we really were. We were very optimized for Jamstack and serverless.

Now, we find that most people choose to deploy onto server-full environments, things like Render, or fly.io, AWS directly, because of the performance issues. You don't worry about cold starts. You don't worry about the costs. Costs can be unpredictable with serverless platforms. We see a lot of people choosing either something that's containerized, or just bare metal. We have a deployment strategy called bare metal, where it's just like, hey, get an easy to server and go for it, right? Do everything yourself.

[0:38:06] P: You've seen with Redwood, from the start, you optimized for the serverless and now you're seeing a move of the community as well, the applications more into the server-full. This is to both keep the persistence for the GraphQL and to avoid any additional issues with server-side rendering. I was wondering –

[0:38:26] TPW: Yeah. I mean, it's been that way for a while. This transition happened a year and a half ago, really.

[0:38:33] P: Wasn't mostly thing led by the community. I was wondering, how do you choose what technology is RedwoodJS made of? How do you work with your open-source community at the same time? Do the community have any input on that?

[0:38:49] TPW: Yeah, absolutely. The community is one of the primary pillars of RedwoodJS. From the very beginning, I wanted it to be a first-class open-source project. A huge part of that is how we treat collaborators, what kind of community we're creating. I thought a lot about like, how can we make the best open-source community that we can? Really inviting people to contribute and all of the core members came in through just starting to contribute. I fund a number of them to work on it full-time, because it's open source. There's no corporate entity behind it. I just fund that myself, because I like it being a pure open-source project that's not affiliated with a commercial entity right now. I like the freedom that that gives the project.

We have a Discord channel. We have a discourse forum. Very active on both. We do a lot of community events, from town halls to a conference. We're about to throw our first conference in September. I could speak to that for a few minutes, that regards our community. This is September 26th through 29th. It's going to be in Oregon. Southern Oregon, United States. It's going to be a four-day conference. But two of those days are the main talks. Then there's an optional workshop day on the front end, and there's an optional having fun and doing things out in nature, or doing crafts on that fourth day, or just hanging out with the other people in the conference. It's going to be awesome. It's going to be about RedwoodJS, but really, it's much broader than that. It's about entrepreneurship, security, design, everything in and around building web applications. Oh, and you can go learn more about it at Redwood JS Conf.

[0:40:40] P: You have an open-source community, but also you're planning to do your first, I think it's the first conference in Oregon and could you speak a little bit more about that?

[0:40:49] TPW: Yes, so we're holding our very first in-person conference. It's going to be September 26th through 29th this year, 2023 in Southern Oregon, United States. This is going to be a four-day conference. The first day is an optional workshop day. The next two days are going to be where the talks are. Then there's a fourth optional day for doing fun things around that location. This is in Grants Pass, Oregon. It's beautiful. There's Redwood trees there, if you want to come see some Redwoods, or do crafts, or just hang out.

This conference is really about more than just RedwoodJS. That's the reason that we're putting the conference on. It's really to talk about the future of React and React Server Components. I'll talk. I'll give a keynote, where I talk specifically about RedwoodJS and how we're using React Server Components and where we're at and how you can use them and experiment with them at that point. It's really about everything around building a web application today. Security, design, performance, even how to build a company. We’ll have talks about raising money, etc. Business people will be there. Everything that you might need to become an entrepreneur and really be successful at building a web application. That's what this conference is about.

We've designed it to be fairly intimate. It's a smaller conference. My favorite conferences that I've ever been to have been in the order of a few hundred people in a location where you can really spend time getting to know each other. That to me is the real value of a conference. The people, the people that you meet there, the conversations that you have. This was such a big part of my experience growing up in the Ruby community was going to these small conferences. This is what we're trying to replicate with this conference. You can go to redwoodjsconf.com and find out more information there. I'd love to see you there.

[0:42:38] P: We'll also put the link in the description of the actual podcast to make sure that people can just click through. For people that won't be able to attend physically, but would still like to tune in online, would there be any option to view the talk happening?

[0:42:54] TPW: Yes, absolutely. You can purchase online tickets at any time and watch the content being streamed.

[0:43:01] P: Excellent. Coming back a little bit into the community part and into the projects that are currently using RedwoodJS, I was wondering, do you have any favorite projects, or any specifically interesting projects that you would like to mention that evolved into startups and that are using RedwoodJS? What do they do?

[0:43:21] TPW: Yeah. One of the co-founders of RedwoodJS, Peter Pistorius, who I worked with at Chatterbug and was been with me on the RedwoodJS journey since the very, very beginning, he founded a startup called Snaplet that he's been doing for the last couple of years, which is built with RedwoodJS, and is really amazing.

Snaplet is a way to, well, let me present the problem to you. You're building web application and you make it, you put it to production, you have a bunch of people using it and they're all putting their data into the database, but you're still developing it locally. When you're debugging things, especially, it's really nice to have some production data to do that, because like replicating a database that looks like anything useful, or anything that is going to help you fix a bug, or build a new feature, all of that's in the production database. You really want to copy that production database into your local database. That's a very bad idea, obviously, right? Security issues are plentiful, privacy issues in doing that. It is definitely not best practice to do that.

Snaplet allows you to create a subset of your database and then anonymize it. Replace any personally identifiable information, replace that with anonymized data, so that you can take a smaller subset of your potentially very large production database and then use that locally to test against, to work against. Snaplet.dev is the website there and they use RedwoodJS. That's one of my favorites.

There's a startup studio called Fractal and there's a bunch of startups, a dozen or more startups that have come out of that that all use RedwoodJS doing vertical SaaS. There's one called left lane. They've been using RedwoodJS heavily and growing quickly. They build software for used car dealerships to manage their inventory and then manage people applying for credit and doing the financial side of it. I think that's really cool. There's so many opportunities to build SaaS applications in places where modern technology has not yet really helped them out sufficiently. Tons of these vertical SaaS cases.

Or another one, a different place in the UK called Nous is helping people manage their household buildings and keep track of electricity usage and other things in the UK market and giving you tips for how to manage that better. They've raised something like 10 million pounds or something for that. Overall, we like to track startups that are using RedwoodJS and really bring them into the open-source ecosystem and help them out. We have a private channel where we get together with the startup founders once a month and try to help them out as much as we can from our past experiences as entrepreneurs within the community.

So far, companies that use RedwoodJS, so companies that are building with RedwoodJS overall have raised something like 70 million dollars in funding. We like to keep track of that number just as a bellwether of how many startups are using RedwoodJS. Of course, that doesn't represent all of them and probably we're a little behind on some of the fundraising amounts, but these companies choosing and believing in RedwoodJS is really important to us. We want to really help them as much as we can.

This is another reason maybe to choose Redwood is that you get access to this whole startup ecosystem of people that can help you out along your way in that admittedly very challenging journey.

[0:47:17] P: As a developer, if I'm using RedwoodJS, I have just built my site project and I'm trying to turn it into a startup to be featured, or for example, to connect with the community, what is the easiest way to join? Is it just to join Discord channel, or on GitHub, or do you have any preferred way of bringing new people?

[0:47:36] TPW: I mean, Discord is great. Obviously, we love any interactions on GitHub if you're from submitting an issue, saying that you have a problem with something, or well, we especially love pull requests. Any of the community channels, whether it's Twitter or, sorry, X. What do we call it now? I don't even know. Or is it for real though? Is it going to be a joke?

[0:48:00] P: This is going to stay, but I've seen already. If you do x.comflash your username, I think then it redirects. No, if you do Twitter, they redirects it to X. I think if you do X, it redirects you back to the other one.

[0:48:13] TPW: Who could even know? Anyway, on that platform, you can find us, RedwoodJS. I mean, any of them just reach out and say, “Hey, I'm building with Redwood. I would love to chat. If you're building a real startup, then we'd love to get you into the community.” Any of the ways that you can reach us are viable.

[0:48:34] P: Could you speak a little bit more about the team that works on RedwoodJS? How do you all work together? Because it's an open-source project, but there are some people that work full-time. I was wondering, what's the dynamics? What kind of mode do you work in?

[0:48:47] TPW: Yeah. We work in a very open-source fashion. We're distributed all over the place. We've got some people here in California. We've got people in the UK, Scotland. We've got people in – one of our guys is in Thailand. It's all over the place. We all came together by contributing. Everyone that's come to join the core team came in through actually contributing. Then some of those people I've hired on full-time to work on RedwoodJS.

I think it was a year and a half or so ago, we announced the RedwoodJS 1.0 release saying, we're production ready. You should use RedwoodJS. At that time, I committed to spending 1 million dollars a year on funding the development of RedwoodJS. That's around what we're running now. I employ some people to work on it. That represents the core team. That's really just selecting the most committed developers, the best and most committed developers that we found around the RedwoodJS ecosystem, coming in from just authoring pull requests. Elevated them to core membership, and then I pay them so that they can spend their time doing that and we can make a really sophisticated system, without having to compromise our open source values with a commercial entity.

I mean, I would love to make money with Redwood someday, but it's not my top priority right now. More priority to me is building the most amazing web framework that we can. I think with the Redwood, or sorry, with React Server Components, the future for that is even better. One of the challenges is that we started with a very sophisticated model, with a very sophisticated framework. We’re trying to figure out how to make it more accessible to people that were just experimenting, right? We started upmarket.

Where something like Next.js started down-market, super simple, just a very small component of what you're trying to do, like this rendering framework. Then have gone upmarket, become more sophisticated trying to reach broader markets. We put together this very integrated full stack framework, kind of upmarket. Now, we're trying to figure out how to come down-market and make it more appealing to people that are just doing a weekend hackathon, or something. 

In those instances, building out a full GraphQL API, even as easy as we make it, feels like a lot. React Server Components allow us to give people the option of not needing to use GraphQL. Once we release a Bighorn release, a release with React Server Components, then you'll be able to choose to not use GraphQL at all, and so you might start using just React Server Components and doing your data fetching server side. You're reaching directly for Prisma, directly into your database, fetching your data, and then that gets rendered and sent out to your client. You don't need to use GraphQL to do your fetching anymore. You'll be able to do that very, very quickly.

Because we have such great GraphQL support, if later on you want to add a mobile client, an iOS app, or an Android app or something, and you want to use GraphQL for that. Well, we have amazing GraphQL support fully integrated that you can now start building out your GraphQL, like API back-end, but you probably at that point have dedicated GraphQL people and know how to build and manage a GraphQL API with all of the performance and security challenges that can come along with that.

Then once you have your GraphQL API, like I was saying before, your friend and people start to want to consume the GraphQL API. Making it really easy then to consume the GraphQL API from your React server components, so you're still doing your data fetching server side for the most part, but you're doing it via GraphQL server side, which is maybe a little weird, but also awesome. Because with GraphQL, you're just saying, “Here's the data I want.” You're not having to worry about how to pose this, how to construct a Prisma query to do that in a performant way. All of the performance stuff has been handled for you already on the GraphQL API side. You just say, “Here's the data I want.” You can be very flexible about that.

In that scenario, you're not even having to worry about security as much, because you just don't make your GraphQL API public if you don't want to. I mean, you can’t if you built it because you're doing a mobile client, then probably it already is, but you wouldn't have to. There's this, to me, this beautiful evolution using Redwood where you can get started very easily once we have React Server Components, and then grow into GraphQL as a more sophisticated API that allows you to consume it, both from a mobile client, or any client, and then also in your own front end.

[0:53:47] P: Just also a nice way for startups with limited resources to grow gradually and more progressively growing into the ground.

[0:53:56] TPW: Yup. That's really everything around building a web app is you want to be iterative. You want to do things incrementally. Making huge commitments upfront tends to slow you down. That's exactly where we're trying to go.

[0:54:07] P: Or completely kill the product.

[0:54:09] TPW: Yes. As it may be.

[0:54:11] P: Now, I was wondering, how do you imagine the future of software engineering within the next 10 years? What part of it are the most excited about?

[0:54:19] TPW: That's always a challenging question. I think, obviously, we have to mention AI in that discussion. Things like ChatGPT, and Co-Pilot have already changed how we write code. I use it extensively when I'm – especially when I'm working on my electronics project, where I'm writing primarily C and I don't write a lot of C normally. Having ChatGPT there to say, “Hey, what's the idiomatic way to do this thing? Or how should I deal with memory in this instance where this function is allocating memory and then needs to return it? What is the normal way to then free that up? Who's responsible for that?”

These questions that you can Google, but you end up having to go through five or six articles before you find something that really gets at what you want. ChatGPT makes that really easy to get to much quicker. That's level one of AI. I mean, where are we going to get to? How many years will it be before we're not really writing low-level code anymore? I think it's really hard to say. But over a 10-year span, for instance, I think we probably get much more descriptive about what we're doing and we leave some of the details to AI systems that are very good at building those out, because there's so much example code to do that.

We'll probably have frameworks that are specifically designed for that, where instead of writing the code itself, you're writing more of a descriptive language. You have something that looks like more pros, but it's probably a little bit more structured than just like, say what you want. That you could use that to start with and then an AI system would generate that. Then at that point, you can have a conversation with it and say, “No, I actually want to change this thing in this way.”

It essentially, I guess, becomes a programmer that you're standing behind, pointing at things on the screen saying, “No. What if this form had this other field?” It's really hard though, because we as developers, everything that we do is very specific, right? Like, I need this field and this form to go into this column in this database with this transformation, so that I can do these things with it in the future. I think it could become very frustrating to try to do that with AI systems, where you're just spending the same amount of time and effort to do things. You're just speaking in English instead of code. I don't know that that's necessarily an improvement.

[0:56:57] P: Because they'll have to describe each single piece very specifically, you mean, so we just spend time hanging over it.

[0:57:04] TPW: Right. If you want to be that specific, that's what code is. It's just a very formalized version of English that allows us to be as specific as we want it to be, really, at the end of the day, right? I'm not sure exactly where that goes. I think it's very difficult to predict, but it will obviously change the way that we write code, the way that we build web applications.

I think the harder thing to do is to create something really new. How would you build a web framework? I'm trying to think of how would it – does this replace me as a person building a web framework? How do we get an AI to do that? That's really about bringing the creativity and the curation of selecting specific technologies and things like that. I mean, at some point, maybe it doesn't matter, because AI is doing – choosing of all the technology and you don't even care what language it's writing in anymore. I'm not sure.

I think there will be a lot of frustrating times between now and that vision of the future where you really just, the Star Trek vision of the future, or just like, “Hey, computer. I need this thing.” It's like, “All right, I got you.” You're happy with the outcome, I think we're quite a ways from that. I think in the meantime, we just become happier, more efficient developers, because we have better ways to answer our questions.

[0:58:32] P: Do you think that it might potentially make the future generations of developers more incompetent, because they will just go and ask for each single of the things that they don't know and receive pieces of code that might be too complicated to understand, for example?

[0:58:47] TPW: Well, sure. But in the same way that we today are more incompetent at machine code level things, because we don't write in an assembly anymore, right? The things that we do at the level that we're writing code are probably much less efficient than if you were to hand code them in assembly. The question is, does it matter? Have computers become fast enough that we can get done what we want to get done much faster, but at the expense of some performance? I think that's the real question.

I think, obviously, we probably become less good at understanding the very deep-down bits of computers. Not everyone, obviously, but the everyday programmer. That's been happening for years. It's just a further evolution of the abstractions that you build.

[0:59:45] P: The level of abstraction, yeah.

[0:59:47] TPW: Right. No code tools are the same way. Those tools can be amazing, like things retool and any of the no code kinds of web flow. All of those are basically saying, “You know what you want your thing to look like and behave like. Just tell us that. then we'll code it up for you underneath, because you don't actually need to know that.” Does that make you more incompetent at programming? Certainly. You don't even need to know how to program to use those tools. You're completely incompetent at programming. But guess what? You're solving your problem faster than someone who's coding it from scratch. Who's the better programmer at the end of the day?

Really, at the end of the day, programming, writing code is a means to an end. In my book, I mean, I love programming. I love the act of programming, but I only program, I only write code really to solve problems, to build solutions. To me, that's the outcome that it should be optimized for is building solutions. Whether we write code, whether we write assembly, or we write C, or we write Ruby, or we write web flow, to me, it doesn't really matter. What matters is, are we building something valuable that makes people's lives better?

[1:01:08] P: As the last question, as a request for advice, I was wondering, do you have any advice to developers who are currently trying to turn a side project into a startup, into a successful one?

[1:01:22] TPW: Yeah. I'd say, you first have to try. You have to decide that you want to do that, that you need – and then you need to learn what you need to do it. It's not always programming. Oftentimes, it's marketing, or sales, or something, going to conferences, talking to people, finding customers. That is the sometimes disappointing answer for programmers, because we often become programmers, because we don't want to go be a salesperson.

If you want to build something valuable, a product that people love to use that solves a problem for them, you have to do all the parts of a business, really. Yeah, you have to build a thing, but you have to get people to know about the thing. You have to solve the problems for them when they start using the thing and it doesn't work the way that they intend it to work for them. You have to become a customer service person. You have to do all of those things.

I just say, the right way to be successful at building a startup is to be willing to do whatever it takes to solve the customer's problem and figure, and be happy doing that. That's the right attitude. That's the right person to be successful with a startup, is someone who's after it to solve problems and create value, not just to be a programmer.

[1:02:47] P: And use the right web framework.

[1:02:50] TPW: And use RedwoodJS, of course.

[1:02:51] P: Exactly. Cool, awesome. Thank you so much, Tom, for your time.

[END]