[HN Gopher] Blitz.js Now in Beta (Batteries Included Framework B...
___________________________________________________________________
Blitz.js Now in Beta (Batteries Included Framework Built on
Next.js)
Author : flybayer
Score : 129 points
Date : 2021-02-17 14:38 UTC (6 hours ago)
(HTM) web link (blitzjs.com)
(TXT) w3m dump (blitzjs.com)
| aericson wrote:
| Amazing how fast this is moving, congrats! Looking forward to
| seeing it being used more broadly.
|
| Just saw that they have links to "Made with blitz" on their wiki
| in case anyone is interested: https://github.com/blitz-
| js/blitz/wiki#-made-with-blitz-incl...
| supert56 wrote:
| I hadn't heard of Blitz until now but am loving the look of it.
| Congrats on the beta!
| xeon06 wrote:
| Been using in hobby projects for a bit now, absolutely fantastic
| framework, especially the data handling. It also gives you a few
| goodies by default that Next.js doesn't.
| helloiloveyou wrote:
| Amazing!! The idea to generate an API when compiling is very
| good.
|
| The only thing that is holding me back is that as far as I
| understand Prisma doesn't support cascading deletes.
|
| Meaning that if I have to delete a user, then I have to manually
| delete all his projects, comments, posts, etc... which is not
| nice.
| quaffapint wrote:
| You could just setup the CASCADE in the DB and it will handle
| cascading deletes. They have docs on it...
|
| https://www.prisma.io/docs/guides/general-guides/database-wo...
| asidiali wrote:
| Awesome work! Love the stack.
|
| How does this compare with Supabase?
| flybayer wrote:
| There's a bit of overlap with Supabase because they are
| positioned as "open-source firebase". But you can just use
| Supabase as the DB provider for your Blitz app.
|
| In general, I'm way more in favor of owning your entire stack,
| like Ruby on Rails and Laravel vs relying on a third-party
| service for the core of your app.
| asidiali wrote:
| Makes sense, thanks for the reply and congrats on Beta
| iyn wrote:
| I've been tinkering with redwood.js for the last couple of
| months. I quite like it and it definitely speeds things up,
| compared to rolling out everything yourself. But since this is
| alpha-grade, there have been a lot of breaking changes -- which I
| totally understand, but it's been PITA to work on upgrades vs my
| side project. To the point: how does the upgrade situation looks
| like with Blitz.js? What are the plans for breaking changes now
| that's in a beta? Also, what would be the biggest differences
| between redwood & blitz (besides blitz being based on next)?
|
| Lastly, thank you for working on this project/problem, definitely
| a lot of potential here. I've also seen that you really care
| about the community around the project, which is awesome!
| flybayer wrote:
| We expect only minimal breaking changes to Blitz from here on.
| 1.0 is expected in April.
|
| The biggest difference between Blitz and Redwood is that
| Redwood makes the API layer easier with conventions and APIs,
| whereas Blitz abstracts away the entire thing into a compile
| step. So working with Redwood requires working with APIs like
| normal. But with Blitz you can almost forget an API is even
| there.
| iyn wrote:
| Thanks, 1.0 being just around the corner definitely makes me
| more interested!
|
| As for the redwood vs blitz, I think I get what you're
| getting at but still not fully grok what _exactly_ it
| means/looks like (and what are the tradeoffs). I'll
| experiment with it, so I can develop the intuition myself :).
| snarkypixel wrote:
| "But with Blitz you can almost forget an API is even there."
|
| How does it work for clients using an old version of the app?
| I.e. if I change the db schema and update it for new clients,
| what will happen to older clients?
| flybayer wrote:
| It works the same as any other fullstack web app
| (possibility for discrepancies). We'll add a hook/API that
| allows you to easily detect if a new version is deployed
| and handle this gracefully by e.g. notifying the user.
|
| I'd also like to go even further and add some type of
| detection to the build that would notify you of potential
| issues.
| kevincox wrote:
| Notifying the user isn't graceful.
|
| "Hi, we can't handle any version skew so please interrupt
| what you are doing to click this button and reload the
| app."
| cwackerfuss wrote:
| makes sense. could also explore versioned routing, where
| you detect multiple versions based on filename (e.g.
| *_v1), folder name, or some export naming convention.
| flybayer wrote:
| Yes, good idea!
| jrumbut wrote:
| This sounds very cool but the code sample on the front page
| didn't have instant appeal for me.
|
| Once I Googled a little and found out what it was doing it looked
| awesome, but it was very noisy if you don't know the components
| of Blitz.
|
| Compare it to this code from early in the ActiveRecord guide:
|
| "class Product < ApplicationRecord
|
| end"
| chaostheory wrote:
| Does blitz have typescript support? I've looked everywhere on the
| site and there's no mention which is a bad sign. It's too hard to
| build large apps with vanilla JavaScript
| quaffapint wrote:
| It's on the bottom of their front page... First Class
| Typescript Support Blitz is built with Typescript and the Blitz
| data layer is fully end-to-end typesafe. All types are
| completely static without needing a separate type generation
| process!
| chaostheory wrote:
| Not sure how I missed that on mobile.
|
| Then this is my dream framework
| randtrain34 wrote:
| I've tinkered with this in side projects and it's really a joy to
| work with. The setup for a basic CRUD app w/ GraphQL and
| Auth/plugins/CSS frameworks takes ~1minute, and the generated
| code is pretty extensible.
| quaffapint wrote:
| The one thing that was holding me back from going forward with
| Blitz is the rapid amount of changes, so this is very exciting.
| I'm using NextJS with NextAuth and Prisma right now, but I want
| it more integrated with more of a server aspect to host. Blitz is
| such a great idea.
|
| Congrats on the beta!
| akbar501 wrote:
| TL;DR Give Blitz a try.
|
| I've been developing my app with Blitz. It has been an extremely
| productive framework to work with.
|
| The following are a few of the productivity boosts that I like:
|
| 1. It includes authentication plus there's a good library for
| authorization (blitz-guard) so auth is a breeze.
|
| 2. The generator is helpful when I started with Blitz, but use it
| less now.
|
| 3. The community is friendly and helpful. ex. Check out this post
| on skeleton loaders https://andreas.fyi/engineering/nextjs-auth-
| skeleton-loaders
|
| 4. The integration with Prisma is buttery smooth. In your UI code
| you call a function that has the database access. Blitz converts
| the function calls into API calls and runs your database code on
| the server. When Prisma is not enough you can drop to
| `db.$queryRaw` to write SQL directly.
|
| 5. Personally, I dislike fiddling with 800 libraries to get a
| project up and running. Blitz includes Jest, Prettier, and
| everything else you need so on so that you're productive from day
| 1.
| jacktheturtle wrote:
| Been dabbling with this framework back and forth. Excited to see
| it in a stable spot. Finally gonna build a medium sized project
| on it now.
| [deleted]
| jack_riminton wrote:
| I love how similar this is to Rails, specifically the generate
| commands.
|
| I'm going to enjoy playing with this! well done
| dyeje wrote:
| > At build time, that function import is swapped out with an auto
| generated HTTP API.
|
| This was surprising to me, I thought it would be focused on SSR.
| quaffapint wrote:
| he
| cwackerfuss wrote:
| I have been a tad skeptical about how Blitz.js would accomplish
| "batteries-included" elegantly, but 5 min into reading the (very
| thorough) docs and it seems like a fantastic amount of
| abstraction to work with. You're a genius flybayer!
|
| 2 questions:
|
| 1. How the docs read right now, I'm cautious about the "recipes"
| concept. It's not clear why I'd need to use a recipe to install
| Tailwind instead of installing Tailwind via NPM. I'd love the
| docs to explain what "coupling," if any, occurs with Blitz <> a
| recipe's dependencies, so I can better understand what I'm opting
| into by choosing the framework.
|
| 2. Is there a roadmap for API-only implementation, like Rails? If
| I want to use some of my Blitz endpoints from another client is
| that possible?
|
| Thanks!
| flybayer wrote:
| Ha, thank you!
|
| > Re: recipes
|
| You don't have to use recipes. Recipes simply package a number
| of manual steps into a single automated command. Recipes let
| you install a library without looking up the install docs.
|
| Recipes are roughly "install dependencies + codemods". So for
| example the `chakra-ui` recipe installs the needed dependencies
| and adds the theme provider to your app root.
|
| There's currently zero coupling with recipes. The end result is
| exactly the same as if you did everything manually.
|
| > Re: API-only
|
| Currently you can do that. You can use the API routes (which
| give you direct access to Node req, res objects. And don't add
| any pages (or just a few, as you want).
| cwackerfuss wrote:
| Sweeet. I could actually see Blitz being really useful as an
| admin interface over an API, where the generated API drives
| web/mobile apps.
___________________________________________________________________
(page generated 2021-02-17 21:01 UTC)