Blitz.js – Fullstack Toolkit for Next.js(blitzjs.com)
blitzjs.com
Blitz.js – Fullstack Toolkit for Next.js
https://blitzjs.com/
88 comments
FlightControl looks interesting too. Interesting pricing model - to directly & explicitly charge a markup on the underlying managed infrastructure.
There's some obvious risk in your business model but I'm 100% rooting for you.
There's some obvious risk in your business model but I'm 100% rooting for you.
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.
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.
can you elaborate on the obvious risk?
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.
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.
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.
I deploy on AWS AppRunner or Google CloudRun which takes care of the HTTPS/TLS and domain bits.
Heya! Creator of tRPC here. Seen some comments on trpc's ts perf issues.
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)
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)
Cant wait for a new framework “the missing X for blitz.js”. Give it a week or two.
+1. Tried blitz.js. It was too complicated for me
Oh boy, thats a bad omen. If it’s complicated and requires 10x the effort it will likely get widespread adoption.
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.)
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.)
Related:
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)
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)
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?)
/rant
[0] https://wordpress.org/plugins/simply-static/
(edited to remove some unnecessary negativity)
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)
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).
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).
You're right on the tone. I've edited it to make it less negative.
Appreciated! Have an upvote.
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.
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.
Sinatra is good if what u build is minimal in business scope.
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
This is why I only use operating systems that I have personally glued together from scratch.
Leveraging massive libraries is not "from scratch".
Another thought: You are on HN, so you probably prefer Unix to Windows. Why do you think that is?
Another thought: You are on HN, so you probably prefer Unix to Windows. Why do you think that is?
[deleted]
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'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.
> Both popular SSR frameworks (Next.js + Remix) break the Unix philosophy, and Next.js + Blitz.js is the opposite of the Unix philosophy
Would you mind to elaborate?
Would you mind to elaborate?
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.
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).
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).
Yep, I want Next.js to get off webpack too
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).
Yep, I want Next.js to get off webpack too
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.
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.
> I'd strongly suggest having a direct comparison vs. tRPC page in the documentation
Yes, it's coming.
> does that mean it can be used with Vite?
Yes, but we do have a bit more work to clean up our internal package dependencies and APIs so that this works.
Yes, it's coming.
> does that mean it can be used with Vite?
Yes, but we do have a bit more work to clean up our internal package dependencies and APIs so that this works.
I’ve never used TRPC but curious to learn more about the slowdown. Is that a slowdown with Typescript or a runtime thing?
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.
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.
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.
Slowdown with Typescript and IDE completion. Not runtime.
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.)
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!
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
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 [email protected] with feedback or questions!
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 [email protected] with feedback or questions!
I think the whole point is you don't have to daisy chain a bunch of stuff. It's batteries included.
Why use Blitz?
1. Next.js is Very Minimal
That's Next's best feature. I wouldn't want to replace that.
1. Next.js is Very Minimal
That's Next's best feature. I wouldn't want to replace that.
Sorry, bad wording. Just updated that.
Blitz does not replace anything of Next.js. Rather, it compliments it's minimalism.
To build a full app, you need to add a lot of things on top of Next.js. Blitz provides some of those libraries.
Blitz does not replace anything of Next.js. Rather, it compliments it's minimalism.
To build a full app, you need to add a lot of things on top of Next.js. Blitz provides some of those libraries.
[deleted]
The frontpage still lists a tie only to Next.js, but I believe they are trying to redo blitz to be more generic...
https://github.com/blitz-js/blitz/discussions/3075
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
Is there a roadmap to being able to use it with Vite?
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.
Something like Bull might do the job (https://github.com/OptimalBits/bull)
Mergent (YC S21) - https://mergent.co
(disclaimer: I’m the founder)
(disclaimer: I’m the founder)
Can someone explain what this is?
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.
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.
Fair point. Messaging is so hard, we're still working on it.
Here's a side-by-side comparison to GraphQL from some time back: https://twitter.com/flybayer/status/1256957956270120960
Here's a side-by-side comparison to GraphQL from some time back: https://twitter.com/flybayer/status/1256957956270120960
Anything that enters an existing market, has to boldly challenge the competition and win - everything else is a mistake.
If this is a better GraphQL, it better say 'Better GraphQL' and have a side by side comparison, showing how it is obviously so much better.
Messaging is not hard, having a superior product is hard.
If this is a better GraphQL, it better say 'Better GraphQL' and have a side by side comparison, showing how it is obviously so much better.
Messaging is not hard, having a superior product is hard.
I honestly cannot co-sign a framework for a framework, and I say this with much love.
That's sort of what Blitz used to be, but not anymore
Technically the description would have been "framework for a framework for a framework".
(Blitz wraps NextJS wraps React)
(Blitz wraps NextJS wraps React)
> (Blitz wraps NextJS wraps React)
Again I repeat, that is what Blitz used to be. Blitz no longer wraps Next.js. It's no longer a framework.
Again I repeat, that is what Blitz used to be. Blitz no longer wraps Next.js. It's no longer a framework.
I deliberately said "would have been" in the past tense.
You probably should have changed the name to avoid confusion.
React is NOT a framework.
Wow a toolkit over a toolkit over a toolkit. I thought JS was getting boring.
Fyi this site is horrific in darkmode on mobile
https://imgur.com/5RXFtrz
https://imgur.com/5RXFtrz
I'm on mobile and the site does not look like that. Might be your connection
Yeah I'm getting the same issues on desktop with dark mode.
[deleted]
Can this work with a custom server, IE Express? Or do you have to use Next.js backend?
The whole idea is that you can do that, but we still have a bit more work to clean up internal package dependencies to make that nice.
The goal for beta was to reach Next.js production feature parity with legacy Blitz. Now we can turn to cleaning it up for other uses.
The goal for beta was to reach Next.js production feature parity with legacy Blitz. Now we can turn to cleaning it up for other uses.
How is the Blitz different from Remix? They both seems to have similar goals
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.
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.
Watch the pitch for Blitz over Redwoodjs?
In simple terms: If you want to use GraphQL, use Redwood. If you want type safe client-server communication without GraphQL, then use Next.js + Blitz
Has anyone used it with vite-plugin-ssr?
No wonder all the web guys are abusing amphetamine with higher dose than soldiers in WW2.
I have npm fatigue.
Just use the language people!
Writing 3 LOC instead of 1 call to an external package is OKAY.
Just use the language people!
Writing 3 LOC instead of 1 call to an external package is OKAY.
This is not the kind of framework you can casually build and maintain yourself to support another project.
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.
Everyone love's a skeptic :)
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.
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.
I have no clue what you just wrote here lol and that is exactly my point.
> tools like Next.js or Blitz should be fully isolated away from your app logic
Should they? For small startups it might be better to skip paying the cost of such abstraction and just marry with a mature technology.
Should they? For small startups it might be better to skip paying the cost of such abstraction and just marry with a mature technology.
[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