Why I would choose RedwoodJS over any other framework

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 :evergreen_tree: 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:

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.

7 Likes

Thanks for this @KrisCoulson! I think another thing that can be intimidating about Redwood is that, when doing a comparison, it can seem like a lot of prior knowledge and exprerience is required:

  • React
  • Apollo
  • GraphQL
  • Prisma
  • JS and TS (and Node.js)
  • etc.

Whereas Next.js describes itself as “The React Framework”, which feels like a lot less overhead to get started. E.g. “Ok, cool, I can figure out this React thing…”

Related to the technologies used by Redwood, what would you say your level of prior experience/knowledge was? And any advice about this to others looking to get started?

1 Like

@thedavid I think those are very realistic, fair points and the learning curve might seem steep to some who have been writing code for less than a few years or haven’t worked across parts of the stack other than strictly front end.

In the 8 or so years I’ve worked as a software engineer, I have worked across the stack and done a fair amount of web development, but have been focusing mostly on iOS development for the last 3-4 years and really only knew some Typescript and my way around React and Redux when I got started with Redwood last August. I was able to get up to speed using RedwoodJS following the tutorials, Cookbooks and reading through forums in a couple of weeks.
I think learning RedwoodJS is very reasonable if they were already going to dedicate themselves to being a developer working across the stack in some capacity even without RedwoodJS.

The thing I struggled with the most (I’m almost embarrassed to admit, but will anyways) was deciding on a UI library to style my forms. Antd isn’t as fitting a choice in RedwoodJS projects because you have to choose antd’s or the built-in RedwoodJS form components. I went back and forth trying to decide whether to leverage the built-in form tools RedwoodJS provides or use some other library; Redwood’s form tools have won out and I’m glad I settled on those.

What I would suggest to developers who are considering RedwoodJS but haven’t used the underlying tools, such as Prisma, GraphQL and Apollo - is that they should get up to speed, and understand when they would and wouldn’t use those tools in other projects where they have complete control of choice and be able to use them at least well enough that they can write simple features using those tools.

Just my 2c - I hope this helps someone else looking at this framework and is good feedback for the RedwoodJS Core team.

4 Likes

@PilotSSW this is great feedback and great insight offered from your experience.

This really resonates.

And this is simply solid advice.

Thank you!

And I look forward to learning about your current (and/or future) Redwood projects! I’ll keep my :eyes: on the #show-tell for a future post (no pressure, of course). :wink:

@PilotSSW I am with you there: The thing I struggle with the most is using any UI library to style my forms. Secondly, my UI. I’m so old there wasn’t any css. :older_man: :nerd_face: (me very old dork [east coast nerd]) :rofl:

I am starting my next project and swear to use Storybook this time !! And I hope I can get Mui.5 running easily – Love that lib the most these days.

I saw another thread talking about generating storybook support – I’ll go see what’s up w/that.

Just wanted to say, you’re not alone at all. I couldn’t get my head into storybook last time but I’m gonna make this round head fit into that square hole yet !!

One of the main reasons I’m loving Redwood is that the happy path of development is the most testable and easiest to maintain. That the decisions and flow that the Redwood Team has created is the best mix of Best Practices that I have ever seen.

Personally I like how I become up a better React programmer the more I align with the Redwood way of doing things – learning by Osmosis !!

Redwood Rules !!

2 Likes

Update:

I watched the video on Design First, using Storybook w/Redwood and I was blown away. Game over. Going there, Doing that.

So I have been LOVING RedwoodJS+Storybook with my latest project!! I find a page with a component in a component (etc., etc.) that has a problem, it’s misbehaving or the spacing around it isn’t working right, or Anything-It-Doesn’t-Matter-Anymore !!

Now I drop in on the component, and repair it, testing it and exercising it in isolation :slightly_smiling_face:

Then I check it in it’s containing component, in isolation again :grin:

And then I flick thru all the pages where it’s used in a few Seconds (because I can) :rofl:

RedwoodJS :+1:

RedwoodJS + Storybook :muscle:

2 Likes

This makes me so happy. But how did you find that video?!? I created it to show to the Storybook team as a draft and I’ve been meaning to update and record a better version ever since. And I also never posted a link anywhere.

Regardless, I’m excited that you’re excited :rocket:

Hahaha I’m watching you guys like a HAWK !! :grin: I’ve known of that video for a couple of weeks and have been using it to evangelize

I need everything you’re building, and I need to bring it into the office as the official React framework, I need I need I need, I want I want I want

I looked into your work when you RW was brandy new, and I loved all the things you were saying - but there wasn’t enough there

Then I came back around v24 and have been loving it. I tried to use Storybook around v35 but couldn’t get it — now I do and I’m sold lock, stock, and two smoking barrels !

Cheers All,

Al;

  • Redwood Rules !
2 Likes

Ha! Thank you, Al. Your enthusiasm is wind in my sails.

Lots of milestones to come in the month ahead. Keep me (and us) posted about the status re: your office adopting Redwood (or not). We’d like to see more of that post v1.

1 Like

@ajoslin103 - check my comment at Design-first Full-stack: RedwoodJS, Storybook, and Tailwind - YouTube and you will see that you are not the only hawk in RWJS community (I am another one)

@thedavid - the repo GitHub - thedavidprice/storybook-redwood-demo: Design first full-stack with Storybook and Redwood does not seem to contain the latest code. Would it be OK if I introduce the RedwoodJS to all of us, using your (perhaps slightly modified) code?

1 Like

@thedavid if you have a staff evangelist they should ping me

Our company does hack weeks and I’ll likely to Build Something with Redwood :+1:t3: at the end of this month

1 Like

Sure thing! I’m going to try and do an improve recording soon and will likely update that repo. But you’re free to share!

@ajoslin103 That sounds great! I’m definitely in the category of staff evangelist, although often @ajcwebdev is the better fit and, as of recently, @giannelli.tech is helping do the same.

Don’t hesitate to ask!

Do you work at a consultancy?

1 Like