Blitz: A Fullstack React Framework, Built on Next.js | Hacker News Reader

Blitz: A Fullstack React Framework, Built on Next.js

github.com

66 pointsmodinfo35 comments

So, this is a framework on top of a framework on top of a framework?

Yes, also bugs on top of bugs on top of bugs. Given that I haven't had a great experience with Next.js and its bugs — a lot of them, and with the usual suggestion of "have you tried the alpha release to see if it has fixed your issue?" — I can only imagine how fun a framework of 3rd order can be when you encounter an issue.

I'm probably just getting old. I see these frameworks by fresh faced frontend developers and I cringe imagining relying on them when you have looming deadlines and complex requirements.

https://npm.anvaka.com/#/view/2d/blitz

Whenever the details are swept under the rug, I feel uneasy. Maybe it’s a need for control, but I feel like not understanding the configuration is not doing yourself any favors when it comes time to debug.

The magic is very minimal and easily inspectable via the network tab of browser dev tools. We essentially just provide a transparent pipe between client and server. Whatever you return from the function on the server is exactly what comes out on the client. We don't interfere with that. All we do is handle all the HTTP stuff for you.

Some have expressed the same concern, but after using it they’ve had zero issues.

I'm sorry about the poor experience with Next.js. Are there any issues in particular I can look into? We frequently cut canary releases to get bug fixes out, so that might have been the suggestion from the team. Regardless, happy to take a look.

I am old and I cringe when I see most of the 'modern stuff'. It is just simply a minefield and dangerous to use. I work in banking and have to sign off on everything used for decades in the future potentially: not much of what is in these frameworks on frameworks on bugs on frameworks qualifies even basic scrutiny but devs do want to use them because they read on hn/reddit it is the new thing. Painful struggle

Edit: I do not mean to say people should stop making new things or trying to improve upon older ideas; just saying most this stuff needs huge ALPHA/experimental stamps on it.

It's partly a reflection of the web and web browsers. Yes, the goal is "don't break the web," but with each new release the odds that a website from "decades in the past" will continue to work today are slim. I don't mean that a simple HTML page won't work, but rather that HTML and other web standards are living - and compatibility often breaks when it's noticed that public web pages don't use features (low adoption) or when features are removed for security or privacy reasons.

When you get used to re-learning everything on a monthly basis, it's easy to adopt new approaches. In fact, the Web Components movement, including lit-element, is basically built on the idea that you should write code for the browser, and thus your codebase must evolve as the browser does. If you look at it from the perspective of "this code must work forever," well, I'm not sure the browser is the right place to be. Have you considered shipping an old and outdated copy of a browser, such as Electron? ;-)

Edit: That said, I do agree there's a lot of reinvent-the-wheel in NPM-land, but I don't think the best possible wheel has been invented yet, so I appreciate having options. TypeScript is a great example: they're continuing to rapidly evolve the language with each point release yet they also centrally maintain DefinitelyTyped to be backwards compatible to previous releases. This means maintainers don't have to manually update their types for each point-release of TypeScript. If you look for that, you'll see a lot of "automatic backwards compatibility" in places. JS Codemods for example, can automatically update minor and sometimes major versions of React. Not everything is pre-1.0 and experimental, but the new stuff is definitely shinier.

In general, I think the web has decent backwards compatibility. With a few exceptions, websites from ten years ago still works fine. The major things that won't work are extensions (NSAPI, Flash, etc) or features that were experimental or obscure at the time.

To me this is actually the big problem. I would love to have a reduced feature set (could be opt-in) in the browser environment. As it stands it's just an ever growing ball of mud that ironically inhibits innovation and makes browsers impossible to develop without a huge amount of effort. It feels like 95% of the APIs are not used on 95% of usage sessions.

Framework on top of a framework using a UI library, but close enough.

Yep, nothing new. It’s abstractions all the way down :)

> ““Zero-API” data layer lets you import server code directly into your React components instead of having to manually add API endpoints and do client-side fetching and caching.“

Sigh… I’m sure the author(s) of this framework mean well and sincerely believe this to be a good thing. I can tell you from having experienced php templates that did stuff like this that this is a terrible idea in practice. Worse, you won’t know it is until you’ve built quite a mess.

Consider for example needing to make a change to a view but your existing view has tons of data access logic embedded right in it. Now consider if there was tons of mission critical data access code inside sub components. Right there you’ve got to do a pretty risky rewrite just to change some UI.

I’m sure it’s possible to use this framework and speak to server concerns in such a way as to keep presentation and business logic concerns separate? but it’s way harder to do at scale. Thin clients are the way to go in pretty much every case I’ve ever encountered.

> your existing view has tons of data access logic embedded right in it.

