902: Fullstack Cloudflare with React and Vite (Redwood SDK)

Wes talks with Peter Pistorius about RedwoodSDK, a new React framework built natively for Cloudflare. They dive into real-time React, server components, zero-cost infrastructure, and why RedwoodSDK empowers developers to ship faster with fewer tradeoffs and more control. Show Notes 00:00 Welcome to Syntax! 00:52 What is RedwoodSDK? 04:49 Choosing openness over abstraction 08:46 More setup, more control 12:20 Why RedwoodSDK only runs on Cloudflare 14:25 What the database setup looks like 16:15 Durable Objects explained – Ep 879: Fullstack Cloudflare 18:14 Middleware and request flow 23:14 No built-in client-side router? 24:07 Integrating routers with defineApp 26:04 React Server Components and real-time updates 29:53 What happened to RedwoodJS? 31:14 Why do opinionated frameworks struggle to catch on? 34:35 The problem with Lambdas 36:16 Cloudflare’s JavaScript runtime compatibility 40:04 Brought to you by Sentry.io 41:44 The vision behind RedwoodSDK Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Welcome to Syntax. Today, we have a really interesting guest on to talk about Redwood SDK. So, we had Tom Preston-Warner on, I don't know, maybe a year, year and a half ago, to talk about Redwood JS. And they've done a little pivot into something called Redwood SDK. And I'm so excited about this, that it's middle of the night for Peter, and I just DM'd him. I was like, "You want to record right now?" And he said, "Yes, let's do it." So, I'm pretty excited about it. Welcome, Peter. Thanks so much for coming on.

• 0:36Speaker 01

  It's a super pleasure to be here. I'm also really excited by you picking up Redwood SDK. I obviously wanted to spread like wildfire. I think it has some great ideas. But I want people to pick them out, you know? Let's chat about them, figure out what's better.

• 0:53Wes Bos?

  Yeah, so I just spent the last probably hour and a half going through it. So, like, I've got a million questions, and my headspace is in it. So, the idea with Redwood SDK is that it's a framework for building React apps on CloudFlare? Is that... Give us the pitch of what it is.

• 1:13Speaker 01

  Yeah, yeah. So, Redwood SDK is a React framework for CloudFlare. It starts off as a beat plugin that then gives you server-side rendering, React server components with client-side hydration, and then also real-time capabilities that are provided by CloudFlare's durable objects. Then, CloudFlare is the platform. So, what you get from them is a super-fast edge network all over the world. You get a D1 database. You get R2, so you can store your files. You get queues. You get really, really great abilities to serve images to the right devices at the right resolutions.

• 1:57Speaker 01

  And you basically get that for $0 a month, or

• 2:02Wes Bos?

  Yeah.

• 2:02Speaker 01

  $5 a month. When we were coming up with the idea of what Redwood SDK was, I'm from South Africa, so I live in a rural community in South Africa. There are 2,000 people where I live. And for me, it was really important that I could build software that was good for people in my community. And I mean, good in terms of latency. There are very few providers out there, hosting platforms out there that have servers in South Africa. And CloudFlare has them everywhere. I think they have something like 230 edge networks. And you know, CloudFlare is a networking company, so they really, really know what they're doing when it comes to making things fast. So.

• 2:44Wes Bos?

  Yeah. So I was very excited about this when I saw it because there's a couple of things that I'm bullish on right now. And one of them being the CloudFlare and all of their products. They've sort of been on fire recently, releasing like Workers is really cool, the durable objects is really cool, their queues is really neat. And then, of course, like you said, it's relatively affordable compared to lots of other options. I went to move my own personal website, which is a React-based website, to CloudFlare. And I first moved it to NextJass with server components, and I tried to use OpenNextJass.

• 3:26Wes Bos?

  And it worked pretty good, but it wasn't totally there at the time. So then I moved it to Waku, which I deployed great tools to server components, and that is also based on Veet, because I'm pretty big on Veet as well. But there's not, aside from Waku, there's not a whole lot of like Veet and React server components out there. So the fact that this gives us that was pretty exciting.

• 3:54Speaker 01

  Totally. And you know, the thing is, we first validated that CloudFlare was a was a good platform for us to target. And then we built the framework from scratch within CloudFlare's worker D runtime. So we try to make sure that everything that we are giving you is CloudFlare native, so to speak.

• 4:15Wes Bos?

  Yep.

• 4:16Speaker 01

  But with the pluggability of Vite. And Vite is just released, or they're busy releasing the React Server DOM Vite plugin, which is the thing that enables React Server Components. It used to be a webpack only thing, and we kind of like shimmed a whole bunch of stuff to make it work. And now it was, we deleted 1,400 lines of code when we replaced it. So the ecosystem is catching up to React and React Server Components, specifically in Vite, in Vite land. And I think we're the right product at the right time.

• 4:49Wes Bos?

  Yeah. Another thing I noticed about it is that it's, this is not like a framework built on top of these technologies, which maybe, maybe Redwood JS was. But this is more of like, like an SDK, dare I say, an SDK that works with the tech that you want. Meaning that it's not like, you're not burying all access to all of these packages that we know and love, like Prisma, or any other ORM stuff, or any of the CloudFlare stuff. You are simply, you import them directly like you, like you normally would, right? Was that an intentional decision?

