So I've been tinkering with BlitzJS for the past couple of weeks and I have to say, it's now my favorite way of making websites HANDS DOWN.
What is Blitz?
Blitz is a framework that attempts to be a React on Rails (Ruby on Rails but with React) sort of thing, and it feels friggin amazing to program in. We'll get back to the deetz on this in a bit. But first lets give a quick history of what things were like before blitz.
A Little History on Rails
If you don't know, Ruby on Rails' claim to fame is basically that you can churn out a full-stack website super fast. Here's how they achieve that.
- Really Great CLI Tooling
- Amazing ORM (Active Record)
- MVC Architecture allows you to create your frontend without explicit fetch calls
- built in seeds / migration for database
- built in integration / unit/ and e2e tests
All of this means you can start doing full stack development the second you run rails g new project-name, and you can have a full stack website built literally within a minute. You can even get relational data working from your CLI. The way they accomplish this is largely defined by their motto "Convention over Configuration", meaning that they've made a lot of the tough tech choices for you, and in doing so preconfigured all of them to work with each other. It's also probably worth noting here that Rails is like THE ruby stack that everybody chooses. It's Ruby's killer tech, and without the Rails framework, it's likely that Ruby would not be a popular language at all.
Unfortunately here's some things that kind of suck about rails.
- It uses Ruby instead of JS / TS
This isn't a problem per se, but the thing is that IMO Ruby as a language suffers in a few areas.
- Async Programming doesn't feel as good as it does with JavaScript.
- Ruby is designed to be terse, sometimes unnecessarily so, and this can make complex code really hard to trace sometimes.
- It's difficult to trace where things come from in Ruby, making it often VERY difficult to figure out how to do something that isn't well documented
- It's weakly typed, and there's no well-working typescript kind of thing for ruby.
- Everybody knows Javascript, not everybody knows Ruby
You're views are locked into being pretty static, pessimistically rendered. sure you can feed them with data, but most of the good stuff happens AFTER you refresh a page (Although there is new ways that Ruby is trying to Tackle this [ripping off Pheonix liveview]). If you are a beginner this basically means that the backend will primarily be driving any UI changes on the front. This simplifies logic, but can also be limiting in the types of things you can create.
It doesn't have the massive Javascript Community
- Many tools won't work with ruby very well, ie: firebase, styling libraries, UI testing libraries, etc...
- Sure Convention over configuration is great, but what if like I really really need to use some special package. Welp, it might be easy, or it might be really hard and difficult to debug.
Quick summary of pros and cons
| Pros | Cons |
|---|---|
| Fast to make Full Stack Website | Difficult to deviate from the norm |
| Best practice on DB, Testing from the jump | Ruby < Javascript / Typescript IMO |
| Amazing Codegen tools | Scalability |
On The Other Hand (Javascript)
Javascript, has felt like the opposite of rails. It's power came from it's flexibility. There are so many people with so many libraries constantly coming out that it's difficult to pick and choose which ones actually fit your needs. Furthermore, when you do pick them, now you have to make them play well with each other.
To give you an example, when I was learning to code, people called node-express a backend framework. Which is INSANE. All of express's functionality is a small subset of what rails can do. When you want to set up a full stack website with node you'll need a stack similar to the following
On the backend
- Express (handles controllers and routes)
- Passport (helps you with protecting routes)
- Some Database Client (helps you connect to a database)
- Some ORM(prisma), SQL Query Writer, or similar thing (allows you to query your database)
- Some Validations Library
- Need to go way out of your way to set up migrations / seeds for good database practice
On the frontend
- Choose your favorite: React, Vue, NextJS, Ember, JQuery, VanillaJS etc...
- Maybe: form libraries, validation libraries, typescript configuration
On both frontend and backend (this takes me for flarking ever personally 10+ hours to start and ever changing after I get the initial setup)
- typescript configuration
- prettier configuration
- eslint configuration
- testing configuration
- pipeline configuration
So yeah, it's super nice because you can swap out libraries and know what the heck is going on BUT it's A LOT of work and as they say "time is $$$$$$".
In summary on what programming in Javascript has been like
| Pros | Cons |
|---|---|
| Very Scalabile | Since nobody makes a choice for you, you will likely make some bad ones before you make good ones |
| Ton's of libraries | Configuration can take a very long time |
| Very Flexible, and transparent configuration | Slower to develop |
Alright so How does blitz solve these problems
First let's just look at blitz's core values
- Fullstack & Monolithic
- API Not Required
- Convention over Configuration
- Loose Opinions
- Easy to Start, Easy to Scale
- Stability
- Community over Code
I'm not going to get too into it, but lets break apart their mission a bit. The majority of these are fully inline with rails( Fullstack, api not required, convention over configuration, easy to start[although rails is harder to scale from what I understand]). One of the key divergences here is that "Loose Opinions", it basically means that the blitz team cares about you being able to switch alot of the technology.
More on loose opinions
Here is where you are locked in on Blitz. You have to use NextJS, React and.... thats about it. From there you can kind of do whatever you want, although you will have an easier time if you choose to use Prisma, and blitz's queries etc..
In other words, with Blitz they give you a happy path at default but straying from the happy path isn't like trying scale everest, it's just maybe going to be uphill and a little bumpy. In fact Blitz even has tools like "recipes" (which come from gatsby), that allow you to adopt new technologies not core to blitz, that maybe someone else has configured before.
Amazing ( albeit somewhat unfinished )CLI Tools
A little while back, I did an article about nestJS where I talked about their CLI. I really liked the idea of it, and it did save a little bit of time, but it's not nearly as good as Blitz's. The blitz CLI tools gives you some pretty amazing out of the box features, some of which wrap prisma commands. Here are some examples:
blitz g resource modelname attr1:datatype1 belongsTo:otherModel
- modifies your schema to generate a new model, in this case your model will have attr1 set to datatype 1, and belong to another model. a real example of this might be
blitz g resource dog name:string belongsTo:user
blitz g resource modelname attr1:datatype1 belongsTo:otherModel
- does everything that generating the resource does, but also adds an index, show, edit, new page for that model. For example now out of the box you can go to /dogs/new and create a new dog which is pretty insane.
blitz console
- allows you to explore your database with a CLI tool. This can be a bit buggy but is still super useful
blitz prisma migrate
- wraps prisma to migrate your schema
blitz seed
- runs your seeds.ts file
blitz install ___recipe_name___
this will install based off of a recipe. For example you could run blitz install tailwind and BAM you've installed tailwind.
It's some pretty amazing codegen tools that blitz has set up for you, and that's only one of the features that makes blitz feel amazing.
Automatic Codegen
So I don't fully understand the magic here, but prisma utilizes something they call the zero-api layer to generate types from your schema. Which is also pretty F**king insane.
In my backend I have a properties table, which in the schema looks like this.
Now once I migrate that file, I get types not only on my backend, but also on my frontend. At the top of my file I type `import {Property} from "db", and now I have the shape of my data on the frontend, I didn't have to make an interface anywhere. There's a single source of truth on that, which feels amazing. Now if I go to mess with a property on the front I know exactly what's there as soon as I make a change to my database.
This also means that if I make a breaking change to a type on the database, that breaking change breaks the backend and the frontend as well. Which just means you catch stupid type errors instantly which I love.
Routing
The routing comes basically straight out of NextJS but with a twist. I'm not super familiar with next, but from what I understand in nextJS, you couldn't structure your routes by folder, but in blitz you can. So for example if you have the following
`
src
- pages
- properties
- [propertyId]
- edit.tsx
- [propertyId].tsx
- new.tsx
- index.tsx
`
- [propertyId]
- properties
You get the following routes automatically.
/properties/:id is your show page
/properties/:id/edit is your edit property page
is your create property page/properties/` is your properties index page
This just makes your life easier with routing
Outro
I'm not going to go full on over all of blitz here, because the blitzJS Documentation is already amazing. But here's some features that I never mentioned you get access to.
- Free Authentication, User, Password, Email OUT OF THE BOX
- React suspense library integration
- everything you already like about NextJS
- API routes and middleware
- Date Serialization
- Recipes, and ability to create your own custom recipes
- Jest out of the box
- A Cypress Recipe if you want e2e tests
- The team is trying to make this React Native Friendly (which would be a dream come true)
Long story short, BlitzJS feels amazing. I think it's just one of the best developer experiences that I've ever had and I highly suggest you try it out too.
Top comments (1)
Great writeup. I keep debating blitz.js vs rails + inertia + react. I am very early in my research, but they both seem capable of achieving zero-api. Also, rails + inertia is slightly less opinionated since you don't have to use react (or nextjs).