11 ms·

Blitz.js – Fullstack Toolkit for Next.js

119 points by davidbarker 4y ago

Jenk 4y ago
Fyi this site is horrific in darkmode on mobile https://imgur.com/5RXFtrz https://imgur.com/5RXFtrz
- chipgap98 4y ago
  I'm on mobile and the site does not look like that. Might be your connection
- stillblue 4y ago
  0.07 KB/S???? Are you okay my dude?!
  - numlock86 4y ago
    Pretty sure that's just an live-indicator of what's going on at the moment, not what your network limits are.
- deleted 4y ago
  [deleted]
- dimgl 4y ago
  Yeah I'm getting the same issues on desktop with dark mode.
vasergen 4y ago
How is the Blitz different from Remix? They both seems to have similar goals
- flybayer 4y ago
  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.
  - crooked-v 4y ago
    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.
yrgulation 4y ago
Cant wait for a new framework “the missing X for blitz.js”. Give it a week or two.
- snihalani 4y ago
  +1. Tried blitz.js. It was too complicated for me
  - yrgulation 4y ago
    Oh boy, thats a bad omen. If it’s complicated and requires 10x the effort it will likely get widespread adoption.
  - XCSme 4y ago
    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.
quaffapint 4y ago
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 https://github.com/blitz-js/blitz/discussions/3075
- zeko369 4y ago
  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
  - bluelightning2k 4y ago
    Is there a roadmap to being able to use it with Vite?
jitl 4y ago
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.
- sambeau 4y ago
  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?
- gavinray 4y ago
  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.
flybayer 4y ago
Hello, I'm the creator of Blitz.js [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 https://github.com/blitz-js/blitz/releases/tag/v2.0.0-beta.1
- bluelightning2k 4y ago
  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.
  - flybayer 4y ago
    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.
  - 4y ago
upupandup 4y ago
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.
- flybayer 4y ago
  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.
  - hu3 4y ago
    > 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.
  - i_love_cookies 4y ago
  - upupandup 4y ago
    I have no clue what you just wrote here lol and that is exactly my point.
jesuscript 4y ago
I honestly cannot co-sign a framework for a framework, and I say this with much love.
- flybayer 4y ago
  That's sort of what Blitz used to be, but not anymore
  - bluelightning2k 4y ago
    Technically the description would have been "framework for a framework for a framework". (Blitz wraps NextJS wraps React)
    - flybayer 4y ago
      > (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.
      - heartbreak 4y ago
        You probably should have changed the name to avoid confusion.
      - bluelightning2k 4y ago
        I deliberately said "would have been" in the past tense.
    - mirzap 4y ago
      React is NOT a framework.
onion2k 4y ago
Why use Blitz? 1. Next.js is Very Minimal That's Next's best feature. I wouldn't want to replace that.
- flybayer 4y ago
  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.
jiggywiggy 4y ago
Wow a toolkit over a toolkit over a toolkit. I thought JS was getting boring.
lagrange77 4y ago
Has anyone used it with vite-plugin-ssr?
bluelightning2k 4y ago
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).
- emptysea 4y ago
  I’ve never used TRPC but curious to learn more about the slowdown. Is that a slowdown with Typescript or a runtime thing?
  - flybayer 4y ago
    Slowdown with Typescript and IDE completion. Not runtime.
  - bluelightning2k 4y ago
    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.
    - flybayer 4y ago
      > 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.
  - zamalek 4y ago
purplerabbit 4y ago
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/ https://wordpress.org/plugins/simply-static/ (edited to remove some unnecessary negativity)
- bluelightning2k 4y ago
  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).
  - purplerabbit 4y ago
    You're right on the tone. I've edited it to make it less negative.
temuze 4y ago
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!
- temuze 4y ago
  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 https://github.com/cloudposse/terraform-aws-ecs-web-app
  - bluelightning2k 4y ago
    I think the whole point is you don't have to daisy chain a bunch of stuff. It's batteries included.
  - zoomzoom 4y ago
    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!
senttoschool 4y ago
Can this work with a custom server, IE Express? Or do you have to use Next.js backend?
- flybayer 4y ago
  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.
alexashka 4y ago
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.
- flybayer 4y ago
  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 https://twitter.com/flybayer/status/1256957956270120960
  - alexashka 4y ago
    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.
deleted 4y ago
[deleted]
Kiro 4y ago
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.
- lxe 4y ago
  Something like Bull might do the job (https://github.com/OptimalBits/bull https://github.com/OptimalBits/bull)
- jamescmartinez 4y ago
  Mergent (YC S21) - https://mergent.co https://mergent.co (disclaimer: I’m the founder)
evtothedev 4y ago
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.)
startupdiscuss 4y ago
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.)
throwayyy479087 4y ago
Watch the pitch for Blitz over Redwoodjs?
- flybayer 4y ago
  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
xthrowawayxx 4y ago
I have npm fatigue. Just use the language people! Writing 3 LOC instead of 1 call to an external package is OKAY.
- stevenpetryk 4y ago
  This is not the kind of framework you can casually build and maintain yourself to support another project.
dang 4y ago
Related: Future of Blitz - https://news.ycombinator.com/item?id=30896931 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 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 https://news.ycombinator.com/item?id=26166716 - Feb 2021 (78 comments)
oxff 4y ago
No wonder all the web guys are abusing amphetamine with higher dose than soldiers in WW2.
ram_rar 4y ago
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.
alexdotjs 4y ago
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/pages/Project%20References.md 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#writing-easy-to-compile-code 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)