• 5:30Speaker 01

  That was an incredibly conscious decision. I don't know if you've seen this image of Elon Musk's SpaceX, where they have these iterations of the different kinds of rockets that they're building.

• 5:41Wes Bos?

  Oh, yeah, yeah.

• 5:43Speaker 01

  So I was the co-creator of Redwood JS, and now I'm creating Redwood SDK. I don't think that there are many people that have the ability to actually, or have had the opportunity to build a framework from scratch twice. And this is my second iteration. So I've learned a lot of lessons from building the first framework, trying to use it in my own startup, and then now I'm approaching it for the second framework. One of the things that I really wanted to make sure that we did was that we didn't hide anything away from you. The moment we did that as a framework, it made support much harder for us, because people wanted the optionality. But it also made it super hard to understand. So. For me, I wanted to get down to sort of the bare bones of what makes sense from a

• 6:28Speaker 01

  request slash response model, as well as what made sense from a TypeScript position. I didn't want to generate types. I wanted there to be no magic. And I've been thinking about this quite deeply, about why we ended up having frameworks that look the way they look right now. And I'm talking about Redwood JS. We had these things that were magic exports. Essentially, we created like a DSL for interacting with our framework. You export a special thing named this special name, and it would do something special within our framework. I think it's because people are trying to emulate Rails.

• 7:04Wes Bos?

  Yes.

• 7:05Speaker 01

  Rails, Ruby is a language that gives you the ability to define DSLs like off the bat. So there isn't much traceability in Rails. It's also just like, everything somehow works. Some of their imports, I don't know how exactly they put things together, but it's incredibly difficult for a newcomer to understand where everything is linked together in Rails. And you started seeing that in many JavaScript frameworks. So I wanted to take that away. One of the things I appreciate about JavaScript is the ability to follow where an import is coming from and where it's being used. So I didn't want to hide that from you. I wanted to make sure you could trace it. And I think the result is, it just feels so good.

• 7:46Wes Bos?

  Mm hmm. It feels so good to be able to just see where everything is. For example, anyone listening, when you want to declare a new route, you simply just go to your worker. TSX file, and you can like register, just like the old Express days, you can register a regular route that is simply returning a response. So I've talked a lot on the show about the like, the standardization of the web and very, two of the big ones are the request and the response, right? That's what fetch is built upon. And so much of the, so much of the modern web is built on the request and response. So being able to

• 8:31Wes Bos?

  simply just return a response object, or being able to

• 8:37Wes Bos?

  To return like JSX components, which may be pages. So having like explicit access to that seems really nice. I think it's probably a bit more typing. Would that be fair to say? A little bit more setup?

• 8:52Speaker 01

  Yeah, totally. I mean, we're not giving you sort of like return a redirect function. Or we're saying, hey, return new response with a redirect header. But you can create those yourself. We just didn't feel that we that's the surface area that we need to provide things for you. And you know what's wonderful about request and response is that if you're interacting with third-party services and you're returning a response, you can just stream the request directly back down to the browser. We've also enabled that via React server components. So you can take, like say, for instance, you're chatting to AI. You could send off a request to an LLM. It can return a response which is chunked by default. It's thinking, it's thinking, it's giving you

• 9:36Wes Bos?

  Yeah.

• 9:37Speaker 01

  Bits of information over time. You can take that and just return it straight down the wire into an RSE component and update the React component. And that feels so intuitive. You're just like, okay, there's nothing crazy going on here. It's the network. I'm dealing with the network and the browser APIs. I'm just sort of facilitating it in between. And a long, long time ago, I was a fan of saying this. Most web development is actually just trying to share memory from one computer to another in a safe way. And if you can make those easier, if you can facilitate that in a simple way, it just makes everything easier. So I think we've done that by just standardizing and request response. It feels like everything is possible.

• 10:20Speaker 01

  One of my favorite examples is actually uploading files to R2, which is Cloudflare's Ons to S3. You just stream it directly from, you take a file, a form data, attach a file to it, push it up to the web server, the web server catches the request and streams it directly into R2. Like, it's like three lines of code. I don't know if you've ever had to deal with chunks in a multipart form data thing.

• 10:45Wes Bos?

  It sucks, yeah.

• 10:46Speaker 01

  It's terrible. It's really bad.

• 10:48Wes Bos?

  Honestly, it's, it's one of the reasons why I, I love Node so much, or, or server JavaScript so much, is that, uh, like, Node used to have its own, or it still has its own streaming, but then they implemented regular streaming and just being able to use the same streams and request response on the client and on the server and is, is such a, a beautiful way to live. I'm a big fan of that.

