Rendered at 21:11:23 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
pistoriusp 6 hours ago [-]
Hey everyone, Peter here. I'm one of the humans behind RedwoodSDK.
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.
Congrats on the launch! While the focus is on humans, I found many of the principles here to be very relevant for building with AI.
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?
pistoriusp 5 hours ago [-]
> 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.
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.
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
pistoriusp 57 minutes ago [-]
Love that you're here, thanks!
digitalgnist 5 hours ago [-]
I used this framework in a university lecture while teaching web applications. The main reasons for choosing it were its simplicity, adherence to web standards, and how easy it is for students to grasp. When used together with Cloudflare, you also get a lot of batteries included out of the box.
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.
pistoriusp 57 minutes ago [-]
So happy that we have the opportunity to give those students fundamental web development knowledge.
kltwrds 5 hours ago [-]
i've built web apps w/ a few different full-stack frameworks -- EmberJS+REST, Python/DRF, Node/React/GraphQL, Heroku, AWS, GCP...each had its own flavour of incidental complexity. now i'm using rwsdk+cloudflare for my latest b2b web app venture, and i have to say the DX has been amazing. no heavy handed frameworks to wrestle with, and the "web primitives" play really nicely with coding agents. it just works.
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.
pistoriusp 55 minutes ago [-]
The big focus will be ensuring that you're not stuck on our implementation of RSC (we wrote a custom vite plugin); so we'll be moving over to the version from the Vite team.
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.
chrsnyman 5 hours ago [-]
As somebody that dabbles in dev between the chaos of life, I found rwsdk super easy to use I've tried sooo many different frameworks in the past and this just works... effortlessly. Freaking delightful! Good job!
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.
https://github.com/redwoodjs/sdk/pull/969
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
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.