mojombo

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.

Oh, and we have a video version of the walkthrough in case that's more your style!

https://youtu.be/5IZv3khsx0o

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.

Happy to answer any questions you may have!

Thanks, Will! It's awesome having you in the Redwood startup community, and blown away by the work you're doing at Everfund!

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.

Explanation and link added!

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!

Did you look at the main website? https://redwoodjs.com

It is indeed a web app framework, based on React, GraphQL, Prisma, Storybook, Jest, and with many integrations for auth, logging, etc.

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. =)

https://tom.preston-werner.com/2022/04/04/redwood-v1-and-fun...

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!

The golden path is to use GraphQL, but you are free to do data fetching to other data sources in the normal way you would in a React app.

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!

Core team member here. Several reasons:

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!

Fun to see this on HN! I originally created Gollum to power GitHub's wiki system and wanted to see if we could use Git to make our wikis more powerful AND more open. I thought it would be cool if you could just clone your GitHub wiki and modify it locally or export it to some other system if you needed, or have it all locally for an airplane trip without wifi.

Another interesting thing is that I used my Readme Driven Development method to develop it, which you can see in the Readme of the first commit: https://github.com/gollum/gollum/commit/c7875704971be998a539.... I wrote it before writing a single line of code and found it worked nicely to figure out the API and feel out the ergonomics of the text format. More on that approach here: https://tom.preston-werner.com/2010/08/23/readme-driven-deve...

Glad to see the project alive and well!

I think this is true for any specific moment, but as we are creatures of the 4th dimension, we must also care about how we change our code over time. When code complexity is managed, users can enjoy better versions of a piece of software more quickly and more often. If we let our code deteriorate into an inscrutable pile of tech debt, it will eventually affect the user experience, so the guts need to both do something correct (and useful) and also be amenable to change over time.

TOML is my true legacy. =)

Author here. Fun to see this come up on HN again, every so often. Readme Driven Development still serves me well (that’s how we drove RedwoodJS early on) and we even expanded that into Tutorial Driven Development, where we wrote the RedwoodJS tutorial to show what we wanted to be possible from a DX perspective, and then figured out what code we needed to write to make it possible. It’s been an efficient way to focus on what’s important and not make usability sacrifices for the sake of easy coding. It’s really just the design-first approach, applied to a framework!

Your understanding is accurate. We do plan to support pre-rendering on a route-by-route basis, which will perhaps be more inline with what JAMstack tends to mean today. But Redwood is still all about JavaScript (client) and APIs (backend), with markup to follow, as I just mentioned. But more than that, it's about the development and deployment philosophy of JAMstack that we fully embrace.

While Redwood is currently optimized for deployment on Netlify, it is by no means restricted to that environment. Our intention is for Redwood apps to be deployable to a variety of JAMstack providers in addition to traditional serverful setups. My main interest is in providing an integrated, joy-inducing experience for app developers that want to leverage the full awesomeness of modern JavaScript and friends. It's true that if Netlify wins, I win too, but I'd rather DEVELOPERS win, and that's what keeps me motivated.

Thanks for noticing our hard work! We spent a LOT of time making sure the tutorial was rock solid and very clear. We will continue investing time into making the tutorial and our docs even better!

Unfortunately, no. Cloudflare workers are heavily restricted in what they can do, both from an outbound request and compute time perspective. If those restrictions are reduced, it’s possible we could make it work someday. It sure would be awesome!

Not currently, and we will prefer pre-rendering to SSR if we can make it work well enough. But we are planning to address SEO concerns.

Like David said, we currently only help you build a web frontend, but we intend to eventually make it super nice to build a mobile app, desktop client, CLI, etc. All under the redwood umbrella (canopy?).