• 11:15Speaker 01

  Having been a web developer for the past 20 years, I feel like this is the golden age. We are hitting a beautiful space and time in software development. And actually, you know, Redwood SDK is a response to generative AI by programming LLMs, because an LLM or, or, or an AI agent will assist you in the decisions you need to make whilst you're building software. But it will often lead you down a, a rabbit hole. It'll be like, alright, you need a database. Here's Neon, or here's Planetscale, or here's this other thing. And perhaps you don't know enough in order to make those decisions. So with Cloudflare, you just get that all, you just get everything.

• 11:55Speaker 01

  Just use the Cloudflare solution. You don't have to create, like, you don't install that service locally. You don't have to figure out how the API works. You don't have to create an account. You don't have to create, give them your credit card. You don't have to figure out how to ship it in production. There are like these taxes that you pay when you use external services. And you don't need to do any of that. You just focus on the software you want to write, rather than the infrastructure that it runs on.

• 12:20Wes Bos?

  And people are probably saying right now, like, well, Cloudflare is a service, uh, similar, similar to Neon. Why should somebody choose this where it only runs on, on Cloudflare? Like, why can't you make this just like Node.js or, or server JavaScript agnostic?

• 12:39Speaker 01

  So for us, the really interesting part about building software is putting it in front of people, getting your idea from start to finish as quickly as possible through the gate and not having to worry about the infrastructure. To me, you're not building a product when you're dealing with that stuff. And that's if you're someone that resonates with that idea, you want to build stuff, you want to ship your ideas as quickly as possible and not have to worry about the infrastructure that's hosted on. Redwood SDK is probably going to resonate with you. I, however, see Cloudflare as rather as AWS than I see it as a Versal, for instance. It's a hosting provider. Certainly, there

• 13:23Speaker 01

  is lock-in there and we have to own that. Cloudflare gives you a lot of things that a lot of other hosting providers can't, specifically durable objects and the tight integrations with all their with all their services. It's world-class. I I'm unashamedly in love with Cloudflare.

• 13:43Wes Bos?

  Yeah, yeah, honestly, people give me heck. Sometimes I think I'm like, like taking money from them or something like that. But like, no, I'm just I'm enthusiastic user, you know, they don't they don't even I get free hosting accounts from everybody and except for Cloudflare. I pay my own way on Cloudflare. So that should say something. But like, let's talk about like, like database as well. So if you're using D1, it's a relational database, kind of, or built on top of SQLite.

• 14:15Speaker 01

  Yeah.

• 14:16Wes Bos?

  So if you're interacting with that, you're not using like the Cloudflare SDK, you're using like what, like Prisma or Drizzle or something like that. What's the database look like in Redwood SDK?

• 14:30Speaker 01

  So we give you a standard starter. And for that standard starter, we give you Prisma. So we decided that that was probably the best DX that we could that that worked for us. But you're connecting through Prisma to D1 and you're just running standard migrations. Although, there are some problems with Prisma right now when it comes to migrations. So we've created scripts that work around that. And they are addressing it. And Prisma has some Issues with their large binary, they have this Wasm that's almost like a meg in size. And they are reducing that, they're taking that out and they're just making it pure TypeScript. So at the end of the day, things are just going to get better from that perspective.

• 15:11Speaker 01

  But we also have a starter where you can just use Drizzle or any of the RMs that are your decision, or you can just directly connect to D1 as you wish, but you don't have to use D1.

• 15:23Wes Bos?

  SQL queries. Yeah, you don't, you don't even have to use that, right? You could connect to anything.

• 15:27Speaker 01

  Yeah. And I mean, then in that case, if you're just connecting to Postgres or MySQL, it's an external service, then Cloudflare can also help you make that super fast. They have these, I don't know what the, I don't know what that product is called, but they have like a proxy or something that.

• 15:43Wes Bos?

  Yeah, it's called a hyper, hyperdrive, I think. Let me check that. Cloudflare, hyper, hyperdrive, yeah. And what that does, it, because Cloudflare is like serverless, I'm using air quotes here. They don't like when you use that word, but it will have a fat pipe to your actual, where your database is. That's, that's a big source of latency for a lot of people, where your database and your code are not in the same spot. Or if you have to do connection pooling and all those fun things that come along with.

• 16:16Speaker 01

  That actually made me think of something that we do. So we follow the request response model. So if you're, if you want to log in a user, you create cookies and that user data is stored in something that we call a session. That session is backed up in Redwood SDK by something called a durable object. So a durable object, I actually, I don't think anyone really knows what a durable object is, but I'm going to describe it as best as I understand it. A durable object is basically another compute instance that lives alongside your existing compute instance. But they're, they are logically separated. So in case of Cloudflare, they have this thing called smart placement, where you can place a durable object closer to the user and the worker closer to your database.

• 17:01Speaker 01

  The result is that it reduces latency overall and they will figure that out automatically. Did that make sense?

• 17:08Wes Bos?

  Yeah, yeah, absolutely. They figure out where to put it because like a durable object is backed by D1 and that database needs to live somewhere, right? And they will try to do their best at figuring out where it will actually live. We did a whole show on durable objects as well, where we distilled it down to like durable objects are essentially JavaScript classes that can maintain state and they don't go away because that's always one of the downsides to using serverless versus like a long running thing is that you don't have memory, you don't have places to keep stuff in between requests because they spin down.

