KBall interviews TPW about the 1.0 release of Redwood - what it provides, why they’ve repositioned as a “JavaScript framework optimized for startups”, and what’s coming next.
Tom Preston-Werner: Yeah. Well, Redwood really started as kind of a technical experiment to see if I could build a full stack framework for the JAMStack. And that used to be our tagline, was full stack for the JAMStack. Because of what Netlify made possible– and I’m on the Netlify board. I’ve invested in all the early rounds of Netlify, and have known the founders since forever… And when Netlify started to make it really easy to package up lambda functions and get those deployed along with your more traditional JAMStacky, like your static HTML, or if you have a React app that you’re going to deliver via the CDN - I thought that was a really interesting model and could be the base of a more modern kind of architecture for full-stack applications. If you had a React application that you want to deliver via the CDN and you have your business logic which you can deploy onto lambda functions, and then you have a database somewhere - and that was that kind of the unknown, part of it - two years ago, when we were working on this it’s like, “How do you deal with this? There’s not a lot of good serverless databases.” Now there are. So that part of it is actually mostly solved, and we made that work.
So you end up deploying an implementation of a GraphQL API that you write in JavaScript or Typescript, onto a lambda, but you deploy the entire thing to a single lambda, which has certain characteristics. Lambdas are not perfect for everything. And so this architecture works and makes that possible. And we have a lot of people using that still today, this serverless deployment option for Redwood. But what we also realized was that’s not going to be suitable for everyone. So there are certain performance characteristics that you might not like. The cold start times are still longer than we’d like them to be. You will eventually max out how much code you can put into a single lambda function.
And so we started experimenting with other deploy targets, and so now Redwood is not specific to serverless at all; you have an option. You can still deploy serverlessly, if that’s what fits your needs, but you can also deploy to traditional serverful providers, things like Amazon. We have a deployment option that we call Bare Metal now, where you deploy in a way that looks very similar to how you did it with Rails and Capistrano, where you’re SSHing into an EC2 instance and getting it set up in that way. And it’s super-fast. It’s really amazing. You have all the flexibility you want around that. Or you can go somewhere in between, right? You can deploy to Vercel, as well as Netlify. You can deploy direct to EC2… But you can go in between with services like Render, where it’s more of a containerized style approach. And so Redwood works across all of these.
And so that was one thing that brought us away from the initial sort of idea for Redwood. And so we started thinking, “Well, what is the differentiator for Redwood?” Why would someone choose Redwood over something like NextJS, which is obviously the most popular player in the React universe for building a site, and for good reason. It’s really a great technology. So why would you choose Redwood over some of the alternatives? And what I started to think about was how much we integrate and how much we do for you out of the box and who’s going to need that, because some of these things make the framework more complicated.
[00:08:19.17] Like, if you look at Next, Next is really pretty simple. There’s not a lot to it. It has a small surface area. It doesn’t try to be full-stack. It gives you hooks to do database calls and other things that you want to do from a server side perspective, but it’s not trying to be opinionated in the way that I wanted to build a framework that was more like Rails, to give people a lot more out of the box, make a lot more decisions for you out of the box. And so Redwood integrates React on the front side, and it uses GraphQL to communicate from the front end web SPA to the back end, which is a GraphQL implementation using Apollo server. And then you use Prisma as an ORM to talk from your GraphQL API to your database, and that’s all in your business logic.
And then on top of that, we also integrate Storybook and Jest for testing, and we have a bunch of authentication providers that you can install with a single command line invocation, as well as different deploy targets. And all of this and a bunch more - logging is included, security by default for your GraphQL API; a really great way to build your GraphQL API using what we call Services… And then on the front end, declarative data fetching using what we call Cells - all of these different things, we’re packaging up and integrating. And to me, that looked like what you need to build a startup; something that is larger than a weekend sort of hack that you might do to experiment with some idea. That’s where Next, I think, shines so well, in just the ease with which you can get something up and running.
With Redwood, you have more complexity out of the gate, because you’ve got– I mean, GraphQL alone and the strict separation that that gives you from the front end to the back end is more complicated, and so it makes it more difficult perhaps to hack something together in an hour. But if you’re building something for the long term, a little bit of that upfront complexity that you have to deal with is going to give you great dividends and maintainability in the long run, as well as helping people– once you grow a team, you have specialized people developers. Some people are doing front end, some people are doing back end. You’ve got all these different roles. And having that kind of separation of concerns of what the different parts of the framework are doing - to me, in my experience as building large pieces of software and large companies, that is what becomes extremely valuable and maintains your velocity in the long run.
And so that is what made us start to say, “Well, Redwood is optimized for startups. It’s the app framework for startups”, because that then is something that someone can say, “Oh, I’m building a startup. I want a piece of technology that’s going to get me further, faster and do more for me, and deal with all of this stuff that I don’t want to have to do, so that I can focus on the things that make my business different.” And so that’s why we’ve really started to talk more as Redwood being for startups.