This is not at all how Blitz is set up to function. Your data access logic is clearly separated into query resolvers that run on the server.

What the "Zero-API" does is in practice is handle all the HTTP stuff for you. So as a developer all you are thinking about is "function calls". The function call happens to occur over the network, but as the dev you don't have to think about the details of how that happens.

> Sigh…

That comes across as very condescending, and took all of my attention away from your actual arguments.

In the space of all the dismissive/abrasive comments on HN, I think the GP ranked pretty low

> I can tell you from having experienced php templates that did stuff like this that this is a terrible idea in practice. Worse, you won’t know it is until you’ve built quite a mess.

We use Blazor in production(admittedly for internal facing app) and it works wonders for us. We mainly share models with frontend part, it's an insane productivity boost. You don't have to embed data access or server business logic into your views. You can, but you don't have to(and you shouldn't). Even just sharing models and calling endpoints like you would call a service is just... convenient.

> Consider for example needing to make a change to a view but your existing view has tons of data access logic embedded right in it.

You can separate these out. Treat public functions from your data/business logic layer as if they were an API in terms of organization. Your views shouldn't be doing any logic, they should be dumb. Overall, we've found switching to a MVC framework for new applications (React/Express -> Phoenix) has increased productivity a lot, especially with a tiny team.

Then again, I'm pretty green, so if there are cases where that kind of separation isn't possible, please let me know!

I tried Blitz ~a year ago. The developers were very friendly and were quick to address an issue I posted on GH.

But I eventually (after ~3 days) switched away. Blitz does what it says it does well, but when you get to that level of abstraction it feels like you lack control of your project. I assume that this level of abstraction would coincide well with newer or less confident developers.

Attempting to signup with a valid email address returned the error:

    node[7117]: ../src/node_http_parser.cc:567:static void
    node::(anonymous namespace)::Parser::Initialize(const
    FunctionCallbackInfo<v8::Value> &): Assertion
    `args[3]->IsInt32()' failed.

... which crashed Node. And later:

    Starting Prisma Studio ...
    Generating Prisma Client ... done
    Prisma Studio is up on http://localhost:5555
    node[9328]: ../src/node_http_parser.cc:567:static void  
    node::(anonymous namespace)::Parser::Initialize(const  
    FunctionCallbackInfo<v8::Value> &): Assertion  
    `args[3]->IsInt32()' failed.
    1: 0x107245c85 node::Abort() [/usr/local/bin/node]

Server restart is also slow now I'm used to esbuild. Overall, not at all impressed.

This is because Prisma doesn’t yet work with Node 16. So not something specific to Blitz.

We have speed improvements on the way.

Might be worth posting a note to that effect on the Getting Started page.

Update: Upgrading to latest prisma fixes this. I'm fixing our new app template as we speak.

Where can I find this? Re-install blitz with npm or git clone?

npm i prisma@latest @prisma/client@latest

I have a small fledgling app that I've been making in blitz for a few weeks now and it's been a pretty lovely experience. The whole api abstraction they've implemented is really dynamite. What attracted me initially to blitz is that it's basically the only ways to do a nodejs app that's fully typed all the way through from db to templates out of the box.

Hmm forgive my ignorance but isn’t having server side code in the client side a high risk security vulnerability?

If I understand correctly, there's some magic involved during compilation, to replace such server-side code imported by the frontend with an API call.

> The new Blitz data layer is a novel technology for eliminating the API while retaining client-side rendering.

> In a Blitz app, you can import your server code directly into the frontend so you don't need to build an API and do data fetching from the frontend.

> At build time, Blitz automatically inserts an API call that runs the server code on the server. Essentially, Blitz abstracts your API into a compile step.

Isn't Next a full stack framework build on React? How does Blitz differ from standard Next?

Yes. Here’s what Blitz adds: https://blitzjs.com/docs/why-blitz

> Isn't Next a full stack framework

It lacks an opinion on backend persistence, and all the supporting framework you'd find in Django/Rails/Laravel/Spring.

522Mb of node_modules. That's some baggage to be carrying around.

We are still pre 1.0. Obviously lots of room for improvment still :)

Please use esbuild if you can. The difference is night 'n day.

Is it any good?

Devs who use it are reporting it's 5-10 times more productive than alternative stacks.

It's still pre 1.0, but we already have thousands of production Blitz projects from users all around the world. Many startups are choosing Blitz because of the fast product iteration speed it enables.

We even are seeing adoption in the enterprise. Algolia now has two internal Blitz apps. They first tried to use AWS Amplify for these projects but switched to Blitz and haven't looked back. And there's a big US university going to production with Blitz shortly.

Here’s a thread of things folks are saying after using Blitz: https://twitter.com/flybayer/status/1361334647859384320

Native support looks promising

Reply on news.ycombinator.com