• 17:54Speaker 01

  Such good tech.

• 17:55Wes Bos?

  Yes, I'm a big fan of durable objects as well. And I know there's several people working on like an open source version of it, just kind of cloning the API. So that's if anyone's worried about like locking with that type of thing, I don't think that would be too big of an issue.

• 18:13Speaker 01

  That's cool.

• 18:14Wes Bos?

  middleware. Let's talk about that. So like Redwood SDK has like proper middleware, meaning that you can you can step in and stop things and set headers and all that stuff.

• 18:29Speaker 01

  Totally, yeah. So the entry point for your app is a function called defineApp. And at the top of that file, you can define as many pieces of middleware as you want. And the middleware is just a piece, a function that gets the request and the context. And you can modify the context or return a response in there. And then it gets handed off to the root handlers. And once it matches a root handler, and then we'll call a request handler. But we have this concept that we call interruptors. Essentially, any root can take an array of request handlers. So a good example is that you can then use to interrupt the flow of the of the request. So a good example is, say, for instance, you wanted to do authentication.

• 19:12Speaker 01

  Typically, you'd have a function that checks if a user is logged in or they have certain privileges. And then you allow them to proceed to the page. So with an interrupter, you can create this function is authenticated. You can check the session to see if they are logged in. And if they aren't, you just return a response that says, hey, you don't have permission to do this. You've now interrupted the request flow. If you don't do that part, it will proceed to the next handler and then it will show you the page. So you can kind of like take these functions, you can share them with your code base. You're like, this is how I check if people are logged in. It's a single function.

• 19:47Wes Bos?

  Yeah.

• 19:48Speaker 01

  And what's really nice about that is when you read the code, when you parse the code, you can see what's happening. You don't have to like dig into each request handler and say, okay, we're actually checking if they're all authorized and they have the correct things. It's just this little nugget that you attach to the request handler. And it makes it really easy to read and share that functionality. Those are the two layers of middleware. The one is like global and the other one is more per route.

• 20:13Wes Bos?

  Oh, that's, that's interesting because in NextJS, they started with like a, like a global middleware. And then they moved it to like a, like a per route middleware. And I, I was never happy with, with either of those. And then the middleware also had a bunch of limitations as to what you could do with it. And whether you like middleware or not, I'm a, I'm a huge fan of it. And my applications, I'm coming, I grew up on Express, you know, I have lots of, of middleware. Uh, so it's nice to be able to, to have the, the full control over that.

• 20:46Speaker 01

  So talking about full control, I like to say that we give you control over every byte that passes over the wire. And what I mean by that is that when you render out some, some JSX or you, when you return a React page, it's usually mounted in like a document, an HTML document that has like a head, a title, a body, like a div, things like that. You know, the structure of your page. Redwood SDK gives you the ability to define that as just another component. And you then give it a method called render. So you say, hey, render this document for these routes. And you can do that for, like, you can have a different document based on a route. Say for instance, you had a blog, a, a section in your website that was just blogs.

• 21:30Speaker 01

  You could remove the client side hydration from that document and you would just serve HTML. There would be no JavaScript going over the wire. And then if you had like an app side to your website, you then just include client side hydration and then you have interactivity. And then you're getting JavaScript and React and all the stuff with that. And say, for instance, you wanted real time, like you had a dashboard that was, that required something to update consistently, or you wanted people to do multiplayer stuff. You switch out the client side hydration with our real time client side hydration. So you really have the ability to ship like many multiple apps within the same worker. And a typical use case for that is like when you have a marketing site

• 22:12Speaker 01

  and the marketing site has like this button that's meant to tell you whether you're logged in or not. And then you click that button and you always see, it would be like login and then it flips. And it's like, nope, you are logged in, click this button.

• 22:25Wes Bos?

  Yeah.

• 22:26Speaker 01

  So we can just take that away. We just send HTML down the wire because we know if you're logged in or not. We handled it in the request and then you click that button. Then all of a sudden you get in all the JavaScript that you need.

• 22:36Wes Bos?

  Oh, and another use case for that is you can like break out of layouts, right?

• 22:42Speaker 01

  Totally.

• 22:42Wes Bos?

  So like one, one problem we have, both my personal website and the syntax website is we have like a, an Open Graph image page where we want to render out not the website, not the header, not the footer, you know, not the whole layout. And in order to like break out of the layout, we have to do this weird like folder based structure with like parentheses on it and whatnot.

• 23:06Speaker 01

  Yeah.

• 23:07Wes Bos?

  Which it's, we can get around it, but it is, it is kind of funky.

• 23:11Speaker 01

  It doesn't feel nice.

• 23:13Wes Bos?

  No. So talking about reading though, one thing that I noticed that there's no client side router, is that true?

• 23:21Speaker 01

  There isn't, but you can add one since you control the, you control the ability to initialize the client side stuff, you can add one.

• 23:29Wes Bos?

  Yeah.

