In case you weren’t already confused enough about the differences between Redwood and Blitz we now have a third contender, Bison, with a very similar overall architecture but its own particular combination of technologies. Chris Ball appears to be the brains behind the project. It is supported by Echobind where he works as CTO.
Bison knows that while good artists borrow, great artists steal, and they have taken direct inspiration from Redwood with their own version of Cells. But they also have their own vision of what they want the framework to be and where they want it to go:
Think of Bison as a bit closer to the metal, but preconfigured for maximum DX and efficiency. The good news is, if you disagree with any of the choices we’ve made, nothing is hidden from you and you’re welcome to adapt the “framework” to fit your needs.
In tandem with the public announcement of the project they also released a short overview video and a long deep dive of the entire architecture. I really love this approach and I hope other new frameworks on the horizon consider it.
Here’s a break down of each stack and how they compare:
Redwood
Blitz
Bison
Routing
Redwood Router
Next.js
Next.js
Types
TypeScript
TypeScript
TypeScript
Not-an-ORM
Prisma
Prisma
Prisma
Code Generation
Redwood CLI
Blitz CLI
GraphQL Codegen, Hygen Templates
Styling
Tailwind
Import CSS
Chakra UI
Forms
React Hook Form
Vanilla JS/TS
React Hook Form
Testing
Jest
Jest, RTL
Jest, RTL, Cypress
Deploy
Netlify
Vercel
Vercel
All three frameworks seem to have their own authentication which would probably need a much longer post than this to directly compare. All three have their own unique opinions about project and file structure that would also make an interesting post by itself. All three support SQLite/Postgres out of the box with the option to switch in other databases of your choosing.
I think that covers all the big stuff, let me know if I left anything off or made any errors.
Before every picks up their pitch forks saying one is better than the other.
This is a new sector of JAM Stack with so much to be created and different paths to take to reach the same goals. In my eyes as it promotes the fullstackJAM (fsJAM)?
So I wish them luck and hope it grows and succeeds!
Thanks for the overview @ajcwebdev and I completely agree with the comments so far! Appreciate the lack of pitchforks .
I absolutely view this as complimentary to the overall FSJAM (thanks @Chris!) ecosystem. The goal was not to add confusion by introducing another option, we just wanted to share our approach and ideas with the community. Eliminating copy/paste of code between projects that use this stack is also a huge win for us. Unlike Redwood and Blitz, Bison is conceptually closer to using CRA and then immediately ejecting. Once the app is generated you are essentially on your own for upgrades. That may change, but it was a far easier starting point.
I met with @mojombo a few months back and joked that I felt like we were creating somewhat of a manual Redwood. Like we say in the Readme, it’s entirely possible that we adopt Redwood in the future. For now though, especially given we are still in the early stages of this kind of approach, I feel like Bison can help get people onboard with the general FSJAM philosophy and stay a little closer to something they might have created themselves (just with a lot more time invested).
If you get a chance to try it out, please give comments or suggestions. If there are any approaches or patterns that may make sense to adopt in Redwood, I’d love to talk about them as well!
I love the idea of everyone being welcoming and trying to support fsJAM continues to grow and succeed. I have created a twitter/discord account to help pull lots of information together from multiple fsJAM Frameworks
Totaly unofficial of any of the frameworks but I would love a place for people to join and have some fun chats between frameworks!
Here I’ve added RedwoodJS, BlitzJS and Bison. Feel free to add more JAMstack fullstack frameworks, and share the resulting link.
Could be interesting to watch, going forward. Please feel free to suggest better indicators of popularity.
(Not that popularity is the be-all and end-all of frameworks, of course).
.