This is the second time I’ve built this framework.
The first version was a collaboration with Tom Preston-Werner. When Tom asked me to become the steward of RedwoodJS, I realized we had a massive opportunity to take what we’d started and make it bulletproof.
I brought my experience from my own startup to the table, specifically the scars , to ensure this version allowed you to iterate rapidly.
Here's the journey: https://rwsdk.com/blog/redwood-v1-getting-out-of-the-weeds
With LLMs able to generate the "magic" with ease, I can see the role of frameworks shifting a bit. Instead of hiding complexity, it's surely more beneficial to expose the primitives clearly enough that both you and an LLM can follow the request lifecycle.
The bet on Cloudflare is pretty bold, but it does make sense given how unique their products like DO and Workers are. I suppose there's not much of an escape hatch if you ever needed one?
100%.
I kinda feel like we've fooled ourselves into creating these domain specific languages for frameworks, where we glue things together using magic, and just dealing with the features of the language, the browser and the network make a lot of sense in the AI world. And our framework is actually much less complicated than I think a lot of them are...
> I suppose there's not much of an escape hatch if you ever needed one?
I of course don't want to be vendor locked in, so I've started working on something called open durable objects, and I have a concept for something called open bindings.
these are the two core technical solutions that the framework really needs from Cloudflare. This does not include durability in the same way you get it from Cloudflare: it will run on a single machine.
This runs on both bun and node.
And now with v1 there are some really logical patterns that I really enjoy.
Like returning Responses from server actions and then the framework automatically handles things like redirecting. https://docs.rwsdk.com/core/react-server-components/#returni...
Like it always felt a bit like a hack needing to add a client component to handle redirects after submitting a form. But RWSDK gives a pretty elegant solution.
And that's just one of many intuitive features of RWSDK. I also like the `useSyncedState` hook they made that makes it very trivial to make real time communication between clients, for something like say, a chat room. https://docs.rwsdk.com/experimental/realtime/
I also dogfooded a reporter I've been working on with the initial v0 tutorial for this. Which then I rewrote that tutorial to demonstrate TDD principles for the v1-beta (to my knowledge there are no breaking changes between v1-beta and the final release, but I'll be going through later to confirm that.) https://www.test2doc.com/docs/tutorial-1
Now with RedwoodSDK I get the absolute easiest way to spin up a production-ready RSC app. Especially true if I don’t want to be on Vercel (I have loved Vercel’s value prop. Many old apps of mine actually still use their pro tier.)
I had already started to move pieces of apps to Cloudflare as their offerings and free tier felt insane not to take advantage of. Cloudflare as a platform has been awesome for me:
~They have awesomely linear cost scaling. I don’t have to have mini apps to figure out when I cross tiers of usage to the same degree.
~I get a world-class CDN just there by default.
~Cloudflare charges a lot of things at a more base level which is getting more common now, but basically charging execution time not duration the worker was waiting around.
~R2, the S3 equivalent, has no egress fees so easy buy in.
~Cloudflare is already public with the infra layer there so less rug-pull fear.
~Durable Objects make stateful coordination and atomic colocation of data&compute near a user suuuuuper easy.
Then RWSDK glues it together in a way that is super AI friendly, extensible, easy to reason about because it’s just sortve handing off the req res to RSC.
I’ve almost been calling it the frameworkless framework because it just lets me do Typescript RSC. The magic is the no magic. My code does my code without crazy wiring behind curtains.
I’ve ended up with maxing lighthouse scores, deleting massive chunks of code, better seo from SSR, and feeling like I own my code. AI does amazing because then it is just writing TS functions or classes or RSC code, or Cloudflare has had pretty stable APIs / it is easy to put a few docs examples in. No making sure the AI keeps up with the new cache directive haha. (Once again I love a Vercel’s offerings, but I also love being able to surface level reason about what is happening 100% of the way through my code because of RWSDK).
I have had apps running with this for what must be a year now so can attest to stability. All problems have been me problems haha, or they were quickly rectified with awesome team.
Teaching the basics was also simpler than with Next. Next has evolved to include many abstractions, features, and tools, which often means the teaching quickly becomes centered around the Next way of building things.
Being able to use RSC in a simple way alongside APIs was also very nice. I’m used to using Hono and really enjoy working with it, but having the best of both worlds through the SDK was great.
And not to mention the realtime features. This was a little cumbersome to get started with, but once set up it became simple to work with.
Working with the SDK in the 0.1 version created some friction for students, but it also became part of the learning process. It was also great to be able to contribute, give feedback to the core team, and gather feedback from students that could help further develop this amazing framework.
i'd be curious to know where the framework is headed next? seems like nextjs/vercel has a legitimate up and coming competitor in rwsdk.
It's not that we think our implementation is worse, it's just that we don't want you to be locked into our framework.
We will also launch something like ActiveRecord and a Convex like experience.