Obviously, I’m super biased here and love Redwood because it has improved my workflow dramatically. So much so that I’ve been able to build an app as a solo developer that serves thousands of visitors a month: teamstream.gg.
Keep in mind that I don’t have a ton of experience with some of the other frameworks, but I have taken the time to read the documentation and do the introductory material.
When it comes to data fetching, each framework has its own approach and unique features:
- do you like React Router v6? Use Remix (which is fundamentally architected on routes)
- do you like fetching at the page/route level? Use Next/Blitz
- do you need “islands of interactivity”, component-level fetching, and state? Use Redwood
Moreover, all these frameworks provide a way to easily model and access data.
So what I can say is that if you’re building an app or starting a side project, it can certainly be done using any one of these frameworks.
But that seems like a shallow way to compare them.
When investing time in a framework, I’m looking for one that allows me to build a production-level application that’s scalable, maintainable, and easy to onboard additional team members.
To me, there is only one option. And SURPRISE—it’s 
RedwoodJS.
The sheer amount of work that goes into upgrade guides, codemods, tutorials, cookbooks, and documentation is unmatched.
Just check out the level of detail that goes into a pre 1.0 minor version update.
Here’s a link to the Redwood v0.38 🚀 release notes.
Here’s a link to the V0.38 Upgrade Guide 🛠 with codemods.
Additionally, Redwood strives for no vendor lock-in. Host your app wherever you want—there’s a slew of supported deployment targets. You can run on serverless or serverfull architecture and switch back-and-forth with a CLI command.
That’s just the beginning of the maintainability story. Where I think other frameworks can’t even compete is that you just get a ridiculous amount of stuff out of the box. Things like Logging, Testing, Deploying, Code Splitting, Data Migrations, Service Mocking, Frontend Data Mocking, Secure GraphQL API, GraphQL Playground, Typescript, Custom Generators, Authentication, Storybook, and so much more. Those integrations are all first-class and things that are necessities for building scalable production applications.
The amount of time this takes to set up manually is weeks of work. And you get it just by running yarn create redwood-app. And maybe a few other CLI commands.
All that before the team is comfortable saying v1.
There are no breaking changes planned before releasing v1. Development is incredibly transparent and what’s being worked on can be found here: Current-Release-Sprint · GitHub. This board is kept up to date and is where all feature development can be tracked so any breaking changes can be caught early.
I’m not here to knock other frameworks. They’re truly excellent, and it feels like it’s never been a better time to be a developer.
But I don’t think that they can compare with the tools that Redwood provides to build secure, production-level applications fast, efficient, and with a delightful developer experience.
Here are just two of the snippets I’ve seen that cemented the amount of additional work I’d need to do to build a scalable application with other frameworks.
For instance, Kent C Dodds, Director of Developer Experience at Remix, tweeted this:
https://twitter.com/kentcdodds/status/1461440702378692609?s=20
Why do you even need to take the time to write this out and manage it? It’s free in Redwood with yarn rw setup auth dbAuth and that’s only if you want to roll your own. There are like 10 other auth integrations if you don’t want to roll your own, and Redwood provides the useAuth hook that aligns all the auth providers, allowing you to completely change your provider with almost no additional code.
And, taken directly from the Blitz.js docs:
Some folks say, “you’ll eventually need GraphQL so you should start with it”. While we believe most apps won’t grow large enough to warrant GraphQL, the question of an API for multiple clients is an excellent point.
We fully acknowledge that many web apps will need a mobile app sooner or later. And we want to make this integration as simple as possible!
That said, you can add a GraphQL server to your Blitz app for other clients. This can be an excellent choice and some folks are doing this.
If you know your application is going to grow and need GraphQL, or you know that you want to create a public API, why not just start with Redwood in the first place? It’s literally on the cutting edge of developer experience. The team works closely with https://the-guild.dev/ to provide a maintainable, secure, testable API following best practices.
On top of all that, the RedwoodJS community is thriving on both the forums and discord. Almost all questions about the framework that are asked and issues that come up are met with a response, tip, or workaround. And the repository has over 250 contributors and 10k stars.
I don’t want this to go on forever so I’m just going to leave this here. At the time of writing this, Redwood is the only framework that provides all the tools to build scalable, maintainable, production-level JavaScript applications—whether it’s a prototype, MVP, internal tool, or startup.
This post was inspired by a discord message of mine. You can check out the original here.
on the 
(me very old dork [east coast nerd]) 
at the end of this month