# Roadmap
Last updated 25 Aug 2020
We want to hit 1.0 by the end of the year. And we think we can do it. But there are a lot of moving parts, each at a different level of maturity.
At this stage of development, when it's so important to keep the finish line in mind, a high-level overview is invaluable. Hence, this roadmap, and these color-coded labels:
- Didn't start
- Figuring it out
- There's a plan
- Making it happen
- Cleaning up
We're taking inspiration from Basecamp's Shape Up here: you can think of each one of these color-coded labels as a point on the hill chart. So if you want an even higher level overview, scroll the aside on the right, keeping the colors in mind.
If you know Shape Up, then you'll know that our scopes are probably too big. They are. But we want to orient people who aren't knee-deep in this, and questions like "how's TypeScript going?" are usually the kinds they have. This means that even if we say TypeScript is Making it happen, there are some parts of it that might be Didn't start.
This document is alive. We'll update it as often as we can, and when it's appropriate to do so. And as always, feel free to open a PR!
# What goes in 1.0?
Not everything will be in 1.0. Even things that are core to the Redwood dream, like more sides and targets, won't be there. But that's by design: we need to be very careful about our priorities, both because we want 1.0 to be something special and because if we aren't careful, we'll never get there. The hardest thing in open source is saying no, but as we get closer to 1.0, it's increasingly what we'll have to do.
With that said, here's a high level overview of the 1.0 roadmap with links to relevant GitHub project boards and forum topics. If you're interested in helping with one of these, just let us know in the RedwoodJS Forum and we'll be happy to get you set up!
# Accessibility
Figuring it out
Accessibility isn't something we're going to compromise on. It has to be first class. Our goal is to help app authors build accessible experiences without having to jump through hoops. As background reading, Gatsby has some great blog posts.
Accessibility • GitHub Project Board
# Auth
Making it happen
Authentication and authorization are baked into Redwood. We plan to have easy-to-install, sophisticated authentication methods for a variety of popular auth providers. On top of that, we'll also provide RBAC (role-based access control) capabilities if you want them.
# Core
Making it happen
Redwood depends on a few libraries—namely Apollo and Prisma—for some of its core functionality. For us to be 1.0, they have to be too.
ApolloClient recently hit 3.0. Right now, Redwood uses 2.6, but we plan on upgrading as soon as we can. Prisma Client made it to general availability earlier this year, but Redwood depends on Prisma Migrate too, which is still experimental. You can check its status on Prisma's public roadmap.
# Deployment
There's a plan
We'd like to support several deployment targets. The ones high-up on our list are: Netlify (done), Vercel (done), AWS, and Google Cloud Run. Deployment strategies should be done in a way that makes it easy for additional targets to be added and for users to create their own custom strategies.
Deployment • GitHub Project Board
# Docs
Making it happen
Part of Redwood's initial success was the quality of the tutorial. The practice of readable and comprehensive documentation is something we plan to continue. The road to 1.0 doesn't mean sacrificing on the quality of docs. On the contrary, the more the framework can do, the better the docs have to be.
Docs are tracked on the redwoodjs.com repo
# Generators
Figuring it out
Our generators are already in pretty good shape. So as we get closer to 1.0, we don't just mean more generators, but more advanced generators. Especially given the recent addition of @redwoodjs/structure.
Generators • GitHub Project Board
# Logging
Figuring it out
Logging has wiped out almost all of the old-growth Redwoods in California. But that doesn't mean we're not fans of logging here at RedwoodJS. As long as the logging helps you figure out what your app is doing! A production Redwood app will need great logging, so we intend to make it easy to get hooked up.
Logging • GitHub Project Board
# Performance
Didn't start
Can you have great developer ergonomics and performance? We intend to find out.
Bundle size will be important here, so a good place to start is by building with the stats flag (yarn rw build --stats). This will make Redwood bundle with the Webpack Bundle Analyzer.
Performance • GitHub Project Board
# Prerender
Figuring it out
# Router
Figuring it out
We've written our own router for Redwood, and we need to make sure it is competitive with existing routers in the React ecosystem (e.g. React Router, Reach Router). We've taken a stance on desiring a flat routing scheme (vs a nested one) and this currently comes with some performance downsides that need to be addressed.
# Storybook
Making it happen
Redwood's component-development workflow starts with Storybook. Being able to develop your components in isolation without ever starting the dev server is a real game-changer.
Storybook • GitHub Project Board
# Structure
Making it happen
Using Redwood's Structure package, we can use the same logic to power both an IDE (e.g. Jamstack IDE) and Redwood itself. Redwood Structure's most common use-case is getting the diagnostics of a complete Redwood project, but being able to programatically talk about a Redwood project like an AST moves many other amazing things we can't anticipate into the adjacent possible.
Structure • GitHub Project Board
# Testing (App)
Making it happen
We've integrated testing for both sides and made Jest configurable. From here, improving the templates that the generators create is a must, not only for the sake of completeness but also for user learning.
Testing • GitHub Project Board
# TypeScript
Making it happen
We want Redwood apps to default to TypeScript. There's a lot to do, both on the Framework-side and the app-side, but its happening.