Future of Blitz

I don’t like the pattern of making frameworks <i>less</i> opinionated. I had hoped to use Blitz in the future but this pivot will undoubtably increase the complexity of the internals. Meaning more bugs. More hassle. Somewhere inside there is now a system to multiplex between different 3rd party frameworks. What they should have done is double down. Rails is one of the most popular and longest lasting modern frameworks for a reason.

Next pushes towards serverless functions and API routes that I didn&#x27;t really enjoy using for more than just a trivial endpoint. Blitz is currently built on top of Next so this same issue came up, and its value proposition is really only there if you use Next.<p>I&#x27;m looking forward to this change and using Blitz again, as the frontend experience was super nice.

Relevant discussion about the pivot here: <a href="https:&#x2F;&#x2F;github.com&#x2F;blitz-js&#x2F;blitz&#x2F;discussions&#x2F;3075" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;blitz-js&#x2F;blitz&#x2F;discussions&#x2F;3075</a>

I really enjoyed using blitz for a project.<p>But I&#x27;m tired of the react ecosystem, and I was disappointed I had to give up Blitz&#x27;s features.<p>But thanks to the pivot, I&#x27;m excited to use blitz-auth and their Prisma codegen with other projects.

How will the new model for Blitz compare to tRPC? That’s a way to get a zero-API setup into a variety of frameworks, including Next.<p><a href="https:&#x2F;&#x2F;trpc.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;trpc.io&#x2F;</a>

I guess this is nice for small projects, but for larger ones, the ”zero-API” model seems to prevent team member specialization and force everyone into full-stack mode. Why does the frontend dev need to know database internals?

This is why these new &quot;Rails killers&quot; are a huge risk. Unexpected U turns every now and then. I wouldn&#x27;t trust any of them for a real life project at work.

Just go with Remix of you don&#x27;t want to use Next, is more reliable than Blitz.