[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.
It’s commoditized and a race to the bottom and a rounding error for AWS spend to wipeout everyone in the space and it might be a good business, it’s getting harder to differentiate, and …?
Not that it’s going to happen. But there’s a plethora of obvious risks.
BTW - to the author of FC, this is not directed against you. I hope you do well. And I’m really excited for the revised vision - I actually joined the Discord today.
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.
This looks awesome. Really enjoyed the tech talk (just watched it on YouTube). You present well!
There's 2 problems though:
1. Does the Blitz RPC thing work the same way as TRPC? If so then it will suffer the same slowdown at scale and basically have to be removed once a project reaches a certain size?
2. Having got used to Vite I just cannot go back to Webpack (which IIRC Next still wraps).
> 1. Does the Blitz RPC thing work the same way as TRPC?
Depends what you mean by "same way". Yes in that both provide fully typesafe client-server communication. No in that the Blitz implementation is a tiny fraction of the size and does not have any Typescript-related performance slowdown at scale like TRPC.
The Blitz RPC tech itself will scale forever. However as a company scales it'll probably face another problem which is API contracts between internal teams. When you hit that, you may want to adopt GraphQL.
> 2. Having got used to Vite I just cannot go back to Webpack (which IIRC Next still wraps).
I'd strongly suggest having a direct comparison vs. tRPC page in the documentation. I doubt we're alone in being curious, and this is the real flagship feature.
Since you say Blitz is no longer tied to Next - does that mean it can be used with Vite? Again I doubt I am alone in thinking this would be huge.
I've said it in other comments but to repeat - I think this is super interesting.
Honestly I can't decide whether this is a framework or a feature. But it's definitely interesting.
Unless I'm missing something, Blitz RPC add's zero TS overhead. So the limitation will be the total amount of TS code you have which is not related to Blitz.
By their own admission (or at least those of their advocates who I've paid attention to) tRPC isn't suitable for large projects.
tRPC as I understand it basically serves definition files to the client using a clever misuse of Typescript - but over time that means Typescript has to conditionally evaluate every type in your app to find the correct one. Or something like that.
My understanding of BlitzRPC from their documentation is it's more Svelte-like with the "everything is a magic compiler" philosophy. This may come with issues but it sounds pretty nice.
> with the "everything is a magic compiler" philosophy
Blitz RPC has 1 minimal magic step, which is a webpack step to replace the resolver imports in client code with a fetch function and to add resolvers to the server-side API endpoint.
And we'll be adding an API that lets you use Blitz RPC without webpack or any compile step.
The slowdown occurs in the editor (red squiggles, autocomplete, etc.). tRPC relies heavily on TS inference, which the TS team strongly discourage due to performance concerns.
It's really interesting to see Blitz.js and RedwoodJS coalesce around some of the same shared tools and patterns (i.e. Prisma, deploying backend to lambda functions, etc.)
It makes me feel like we're on the verge of having a really great tool in this space. (Or maybe even two.)
Reading the docs, I'm a fan of your authentication / session management. When anyone pushes JWTs on me, I get sad. Session revoking is a necessary part of any authentication system and making a Redis call doesn't take that long.
However, the downside of custom session managers is that other services might not be able to read/write the created session. For example, I'm currently to get off of Express and onto Fastify. Unfortunately, @fastify/session isn't perfectly compatible with express-session (although I'm working on it). I would have a similar issue if I introduced Next.js + Blitz... Sometimes, I wish there was a shared protocol for sessions between languages/libraries!
As an aside, this is the first time I've heard about Flightcontrol. Super impressed! The biggest con of something like Vercel is that you can't be on your own AWS VPC. An RDS instance with a public IP address (which Vercel's docs endorse) is a dealbreaker for me.
But... wouldn't a Terraform module accomplish something similar? Our own stack is something like Codepipeline + Fargate + ALB + Cloudwatch + Cloudfront and we basically just forked https://github.com/cloudposse/terraform-aws-ecs-web-app
As someone working on a roughly similar product (withcoherence.com), I would highlight a few key reasons to prefer to a TF module:
- maintainability (better to not have to maintain, audit, improve TF and keep up to date with best practices)
- multiple environments (how do you create pipeline, CF distros, etc up to date with all your active branches). Even more - enhancements like using spot instances automatically for test envs. Maybe you already did that improvement or plan to do it, but a good example of where a platform might get ahead of your own fork.
- discoverability/SPOF on team - how do you train a new dev on how to use these tools? much easier to train them on a nice UI. what if the person who forked that TF repo leaves the company?
- integration to other environment types - Coherence is unique in this respect but how does your cloud footprint map to CI/CD testing envs, development envs, etc? Along with other open questions like how do you provide SSH access to the team across environments when needed? More stuff to fork and maintain... With something like Coherence, all of these questions are answered for you in one sane way (we configure a Cloud IDE and Cloud Shell automatically for all your environments)
- Cross-cloud and cross-region support. Migrating your app to another provider or service is easier if supported by the automation tools. Coherence supports GCP and AWS for example.
All in all, buy vs. build is a tough question but generally SaaS wins once it is a viable option for real-world teams. In developer experience, we are still in the early innings on convincing folks it's worth it not to reinvent the wheel in-house.
Would love anyone interested to check out our free trial and feel free to ping hn@withcoherence.com with feedback or questions!
Blitz used to be a fork of next.js, now we're trying to make it a framework agnostic releasing it with support for next.js and other frameworks will be added in the future
How do you set up scheduled background jobs? That's what's preventing me from using Next.js in any projects so I hope Blitz.js can manage that. I don't want to build an app that's only alive when someone is using it. I need stuff to happen without user input.
It seems to be authentication and a graphql alternative for web devs? Why not just say that and have a side by side comparison of graphql and this on the front page? Words like 'scaling world wide applications' strike me as empty.
Blitz is very different. Next.js and Remix are comparable, but Blitz is a toolkit you can use with Next.js (and also Remix once we finish a bit more work). Blitz picks up where Next.js leaves off, providing libraries like a type safe RPC layer and auth and conventions like how to structure your files and how to implement multi-tenet apps.
The one thing that stands out to me as lacking in the Next+Blitz vs Remix comparison is form handling. It's a real pain in the butt if you want to use Next with progressively-enhanced forms - even with helpers like next-runtime you have to roll a lot of the basics like validation and type coercion from form submits yourself.
It feels like it stands out even more because of mutation handlers, which on the Remix side are generally set up as "just" form posts that update after a success.
Great for startups who dont need to worry about the codebase in 10 years. Not so for medium to large companies who are going to be stuck with a rube goldberg machine in 10 years.
If you properly build a large codebase using patterns like Clean Architecture, then tools like Next.js or Blitz should be fully isolated away from your app logic.
If you need auth in Next.js, your options are Blitz Auth or Next Auth. Try both and see which you like best.
If you need type safe client/server communication, Blitz RPC is one of the options.
Neither of these dictate absolute control over your code as your comment implies.
[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