119 points by davidbarker 4y ago

Jenk 4y ago

Fyi this site is horrific in darkmode on mobile https://imgur.com/5RXFtrz https://imgur.com/5RXFtrz

chipgap98 4y ago
I'm on mobile and the site does not look like that. Might be your connection
stillblue 4y ago
0.07 KB/S???? Are you okay my dude?!
- numlock86 4y ago
  Pretty sure that's just an live-indicator of what's going on at the moment, not what your network limits are.
deleted 4y ago
[deleted]
dimgl 4y ago
Yeah I'm getting the same issues on desktop with dark mode.

vasergen 4y ago

How is the Blitz different from Remix? They both seems to have similar goals

flybayer 4y ago
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.
- crooked-v 4y ago
  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.

yrgulation 4y ago

Cant wait for a new framework “the missing X for blitz.js”. Give it a week or two.

snihalani 4y ago
+1. Tried blitz.js. It was too complicated for me
- yrgulation 4y ago
  Oh boy, thats a bad omen. If it’s complicated and requires 10x the effort it will likely get widespread adoption.
- XCSme 4y ago
  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.

quaffapint 4y ago

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 https://github.com/blitz-js/blitz/discussions/3075

zeko369 4y ago
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
- bluelightning2k 4y ago
  Is there a roadmap to being able to use it with Vite?

jitl 4y ago

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.

sambeau 4y ago
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?
gavinray 4y ago
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.

flybayer 4y ago

Hello, I'm the creator of Blitz.js [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 https://github.com/blitz-js/blitz/releases/tag/v2.0.0-beta.1

bluelightning2k 4y ago
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.
- flybayer 4y ago
  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.
- 4y ago

upupandup 4y ago

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.

flybayer 4y ago
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.
- hu3 4y ago
  > 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.
- i_love_cookies 4y ago
- upupandup 4y ago
  I have no clue what you just wrote here lol and that is exactly my point.

jesuscript 4y ago

I honestly cannot co-sign a framework for a framework, and I say this with much love.

flybayer 4y ago
That's sort of what Blitz used to be, but not anymore
- bluelightning2k 4y ago
  Technically the description would have been "framework for a framework for a framework". (Blitz wraps NextJS wraps React)
  - flybayer 4y ago
    > (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.
    - heartbreak 4y ago
      You probably should have changed the name to avoid confusion.
    - bluelightning2k 4y ago
      I deliberately said "would have been" in the past tense.
  - mirzap 4y ago
    React is NOT a framework.

onion2k 4y ago

Why use Blitz? 1. Next.js is Very Minimal That's Next's best feature. I wouldn't want to replace that.

flybayer 4y ago
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.

jiggywiggy 4y ago

Wow a toolkit over a toolkit over a toolkit. I thought JS was getting boring.

lagrange77 4y ago

Has anyone used it with vite-plugin-ssr?

bluelightning2k 4y ago

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).

emptysea 4y ago
I’ve never used TRPC but curious to learn more about the slowdown. Is that a slowdown with Typescript or a runtime thing?
- flybayer 4y ago
  Slowdown with Typescript and IDE completion. Not runtime.
- bluelightning2k 4y ago
  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.
  - flybayer 4y ago
    > 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.
- zamalek 4y ago

purplerabbit 4y ago

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/ https://wordpress.org/plugins/simply-static/ (edited to remove some unnecessary negativity)

bluelightning2k 4y ago
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).
- purplerabbit 4y ago
  You're right on the tone. I've edited it to make it less negative.

temuze 4y ago

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!

temuze 4y ago
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 https://github.com/cloudposse/terraform-aws-ecs-web-app
- bluelightning2k 4y ago
  I think the whole point is you don't have to daisy chain a bunch of stuff. It's batteries included.
- zoomzoom 4y ago
  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!

senttoschool 4y ago

Can this work with a custom server, IE Express? Or do you have to use Next.js backend?

flybayer 4y ago
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.

alexashka 4y ago

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.

flybayer 4y ago
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 https://twitter.com/flybayer/status/1256957956270120960
- alexashka 4y ago
  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.

deleted 4y ago

[deleted]

Kiro 4y ago

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.

lxe 4y ago
Something like Bull might do the job (https://github.com/OptimalBits/bull https://github.com/OptimalBits/bull)
jamescmartinez 4y ago
Mergent (YC S21) - https://mergent.co https://mergent.co (disclaimer: I’m the founder)

evtothedev 4y ago

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.)

startupdiscuss 4y ago

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.)

throwayyy479087 4y ago

Watch the pitch for Blitz over Redwoodjs?

flybayer 4y ago
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

xthrowawayxx 4y ago

I have npm fatigue. Just use the language people! Writing 3 LOC instead of 1 call to an external package is OKAY.

stevenpetryk 4y ago
This is not the kind of framework you can casually build and maintain yourself to support another project.

dang 4y ago

Related: Future of Blitz - https://news.ycombinator.com/item?id=30896931 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 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 https://news.ycombinator.com/item?id=26166716 - Feb 2021 (78 comments)

oxff 4y ago

No wonder all the web guys are abusing amphetamine with higher dose than soldiers in WW2.

ram_rar 4y ago

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.

alexdotjs 4y ago

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/pages/Project%20References.md 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#writing-easy-to-compile-code 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)