RedwoodJS – Right Problem, Wrong Solution

This week, RedwoodJS celebrated their 1.0 release 🎉. Promised to be, “The fullstack JS app framework for startups” – Redwood wants to make it easier for small teams to quickly build and deploy modern web applications.

But…

I’m not sure they delivered with their v1.0.

😮‍💨 I don’t say this lightly.

I’ve been anticipating Redwood’s release for a long time. I first heard about the framework during this React Summit talk by Tom Preston-Werner, the cofounder of Redwood and, notably, Github(❗).

Preston-Werner opens the talk running through a laundry list of tools needed to create a client-side rendered web application: React, Prisma, Apollo, Jest, Storybook, webpack, Babel, etc. He goes on to highlight just how complicated this stack is to set up, configure, and deploy. Then, he introduces Redwood – a framework that tightly integrates these tools out of the box to…

“Bring fullstack to the JAMstack.”

Before joining Simple Thead, I ran a startup using NextJS to statically render our marketing page and had a React SPA running Apollo to communicate with a GraphQL API that used Prisma as an ORM. By any definition, that app was fullstack.

But building it didn’t feel fullstack. Decoupling the backend from the frontend created consistent complexity that significantly slowed down our team’s development progress in comparison to projects I’ve worked on for ST using traditional fullstack frameworks like Rails.

However, just like Rails, Redwood is out to…

Quell complexity through convention.

The Redwood team, rather than reimagining what it means to build an SPA like Remix or Hotwire, seems to focus more on mitigating the pain of standard practice.

Some of the standout features include:

Monorepo – couple the decoupled.

Whether using an SPA or SSG approach, building a client-side rendered (CSR) application means building the app twice – once in the backend and once in the frontend.

This disconnect still occurs in Redwood, but it’s eased by the framework’s monorepo approach. App code lives in two separate folders: web and api, but having them under the same roof makes it easier to share things like Types, validation code, and model helpers.

It’s also easier to simply start the application. Instead of opening two terminals to run the separate pieces, yarn redwood dev starts the SPA and API together. This is a much simpler process to explain to new developers who might be joining your team. Similarly, when doing deployment, setting up CI to build and deploy both halves can be done in the same GithubAction.

You don’t need Redwood to enable this type of workflow, but if you were going to do this configuration anyway, you’ve saved a day or two of work.

Cells – convention for the convoluted.

Displaying dynamic data on a page using CSR involves three major pieces: a view the data goes in, an API route to fetch that data, and the plumbing to connect the two.

But that plumbing – like an ApolloClient useQuery hook – creates four potential states for the view: empty (no data), loading, failure (error), and success. Handling each of these cases involves adding essentially the same, boilerplate code into every component that queries data – which makes the project harder to read and maintain.

To solve this, Redwood introduces the concept of Cells. This is essentially an abstraction on top of the Container-Presenter component model. A Cell file exports a GraphQL QUERY along with four React components: Loading, Empty, Failure, and Success. Redwood then handles rendering the correct React component based on the state of the ApolloClient query.

The Cells abstraction is an extremely useful and helpful convention for dealing with the convoluted boilerplate of CSR. Which is a great segue to…

Generators – don’t write boilerplate yourself.

The Redwood CLI is truly the main selling point of the framework. Because Redwood knows everything about your technical stack and project structure, the Redwood team has been able to add a ton of powerful tools to their CLI including a suite of generator functions.

Things like adding an entirely new model with CRUD endpoints and pages are one yarn redwood g ModelName command away. Same thing goes for adding things like authentication, mailers, and deployment configuration from tons of providers.

This saves developers a fair amount of time at the beginning of a project scaffolding the application. Redwood doesn’t get rid of the need for a lot of the boilerplate code, but its CLI does write it for you.

There’s more, but…

There’s a ton more that Redwood can do for you out of the box. It is a “batteries included” framework with loads of integrations and plugins. Where it can’t quell the complexity of building an SPA, it quiets it for you and gives you a pattern for reasoning through it.

But, before running yarn create redwood-app to create your next project (especially as a startup), I want you to ask yourself:

Does this app need to use CSR?

It’s more than likely – thanks to tools like Remix and Hotwire that are bringing an SPA-style UX to traditional SSR applications – that the answer is no.

Redwood’s entire framework is predicated on saving developers time by doing all of the CSR configuration work for them. But don’t let Redwood’s abstractions be a distraction from the fact that all of that complexity can be avoided for the life of your project by avoiding CSR altogether.

In a sense, I feel Redwood falls into a trap that many startups do…

Right problem – wrong solution.

Let me reiterate that I deeply wanted to love Redwood. Its all-star team identified real problems that I experienced for years when building web applications with modern approaches like SSG and CSR. However, I don’t feel the abstractions and conventions they provide are enough of a solution to the underlying issues of that architectural style.

But I’m also highly aware that this is only version 1.0 – it’s an MVP. I’m still going to keep a close eye on Redwood, and I hope future iterations of the framework will push the paradigm of JAMstack applications forward.