[Feb 2020]: First announced.
[Apr 2020]: First alpha release.
[Feb 2021]: First beta release.
[Dec 2021]: Decided to do major pivot.
Today the Blitz.js 2.0 pivot to a modular Next.js toolkit reached Beta status [1]
Previously Blitz abstracted Next.js, but Blitz 2.0 is now a modular toolkit that plugs into any new or existing Next.js app. Blitz picks up where Next.js leaves off, providing libraries and conventions for shipping and scaling small to large apps.
When I first created Blitz, my aim was to have an all-in-one fullstack framework for Javascript like Ruby on Rails. But that proved to be too difficult. I've decided that achieving an all-in-one framework for JS like Rails is too difficult unless you have a ton of funding and don't have to make meaningful money.
The difference with JS is that client-side frameworks like React have an incredible amount of complexity. Trying to manage all of that and all the other fullstack framework stuff like API layers, auth, file uploads, etc is too large of scope.
So now Blitz is no longer trying to do it all and is focusing on all the non-frontend functionality you need to ship web apps.
Going forward, we want to be the most trusted technical resource for rapidly building and scaling full-stack TypeScript apps.
Thank you! It's still early for Flightcontrol and we have so much to improve. But we already have a non-trivial amount of production customers (including some very high traffic sites) and solid monthly growth.
We're planning to switch pricing to tiers. Psychologically 30% sounds like a lot, although the end price is quite low. For example we have a site with close to 10 million requests per month with heavy server compute. Their cost is about AWS $300/mo and Flightcontrol $90/month.
I haven’t used Blitz 2.0 (beta came out today?!), but I really enjoyed building with Blitz 1, and the architecture change for 2.0 looks really good. The creator
My personal project stack is Vercel + NextJS + Blitz + Supabase. I can choose to use Blitz’s auth if I need rich OAuth providers, or Supabase’s if I’m building something super simple. I think Prisma (which Blitz bundles as the database access layer) is more productive in the domain of single weekend dev than Rails/ActiveRecord or Django’s ORM.
Here’s the task list:
1. Create Supabase project (2 clicks)
2. Create project with Blitz generator (1 command)
3. Create git repo on GitHub & push (2 clicks)
4. Create Vercel deploy for git repo (3 clicks)
I don’t think there’s a stack out there that can take you from zero to a full stack richly interactive app with CDN caching, auth, database, and live refresh as quickly. If you only want server rendering, Rails + Supabase + Render might be close, but if you’re familiar with Typescript it really is a dream.
I really recommend checking it out if you’re into Typescript.
I know it's a bit late to reply to this, but I'm interested in why you have Supabase in this stack and how you use it. Do you access it using Prisma? Or is it just there to provide auth?
I'm obviously biased as I liked the tech so much I applied for a job here -- but if GraphQL is your thing I feel similarly about Hasura + Next.js with TypeScript & generated type-safe GQL client SDK's.
I deploy on AWS AppRunner or Google CloudRun which takes care of the HTTPS/TLS and domain bits.
- The ts perf things that set trpc apart and make you feel it earlier in tRPC than blitz are largely resolved by the new major of trpc that is currently in a stable alpha (stable in terms of no known bugs, but API might change)
I also tried it (and even sponsored it) as it showed potential, but using it simply didn't fulfil the promises: it took a lot longer to achieve what I wanted (deploy a simple app with user system) because there is always stuff like "you can't have a different database type locally than in production", you can't simply build the application, so you can upload it to any VPS, you have to use railway, and stuff like that which ends up costing A LOT of time, not even mentioning how long it takes to understand how to use it and how it works.
This is not a criticism of Blitz which looks fine. From what I can see, it is better than fine.
However, this reminds me of the early Rails (or even Rails 4.0) demos that I saw where they build a blog in 5 minutes.
Here is the thing: The fastest way to get a skeletal app running -- even if it is written in C -- is to
> git clone already_written_archetype.lang
And then you can modify it.
So you can put that archetype into the framework. So I always wonder if the right example is not build a blog or to-do-list or twitter clone. The right example might be:
take a blog and change it into a twitter clone
Because you can always download the archetype if you need to but the framework should demonstrate how nimble it is. (Again, I don't claim Blitz is not nimble and I would have to play with it to know.)
Both popular SSR frameworks (Next.js + Remix) break the Unix philosophy, and Next.js + Blitz.js is the opposite of the Unix philosophy. (You might think that this is worth it, and you may even be right, but it's something to consider.)
Want a better React stack? Try React + tRPC + Express + Prisma. Each component can be easily swapped out and understood independently (sorry Next.js / Remix), all routing is explicit (sorry Next.js / Remix), development startup time is fast (sorry Next.js), and you still get e2e type safety + minimal boilerplate. I like to call this stack the "NF" stack: "No Framework".
The fanboys will complain. "What about SSR?", they will say. Well, here's the solution: quit fretting about SSR. Your signed-in customers will gladly take 0.05 seconds extra render time for the extra features your devs will be able to deliver after you ditch your complicated SSR framework. Want to do SEO? Make a WordPress site and "SSR" it with Simply Static[0]. Your site will achieve the theoretical minimum Time To First Whatever, your marketing team will be free to actually do their job rather than spending 2/3 of their time trying to get devs to update the landing page, and your devs can move on to something more useful (like creating useful features. Isn't that supposed to be the goal?)
While your comment has an excellent technical perspective, the tone is a little negative. He's gone and built something brilliant & I think you should acknowledge that whilst also (validly) suggesting an alternative.
I'm personally conflicted: I see the upside of Blitz for sure (and find it impressive) but I also have been ultra-burned by frameworks & certainly would never give up Vite.
As far as I can tell the implementations between TRPC and BlitzRPC are very different. One basically (paraphrasing their own words) abuses Typescript & requires some maintenance, where BlitzRPC appears to be a "Svelte-like" everything is a compiler approach.
There's a real scaling issue with tRPC (they say something like unsuitable for large projects IIRC).
It just kinda seems like you've re-invented an ad-hoc framework by gluing various different components together. There can be advantages in this, but there are pretty frequently downsides to this approach too.
It's like back when everybody was going through the "I want to use Sinatra rather than Rails" phase and what happened was a million different half-baked reimplementations of 20% of Rails that were different on each project for no significant benefit.
Why glue it together yourself when a community or someone working full time on it can glue it for you? As a bonus you also get documentation. Since it's open source you can read the code, and it even is based on the stuff you are recommending. If you value your own time it's a no brainer.
It's worth gluing together 1) so everything is explicit, 2) you don't have to write all of the schrodinger's cat "if executing on client, x, else, y" logic inherent in SSR frameworks, and 3) you can avoid Next.js's slowness
Agree completely. I used Next.js for many years, but I probably wouldn't choose it today. SSR adds complexity and blurs the distinctions between client and server and as a result everything is harder - especially tooling and glue code. It also doesn't help that there is a major release so often that whatever configuration you used 6 months ago is now obsolete.
I really wish frontend react stacks would stabilize and provide some sanity for businesses to get on with their primary mission of not just building but also _maintaining_ products.
> It also doesn't help that there is a major release so often that whatever configuration you used 6 months ago is now obsolete.
(I'm on the Vercel/Next.js team) Could you share specifically what configuration you found obsolete?
> I really wish frontend react stacks would stabilize
Did you have trouble upgrading versions? Open to feedback. We frequently hear folks who upgrade from Next.js 8 to 12 with minimal changes, for example.
I sometimes wonder what is different about frontend JS community and ecosystem vs backend ecosystem that makes them iterate over and ship new framework every other week. Is it a lack of standardization/specs or unwillingness to improve existing abstractions?
I could be completely wrong, but it feels like building on so many abstractions, one tends to lose insight into the underlying stack and you eventually enter a diminishing returns territory.
Readit News
[Feb 2020]: First announced. [Apr 2020]: First alpha release. [Feb 2021]: First beta release. [Dec 2021]: Decided to do major pivot.
Today the Blitz.js 2.0 pivot to a modular Next.js toolkit reached Beta status [1]
Previously Blitz abstracted Next.js, but Blitz 2.0 is now a modular toolkit that plugs into any new or existing Next.js app. Blitz picks up where Next.js leaves off, providing libraries and conventions for shipping and scaling small to large apps.
When I first created Blitz, my aim was to have an all-in-one fullstack framework for Javascript like Ruby on Rails. But that proved to be too difficult. I've decided that achieving an all-in-one framework for JS like Rails is too difficult unless you have a ton of funding and don't have to make meaningful money.
The difference with JS is that client-side frameworks like React have an incredible amount of complexity. Trying to manage all of that and all the other fullstack framework stuff like API layers, auth, file uploads, etc is too large of scope.
So now Blitz is no longer trying to do it all and is focusing on all the non-frontend functionality you need to ship web apps.
Going forward, we want to be the most trusted technical resource for rapidly building and scaling full-stack TypeScript apps.
[1] https://github.com/blitz-js/blitz/releases/tag/v2.0.0-beta.1
There's some obvious risk in your business model but I'm 100% rooting for you.
We're planning to switch pricing to tiers. Psychologically 30% sounds like a lot, although the end price is quite low. For example we have a site with close to 10 million requests per month with heavy server compute. Their cost is about AWS $300/mo and Flightcontrol $90/month.
My personal project stack is Vercel + NextJS + Blitz + Supabase. I can choose to use Blitz’s auth if I need rich OAuth providers, or Supabase’s if I’m building something super simple. I think Prisma (which Blitz bundles as the database access layer) is more productive in the domain of single weekend dev than Rails/ActiveRecord or Django’s ORM.
Here’s the task list:
1. Create Supabase project (2 clicks)
2. Create project with Blitz generator (1 command)
3. Create git repo on GitHub & push (2 clicks)
4. Create Vercel deploy for git repo (3 clicks)
I don’t think there’s a stack out there that can take you from zero to a full stack richly interactive app with CDN caching, auth, database, and live refresh as quickly. If you only want server rendering, Rails + Supabase + Render might be close, but if you’re familiar with Typescript it really is a dream.
I really recommend checking it out if you’re into Typescript.
I deploy on AWS AppRunner or Google CloudRun which takes care of the HTTPS/TLS and domain bits.
Some notes:
- The problems with tRPC "at scale" are fixable by using project references, but not going to downplay that it's an annoying refactor to do (https://github.com/microsoft/TypeScript-Handbook/blob/master...)
- All of the problems with trpc are inherent of any ts thing that is heavilily reliant on inference (hence also blitz) (https://github.com/microsoft/TypeScript/wiki/Performance#wri...)
- The ts perf things that set trpc apart and make you feel it earlier in tRPC than blitz are largely resolved by the new major of trpc that is currently in a stable alpha (stable in terms of no known bugs, but API might change)
However, this reminds me of the early Rails (or even Rails 4.0) demos that I saw where they build a blog in 5 minutes.
Here is the thing: The fastest way to get a skeletal app running -- even if it is written in C -- is to
> git clone already_written_archetype.lang
And then you can modify it.
So you can put that archetype into the framework. So I always wonder if the right example is not build a blog or to-do-list or twitter clone. The right example might be:
take a blog and change it into a twitter clone
Because you can always download the archetype if you need to but the framework should demonstrate how nimble it is. (Again, I don't claim Blitz is not nimble and I would have to play with it to know.)
Future of Blitz - https://news.ycombinator.com/item?id=30896931 - April 2022 (31 comments)
Blitz: A Fullstack React Framework, Built on Next.js - https://news.ycombinator.com/item?id=27411975 - June 2021 (35 comments)
Blitz.js Now in Beta (Batteries Included Framework Built on Next.js) - https://news.ycombinator.com/item?id=26166716 - Feb 2021 (78 comments)
Want a better React stack? Try React + tRPC + Express + Prisma. Each component can be easily swapped out and understood independently (sorry Next.js / Remix), all routing is explicit (sorry Next.js / Remix), development startup time is fast (sorry Next.js), and you still get e2e type safety + minimal boilerplate. I like to call this stack the "NF" stack: "No Framework".
The fanboys will complain. "What about SSR?", they will say. Well, here's the solution: quit fretting about SSR. Your signed-in customers will gladly take 0.05 seconds extra render time for the extra features your devs will be able to deliver after you ditch your complicated SSR framework. Want to do SEO? Make a WordPress site and "SSR" it with Simply Static[0]. Your site will achieve the theoretical minimum Time To First Whatever, your marketing team will be free to actually do their job rather than spending 2/3 of their time trying to get devs to update the landing page, and your devs can move on to something more useful (like creating useful features. Isn't that supposed to be the goal?)
/rant
[0] https://wordpress.org/plugins/simply-static/
(edited to remove some unnecessary negativity)
I'm personally conflicted: I see the upside of Blitz for sure (and find it impressive) but I also have been ultra-burned by frameworks & certainly would never give up Vite.
As far as I can tell the implementations between TRPC and BlitzRPC are very different. One basically (paraphrasing their own words) abuses Typescript & requires some maintenance, where BlitzRPC appears to be a "Svelte-like" everything is a compiler approach.
There's a real scaling issue with tRPC (they say something like unsuitable for large projects IIRC).
It's like back when everybody was going through the "I want to use Sinatra rather than Rails" phase and what happened was a million different half-baked reimplementations of 20% of Rails that were different on each project for no significant benefit.
(I'm on the Vercel/Next.js team) Could you share specifically what configuration you found obsolete?
> I really wish frontend react stacks would stabilize
Did you have trouble upgrading versions? Open to feedback. We frequently hear folks who upgrade from Next.js 8 to 12 with minimal changes, for example.
Would you mind to elaborate?
I could be completely wrong, but it feels like building on so many abstractions, one tends to lose insight into the underlying stack and you eventually enter a diminishing returns territory.