[HN Gopher] Blitz.js - Fullstack Toolkit for Next.js
___________________________________________________________________
Blitz.js - Fullstack Toolkit for Next.js
Author : davidbarker
Score : 105 points
Date : 2022-08-15 13:40 UTC (9 hours ago)
(HTM) web link (blitzjs.com)
(TXT) w3m dump (blitzjs.com)
| yrgulation wrote:
| Cant wait for a new framework "the missing X for blitz.js". Give
| it a week or two.
| snihalani wrote:
| +1. Tried blitz.js. It was too complicated for me
| yrgulation wrote:
| Oh boy, thats a bad omen. If it's complicated and requires
| 10x the effort it will likely get widespread adoption.
| alexashka wrote:
| 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 wrote:
| 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
| alexashka wrote:
| 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.
| xthrowawayxx wrote:
| I have npm fatigue.
|
| Just use the language people!
|
| Writing 3 LOC instead of 1 call to an external package is OKAY.
| stevenpetryk wrote:
| This is not the kind of framework you can casually build and
| maintain yourself to support another project.
| [deleted]
| startupdiscuss wrote:
| 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 wrote:
| Watch the pitch for Blitz over Redwoodjs?
| flybayer wrote:
| 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
| ram_rar wrote:
| 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.
| upupandup wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| upupandup wrote:
| I have no clue what you just wrote here lol and that is
| exactly my point.
| jitl wrote:
| 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.
| gavinray wrote:
| 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.
| lagrange77 wrote:
| Has anyone used it with vite-plugin-ssr?
| quaffapint wrote:
| 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
| zeko369 wrote:
| 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 wrote:
| Is there a roadmap to being able to use it with Vite?
| Kiro wrote:
| 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 wrote:
| Something like Bull might do the job
| (https://github.com/OptimalBits/bull)
| jesuscript wrote:
| I honestly cannot co-sign a framework for a framework, and I say
| this with much love.
| flybayer wrote:
| That's sort of what Blitz used to be, but not anymore
| bluelightning2k wrote:
| Technically the description would have been "framework for a
| framework for a framework".
|
| (Blitz wraps NextJS wraps React)
| mirzap wrote:
| React is NOT a framework.
| flybayer wrote:
| > (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 wrote:
| You probably should have changed the name to avoid
| confusion.
| bluelightning2k wrote:
| I deliberately said "would have been" in the past tense.
| evtothedev wrote:
| 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.)
| temuze wrote:
| 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 wrote:
| 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
| bluelightning2k wrote:
| I think the whole point is you don't have to daisy chain a
| bunch of stuff. It's batteries included.
| zoomzoom wrote:
| 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!
| onion2k wrote:
| _Why use Blitz?_
|
| _1. Next.js is Very Minimal_
|
| That's Next's best feature. I wouldn't want to replace that.
| flybayer wrote:
| 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.
| Jenk wrote:
| Fyi this site is horrific in darkmode on mobile
|
| https://imgur.com/5RXFtrz
| dimgl wrote:
| Yeah I'm getting the same issues on desktop with dark mode.
| [deleted]
| chipgap98 wrote:
| I'm on mobile and the site does not look like that. Might be
| your connection
| stillblue wrote:
| 0.07 KB/S???? Are you okay my dude?!
| numlock86 wrote:
| Pretty sure that's just an live-indicator of what's going on
| at the moment, not what your network limits are.
| bluelightning2k wrote:
| 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 wrote:
| I've never used TRPC but curious to learn more about the
| slowdown. Is that a slowdown with Typescript or a runtime
| thing?
| flybayer wrote:
| Slowdown with Typescript and IDE completion. Not runtime.
| zamalek wrote:
| 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.
| bluelightning2k wrote:
| 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 wrote:
| > 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.
| flybayer wrote:
| > 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
| alexdotjs wrote:
| It won't scale forever. You'll need project references in the
| same way as we need in tRPC on large projects.
| flybayer wrote:
| 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.
| bluelightning2k wrote:
| 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.
| flybayer wrote:
| > 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.
| dang wrote:
| 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)
| vasergen wrote:
| How is the Blitz different from Remix? They both seems to have
| similar goals
| flybayer wrote:
| 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 wrote:
| 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.
| alexdotjs wrote:
| 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)
| flybayer wrote:
| 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
| bluelightning2k wrote:
| 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.
| swyx wrote:
| can you elaborate on the obvious risk?
| flybayer wrote:
| 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.
| senttoschool wrote:
| Can this work with a custom server, IE Express? Or do you have to
| use Next.js backend?
| flybayer wrote:
| 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.
| oxff wrote:
| No wonder all the web guys are abusing amphetamine with higher
| dose than soldiers in WW2.
| jiggywiggy wrote:
| Wow a toolkit over a toolkit over a toolkit. I thought JS was
| getting boring.
| purplerabbit wrote:
| 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)
| o_m wrote:
| 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.
| purplerabbit wrote:
| 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
| DangitBobby wrote:
| This is why I only use operating systems that I have
| personally glued together from scratch.
| purplerabbit wrote:
| 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?
| bluelightning2k wrote:
| 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 wrote:
| You're right on the tone. I've edited it to make it less
| negative.
| bluelightning2k wrote:
| Appreciated! Have an upvote.
| ilumanty wrote:
| > 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?
| ostenning wrote:
| 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.
| matthewmacleod wrote:
| 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.
| revskill wrote:
| Sinatra is good if what u build is minimal in business scope.
___________________________________________________________________
(page generated 2022-08-15 23:02 UTC)