• 23:29Speaker 01

  And actually I have an early experiment where I took control of the browser's navigation events. And I would actually go fetch the pages from RSC. So I'd, I'd have an RSC endpoint that I could hit. I returned the flight data and I just replaced the constraints using like the inject stuff in, in, in React. So we might provide one that gives you that SPA feeling.

• 23:53Wes Bos?

  Yeah.

• 23:53Speaker 01

  But it will be very bare bones, kind of take the same principles that we currently have that. You have full control over it, but it just facilitates what the browser offers you as an API.

• 24:05Wes Bos?

  Okay, so if I want to build, like I'm thinking like if I want to build like a full stack app, I'm gonna need like a 10 stack router or React routers, I'm gonna have to bring that in myself. How does that work in relation to the, I guess, the define app? It's like the server router where you can, you set all of your middlewares and whatnot. Now, now is there two separate things?

• 24:31Speaker 01

  No, it will be the same app. So define app can take multiple render methods.

• 24:38Wes Bos?

  Yeah.

• 24:39Speaker 01

  And those multiple render methods can describe different documents. And that the document just can describe how navigation works. So the initial response will include the fact that you're logged in and set the cookies and all that other stuff. And then subsequent requests will still go through the middleware, probably hit like an API route. It'll just work. I should, I should

• 25:00Wes Bos?

  Okay.

• 25:00Speaker 01

  Create an example because I, it's kind of vague in my, in my words because it's vague in my head. But it is possible.

• 25:08Wes Bos?

  And, and you'd still be able to set up like, let's say I'm moving from my blog to my about page. What I would hope would be that like there's a React server component payload for that page. That's, that's set back. Am I, you're able to do that?

• 25:25Speaker 01

  Yeah, yeah, totally.

• 25:27Wes Bos?

  Okay.

• 25:27Speaker 01

  Entirely possible. It'll either just be the payload that then gets rendered hydrated as HTML. But if it, if it has client side interactivity, then you'll get all that stuff. All the, all the rest of the modules with it. No, I was gonna say, where are the downsides? I was gonna say there are none.

• 25:45Speaker 01

  You know, the thing is, we had to start from scratch to do this. We couldn't take what we had and build it on top of there. And I think it's rare that people can do that. So I feel privileged to be able to bring this to people and say, hey, I've learned some things. Here they are. Try them out.

• 26:04Wes Bos?

  Yeah, yeah, totally. Plus, like, you've been able to sort of sit and watch like what what's been happening with React server components over the last, what, like, three years or so?

• 26:15Speaker 01

  Yeah.

• 26:16Wes Bos?

  And see how the issues people have hit and the pains they've had. Is there anything around that that you've you've made?

• 26:24Speaker 01

  So, I mean, we implement pretty stock standard React server components, like the default experience is the one that we are providing, despite the fact that we have like this this way to stream chunk responses from a server action. That's one thing that we brought to the table. Like, our real time actually plays along quite nicely with React server components. So say, for instance, me and you go to a page and there's a server action on this page and we have we have the real time functionality instantiated. If I perform a server action that updates the UI and me and you are on the same page or key, you will get that update automatically. So that's not an explicit behavior, but it's one that you can opt into.

• 27:08Speaker 01

  So like React server components, if they update state, the server is the state, all the clients that are connected to that server receive the updates for free.

• 27:16Wes Bos?

  Oh, man.

• 27:17Speaker 01

  It feels really nice. It kind of like the mentally it makes sense. You're like, oh, yeah, of course. Because that's how React actually works in the background. When you push up a server action, you get the full payload back and then it dips it. So we're just doing that exact same thing for everyone that's connected to the same channel. We broadcast the whole thing.

• 27:36Wes Bos?

  That's cool. That's I I've been playing with like PartyKit quite a bit as well, which is like a real time thing built on top of durable objects. But you're saying that this maybe even I don't it doesn't take it further, but like this is the implementation where it's just standard React server component data, but it's also live?

• 27:59Speaker 01

  Yeah, exactly.

• 28:00Wes Bos?

  Oh, man. That's so if I were to if I were to have like a like a server component where I I queried some data and I put that data in my a client component, I would assume, then it would be and then somebody else were to update that data, then it would just immediately be real time. Yeah, that's cool.

• 28:20Speaker 01

  Yeah, yeah. And that update is coming from the server, the source of truth.

• 28:25Wes Bos?

  Building applications and thinking like, what if everything was real time? You know, like you, you, you could, uh, like literally with enough

• 28:35Speaker 01

  With durable objects, you could.

• 28:36Wes Bos?

  Yeah.

• 28:38Speaker 01

  And it will scale. I mean, they say it scales infinitely, so put it to the test.

• 28:43Wes Bos?

  Yeah, yeah, we'll, we'll have to see. I've, I've built quite a few things with durable objects and it's amazing.

• 28:50Speaker 01

  It really is.

• 28:51Wes Bos?

  How simple and good it actually is. Like I, I had this little LED grid and I built a little app where you could draw in the browser. And then it immediately was just mirroring it right to the LED grid and

• 29:03Speaker 01

  That's cool. Wow.

• 29:04Wes Bos?

  Yeah, it's, it's really nifty.

