I created and named the Grit library that used to power GitHub. Scott Chacon (fellow GitHub cofounder, now CEO of GitButler) specifically asked my permission to re-use Grit as the name of this project, which I gladly granted. R is for Ruby. R is for Rust! Grit is dead. Long live Grit!
With Claude Code's new lifecycle hooks, GitButler auto-sorts simultaneous AI coding into separate branches. Write three features, get three clean branches.
Hey, Tom Preston-Werner, co-creator of RedwoodJS here. We've been working hard on React Server Components support in RedwoodJS and really happy to finally have a bare-bones working implementation ready!
Redwood is a framework for quickly creating React-based web applications that provide an amazing end user experience. Our goal is to be simple and approachable enough for use in prototypes and hackathons, but performant and comprehensive enough to evolve into your next startup.
Until now we've focused on SPAs with GraphQL for data fetching. But this new era of RSCs allows us to offer a streamlined data fetching model that helps you iterate much faster. We still offer first class GraphQL API tooling for when you need it, but it's an optional add-on.
Thanks, Orta! I'm especially keen to get money in the hands of under-represented developers that would otherwise not have a chance to spend time on getting a startup off the ground. Hopefully we can be first money in at a time that truly makes a difference in whether a startup exists or not!
Tom Preston-Werner here, I'm behind the Redwood Startup Fund as an extension of my work on RedwoodJS. I also do a lot of angel investing, and this fund finally combines my great loves of Redwood and investing! I'm happy to answer any questions you may have about the $1M fund and how we expect to deploy it over the coming twelve months.
Right now there is no business model, on purpose. This is why I'm personally supporting it. I think what David meant is that we are sustainable because I am committed to sustaining the project. Our goal is to find a properly sustainable model in the future that meshes well with our mission and ambition. It will be exciting to figure that out!
It is unusual, perhaps, but as Redwood has evolved, it's been natural for us to really offer support for startups using our tools. Redwood is a more complex, more integrated, and more aligned with long term maintainability than most of the alternatives, which means our market focus is on projects that need that kind of tooling. And who needs that tooling most? Startups! Plus, I do a lot of angel investing and so helping startups is of great interest to me, so I can combine my great loves!
These were state of the art tools when we started work on Redwood more than two years ago. We're investigating other more modern alternatives, but swapping them out is a finicky and time consuming project and we've been focused on primary features. We will keep evaluating our dependencies and you may see some changes in v2!
RedwoodJS has been about long term maintainability from the very beginning. This is part of why we chose GraphQL as a core component. It's more complex at first, but in the long run it gives you multi-client capabilities without rewriting your backend, and provides excellent separation of concerns. We still try to make Redwood as easy to get started with as possible, but in the tradeoff between "quick bootstrapping" and "long term maintainability", we tend to choose the latter.
> As far as I know Redwood has no server-side rendering solution.
SSR is priority number one for v2. In the meantime, a number of users use Next.js as a client that talks GraphQL to the Redwood backend. It works very well!
> there is actual financial backing for Next.js
Today I announced I will be providing $1M of funding for future RedwoodJS framework development this year, so now we have funding too. =)
The truth is, we can both succeed at the same time, there are so many great app ideas waiting to be explored, and different tools will work better for different situations!
Thanks! Our mission is to help more startups explore more territory, more quickly. We're hoping to achieve this by integrating all the bits you need up front so you have less work to do on your framework, and can spend your precious time building and scaling your app or startup!
You are correct, if you're not careful with your data fetching you can get into a waterfall situation. This is something we're keen to address in coming versions. Because we can get in the middle of your data fetching flow if you use cells, we should be able to do some optimizations without you having to do anything extra!
Glad you appreciate it! My number one goal for launch week and the new homepage and this event reminder site is to drive the "tutorials taken" number. For me, that is success.
Yes, the new website we launched today is built with Redwood (except docs are done with Docusaurus). We're still doing some optimizations, but you are indeed looking at a Redwood app!
1. Redwood tightly integrates more of what you'll need as your app evolves: Storybook, Jest, Auth, Deploy, Logging, and a lot more.
2. A first class GraphQL experience so you can start from day one with the idea that you'll have multiple frontend clients (web, mobile, desktop, CLI, etc) so you only build your backend once.
3. Declarative data fetching with "cells" that make using that GraphQL backend super simple.
4. A community of builders and startup founders intent on helping each other succeed.
5. An amazing tutorial and set of documentation.
Speaking of the tutorial, that's the best way to get started if you're curious to see how Redwood feels in action!