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
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.
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•1h ago
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
vends•1h 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.
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•48m ago
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