• 29:06Speaker 01

  Was that with an ESP32 or something?

• 29:09Wes Bos?

  Yeah, yeah. ESP32 hooked up to a 16 by 16 matrix, something like that. I need to finish it as well. But I was just looking for a, an example of to, to use Party Kit in real time.

• 29:24Speaker 01

  Super cool.

• 29:24Wes Bos?

  Yeah.

• 29:25Speaker 01

  Yeah. Like Sunil is, he works at Cloudflare now and he was actually the first person that I showed this to. We both had startups around about the same time and I kind of leaned on him a little bit for emotional support. And now I still do for, for emotional support, but just to cheerlead what we're doing. And he's so great.

• 29:46Wes Bos?

  Yeah.

• 29:47Speaker 01

  He was like, dude, I need real time react. And I was like, okay, I'm gonna make it happen.

• 29:53Wes Bos?

  So what happens to the old Redwood or like what Red, what we used to know as Redwood JS?

• 30:00Speaker 01

  So we've renamed Redwood JS to Redwood GraphQL and we're trying to give it the same treatment that we're doing to Redwood SDK, which is to say that we're unbundling all the major packages that were shipped with it. So that the users who are still using Redwood GraphQL can just take V plugins, take the ecosystem as it stands and control their own destiny. And we'll still maintain security patches and bug fixes for the core of it. So that the people who are still using it still have a good experience, but one that they can run and own themselves. I'm cognizant of, you know, that that was my, that was my baby. That's the thing I'm super proud of.

• 30:42Speaker 01

  It's not every day that a, a boy from South Africa gets to build a framework with Tom Preston Warner. I still somehow can't believe that happened to me. But I'm really proud of that work there and I'm really proud to take on the legacy of, of what we built and, and, you know, try and make it spread in the world. We, we just couldn't make Redwood Graphical happen, or Redwood JAS happen. It just didn't, it didn't find a solid footing in the market. And I'm, I'm here to change that.

• 31:14Wes Bos?

  Why do you think that was? Cause I am constantly shocked that nothing that is trying to be the Laravel or the Ruby on Rails of JavaScript has, has caught on. And I, I often joke, we're like, yeah, I want, I want something that's opinionated as long as it's my opinions at the moment.

• 31:35Speaker 01

  If I think about it in my own philosophy, I think the really hard part about building software is not actually writing code. It's gluing together services. And you would feel that like when you were trying to integrate Storybook or, you know, like one package and another. But it got really hard when you tried to ship to production. That's when things started to suck and your hosting provider just could not help you. Then you had to go and search for another queue library. And, and you know, that fatigue of trying to figure out what works best for the thing you're trying to build makes building software worse. And I think, you know, Redwood was built upon that concept.

• 32:16Speaker 01

  It's like, we'll integrate with this, we'll integrate with that, we'll give you this auth provider. We had, I think we have like 18 auth providers. So we didn't actually take your decision fatigue away. We just kind of made it possible. And I think we could have been more opinionated. I think I think a framework requires a platform. I know that might be a little controversial, but I think it just makes software development easier and better if the platform is right alongside the framework.

• 32:46Wes Bos?

  You mean like a platform, like an infrastructure platform?

• 32:50Speaker 01

  Yeah, I mean, like a Cloudflare or a Superbase or something along those lines.

• 32:55Wes Bos?

  Totally. And quite honestly, that's, that's why NextJS is so popular, right? Like, Versal made it extremely easy to deploy and to write the software and it just, it just works. And I don't think that NextJS would be as popular if you had to go and host it yourself somewhere, you know, that's just not, and it happened with WordPress as well. The reason why people love WordPress is that, like, somebody DM'd me the other night, they're like, I don't want to use WordPress, but there's literally nothing else that is that cheap and easy to deploy somewhere else. And it's, it's not a problem

• 33:36Wes Bos?

  of the software. It's, it's literally an infrastructure thing where these, these GoDaddies and BlueHosts have, have made it so easy to deploy these things and, and the software has really benefited from it.

• 33:51Speaker 01

  Totally. And, you know, I think we were a little bit too early with RedRJIS. We kind of saw Netlify, they released these Lambdas that were based on AWS's infrastructure. And we were excited about that. And we had this idea that those things would just continue improving over time. And they didn't, they just didn't. And they had some really, really big restrictions that we didn't fully appreciate at the time, or didn't accept that they would stay that way. And Cloudflare, I think, has become the answer to those things. I mean, like you said, they don't like to call it serverless, but it feels that way. It feels like you're.

• 34:32Speaker 01

  You're running a serverless function in the cloud.

• 34:35Wes Bos?

  What were those limitations?

• 34:39Speaker 01

  Cold start times?

• 34:41Wes Bos?

  Okay.

• 34:41Speaker 01

  There was a limitation on how much JavaScript you could actually put inside of them. And there was execution runtime limit. I think it was quite short as well, maybe 10 seconds, which is pretty long. But when you're pushing up like a massive JavaScript file to the server that isn't performing as well as you should, I think it should, or you have a slow connection to your database, then you have issues. And you know, like connection pools were really a problem for us as well. Cause you'd fire up like tons of Lambdas. Every request was a new Lambda if it was occupied, which would be a new connection to the database. You had to put a connection pool in front of it. Yeah, it was, we learned a lot there.

