Thoughts on RedwoodJS
Tags: react, redwoodjs, graphql, prisma
Published: 2020-05-25 06:45:19

For the past few days I've been going through the [RedwoodJS tutorial](https://redwoodjs.com/tutorial/welcome-to-redwood) and cookbook to see what the technology is all about, I've also listened to [Full Stack Radio's episode](https://fullstackradio.simplecast.com/episodes/138) where Adam Wathan interviews the creator to better understand why it's being built and what problems it's trying to solve.

## The tutorial

First of all I need to praise the Redwood team for putting together one of the best tutorials for a framework I've every experienced. Clear, concise paragraphs and code explained with plain English and light humour. Go through it and you will see what I'm talking about.

## Abstraction done the right way

Many JAMstack frameworks are trying to abstract certain elements away from the developer so we can just focus on creating apps with the right content. Most fail and just produce a chaos of problems that you don't know how to solve, due to the fact that they are abstracted away. Redwood doesn't do that, it abstracts away just enough for to still understand whats going on.

Taking for instance the way GraphQL + Apollo Client work with Prisma. I was familiar with all of these technologies, but never understood them fully until going through the tutorial. Yes it is still abstraction and yes you still give a lot of control to the framework itself, but this doesn't limit you. It's opinionated in the right way in my opinion as someone who only has about 2 years professional experience in the industry.

## Cells

Redwood introduces the concept of 'cells' which in my mind is a thing every single framework should have out of the box. It again opinionizes a concept of how we deal with data state and what to show on the UI. If you write React code there isn't a set way of doing this, maybe you throw in some conditional statements and have to write entire components in order to make it work. 

Redwood presents you with 4 states (Failure, Empty, Success and Loading) where you just tell it what to render once it enters that state and this is again.. fantastic. It eliminates the need to think about how to handle these states and just gives you the option of what to present to the user.

## The Redwood CLI

Not sure if I should call it a CLI, but Redwood goes down the path of the Angular CLI, where you can add `yarn` workspaces through the terminal which I don't understand why it wasn't a thing with React apps before. You have generators for `layout`, `pages`, `components`, `services` and much more. This saves time and again gives you a sort of standard how things should look in your code.

## React is imported everywhere

Leaving you with this: You don't have to import React to every single component. Again, I don't know how this wasn't already solved in the past, why would I need to import 'react' into every single component or page I make? With Redwood you just generate your app and start writing JSX code. You still have to import stuff like `useState`, but this is a welcome edition.

Those are my thoughts on RedwoodJS. I'm excited to see where it goes in the future and what it will bring to the table, it's currently still in an alpha stage so don't go building production apps with it just yet. Play around and see for yourself why I and a lot of other people like it.

Thanks for reading!