• 35:24Wes Bos?

  And for anyone listening, CloudFlare uses what's called like wall time. And this idea is starting to catch on with other providers as well. But, sorry, it's not wall time, it's compute time. The wall time is like 10 seconds. Yeah, you're waiting for a response. And especially with all this AI streaming stuff where, I don't know, you're waiting five seconds for a response to come back. You're paying for that, whereas compute time, you're only actually paying for like the, the actual compute. You're not, while you're waiting on I O, you're waiting for a fetch request, you're not paying for that, right?

• 36:03Speaker 01

  Like, I mean, this is the wonderful thing about them being a network company. I always say that CloudFlare is a network company first. They can do that. Like who can do that? Very few people.

• 36:14Wes Bos?

  Yeah, yeah, that's, that's true. I want to touch upon like node compat really quickly. Like limitations of CloudFlare are that they're not running node JS, right? They're running their own thing called, called Worker D. That's their own JavaScript runtime.

• 36:32Speaker 01

  Yeah.

• 36:32Wes Bos?

  And they have shims and polyfills and there's this thing called unJS. And they try to make like 98% of node JS.

• 36:43Wes Bos?

  Compatible because at the end of the day, you sometimes just want to grab a node package and use it. Are there any limitations or issues you've hit with that?

• 36:52Speaker 01

  So I haven't hit that issue myself. I do understand that it is something that can be a problem. And that's why we actually both read with SDK within Worker D. We were like, let's figure out where this isn't going to work. But we haven't hit any issues where it has been a problem.

• 37:10Wes Bos?

  There's little things that pop up every now and then, like there's several HTTP things that are not totally implemented. But as packages move towards more standards, like a big one was like Axios for the longest time didn't have a, they used XML HTTP request. I forget what it was, but basically they didn't have like a fetch implementation under the hood.

• 37:34Speaker 01

  Like an iframe?

• 37:36Wes Bos?

  Yeah, it was weird, but they, I think with Axios seven, they rolled out a fetch adapter, meaning that if you use it on Cloudflare, it will realize that there's no XML HTTP requests on Cloudflare. So they use fetch, which is, is good at the end of the day. So I haven't hit too many things where I don't have to sort of work around them. It's, it's become much less of an issue as packages get better and as the, the shims are getting better.

• 38:08Speaker 01

  Totally. And I see they're, they're constantly trying to become more and more and more compatible. And based of using their platform, and I'm going to sound like an absolute fanboy here, based of using their platform and seeing how solid their engineering is, I think that they're probably one of the teams that can pull it off. I have pulled it off. Yeah, I'm, I'm actually in awe of Cloudflare. I'm, I'm really impressed by the fact that most of the time it just works. It's one command, it releases to production, throw an env in the front of it, it releases to staging. It's like.

• 38:43Speaker 01

  It feels like I'm FTPing a PHP file into a server. It's so good.

• 38:46Wes Bos?

  Yeah, it's really quick. Like, I moved my, when I moved to Waku, my build times went from like 10 minutes down to like, I'm at like 2 minutes right now. And then now V is about to get really fast, even faster with Roll Down, Roll Up, whatever the new one is. It's like Rust-based bundler, and I think it's Roll Up. Anyways, whatever the new one is. So maybe it will even get faster. Evan Yu has been tweeting out all the stats of like, some of these like, 4-minute build times go down to 20 seconds. So I'm, I'm pretty excited about that.

• 39:27Wes Bos?

  Like, the fact that you will be able to just make an edit to your website and it to be live in 30 seconds is gonna be amazing.

• 39:38Speaker 01

  And I mean, I do that. I know we shouldn't. I know that I should go through CI and should have tests and things like that. I know that process.

• 39:47Wes Bos?

  No.

• 39:47Speaker 01

  Yeah. So, but I just ship to production. I just run it directly from our production. Actually, our website, rw-stk.com, is a React SDK website, and I ship fixes to it constantly using that method. It's so good.

• 40:04Wes Bos?

  Oh, well, you know what I do. I'll do a little, a little ad read for Sentry here right now is, uh, no tests, just, just throw Sentry on there and then I go onto the dashboard and see what, what errors are piling up and I'll go fix those and whatnot. So if you do want to check out Sentry, it works on cloud for great. You go to sentry.io/syntax. One more thing, real quick. May 29th, Denver, Colorado. We're doing a syntax meetup. You gotta be there if you're anywhere within a horse ride of Denver, Colorado. We got the folks from Vercel, the folks from Mux, folks from Sentry. We're all coming out, of course. We're gonna have Scott there. CJ's gonna be there. I'm gonna be there. It's gonna be a really great time.

• 40:48Wes Bos?

  If you want to grab some tickets, they're free, but you gotta get tickets. Go to syntax.fm/meetup.

• 40:54Speaker 01

  I love Sentry.

• 40:56Wes Bos?

  Yeah, it's really, it's a great, great product for figuring out what went wrong.

• 41:01Speaker 01

  I see that David Kramer was actually having a look at a whole bunch of JavaScript frameworks. And I think that's actually how we got into touch with one another because I was shamelessly plugging Redwood SDK in his, in his, in his timeline. And I was like, that thing that you just complained about, we fixed it. But he hasn't responded yet. So if he listens to the show, Zeke, please hit me up. I'll show you the light.

• 41:31Wes Bos?

  Oh, man. Yeah.

• 41:32Speaker 01

  Please criticize me.

• 41:36Wes Bos?

  He'll, he'll find some stuff. He'll give it a good run. He's really good at that. So yeah, I'll, I'll ping him about it as well. Anything else we haven't touched upon about, about this stuff?

• 41:48Speaker 01

  Yeah. So, you know, I actually think a little bit of the vibe of what we're trying to achieve with the framework is like, I was born in the eighties and I grew up in sort of like the personal computing revolution, you know, Mac and PC competing for people, the internet coming out. And there was this sense of wonder and awe at this ability to create software. I use software to impress my friends and I could do that because it was easy enough for me to understand. And I had like really cheap hosts and I could just FTP it up and things like that. I think that we, with, with, with the advent of AI are going to see a whole bunch of people that previously couldn't build software come

• 42:30Speaker 01

  back to the, come to that skill. And I think they need a really good cloud or really good, good platform to host on and really good tooling that is easy to follow and LLM can reason about that follows web standards. And that's partly why we built Redwood, Redwood SDK. We have this thing. On our website called Personal Software. And we think that people, when people build software using vibe tools or generative AI, there doesn't necessarily have to be a profit motive. There doesn't have to be a brand. There doesn't have to be support metrics and things like that. You just need an itch to scratch and a problem to solve for yourself, your friends or your community.

• 43:14Speaker 01

  And it feels like that's the dream of what software was meant to be. It wasn't necessarily just about money. Money's great. I need it and I want it. But I can see in my communities that there are things I can solve with software really easily. I usually don't do it because it's too painful. But now I could just generate a lot of my code and I can host it super easily. It's not going to cost me any money. There's power in that. There's power in that, like, just this ability to solve problems using my skills.

• 43:44Wes Bos?

  Yeah.

• 43:44Speaker 01

  So I'm excited for the future.

• 43:47Wes Bos?

  And on that, the Redwood Starter comes with some like cursor rules, which is, I thought was really interesting as well to sort of feed it. I guess best practices and whatnot, or maybe this is just the prompt? What is this?

• 44:02Speaker 01

  No, no, yeah. And we're actually building an MCP server as well, that if you

• 44:07Wes Bos?

  Oh, awesome.

• 44:08Speaker 01

  Ask an agent some stuff, it will understand how to do that in Redwood SDK. It'll exit the ala as quickly as possible and just do it programmatically. Like I say, for instance, create a route that has a, create a route called Ping. And it will just make that for you using TSMorph instead of the ala. So it ends up being cheaper. It understands what to do and a little bit, it'll be a little bit faster. What we want to do is provide really good tools to AI agents so that they understand what the framework is trying to do. So we're trying to be a really good steward in the age of AI. Not necessarily build an AI interface to vibe hack or I think that that market is really hard,

• 44:51Speaker 01

  really difficult to compete in right now, so.

• 44:54Wes Bos?

  Yeah, no kidding. And like, where's it at right now? Like, can somebody go and start building their, their next personal software or startup on this thing? Or you just released it a couple of days ago?

• 45:06Speaker 01

  Well, it's been out for about a month. We've been working on it for five months.

• 45:10Wes Bos?

  Okay.

• 45:11Speaker 01

  But we publicly let people know because the redwood JS, the original framework, it was becoming a little bit quiet. So we let people know that we were working on something new. And the week after that, we let them know on the Friday, the week after that was CloudFlare's Developer Week. And we just got pulled into that and things started rolling. So from then on, we've kind of said that it's production ready. We have a whole bunch of apps in production. We are constantly fixing, but we'll hit 1.0 really soon. I'm thinking like two weeks' time. I know that there's people on the team that are going to be like, no.

• 45:48Wes Bos?

  Shouldn't have said that yet.

• 45:51Speaker 01

  But that's my gut feeling is that we solved so many things in the past three weeks. We rely on the web APIs. So the surface area of the framework itself is really not that many lines of code. There is a lot of heavy lifting happening in the browser and in CloudFlare.

• 46:08Wes Bos?

  Beautiful. Well, thank you so much for dropping everything and coming on here to talk about this. I'm pretty excited about it and I'm excited to see what people build on it. So next app I need to build, I'm certainly going to use this as my base.

• 46:23Speaker 01

  Perfect, thank you. And if you've come across anything that doesn't work for you in the way that you expected or isn't described in a way that makes sense to you, please let us know. I create content around that and that's what's going to help me improve the framework for everyone.

• 46:38Wes Bos?

  Will do. All right. Thanks again for all your time. Appreciate it and I'll let you go to bed now. Thanks.