33 comments

[ 2.2 ms ] story [ 73.9 ms ] thread
Just go with Remix of you don't want to use Next, is more reliable than Blitz.
What reliability issues did you have with Blitz?
SvelteKit is way too good- anything React based feels like too much of a downgrade.
I'm not familiar with SvelteKit.

Can you provide more details about this? In what way is it a downgrade?

I played around with Next.js and SvelteKit. I don't recall the specific "that's a down/upgrade" but I switched to SvelteKit because "it just works". HMR, more or less plain HTML, (Tailwind) CSS and JS. Developing with Svelte(Kit) feels, and probably is faster than NextJS/React.

The only downside are missing UI libraries like RadixUI. Tried out everything and just "wasted" 2 weeks to build a component library on top of TailwindCSS inspired by Material UI.

SvelteKit comes navigation, sane state management, optional Server Side Rendering, Hot Module Reloading and super-fast pipeline with Vite. And some extra goodies like built-in animation utilities, debouncing, auto-prefetch links on hover, etc...

Its reactivity features are simpler.

And it is much more performant on the browser.

Plus React has steeper learning curve.

Then you'd have to use Svelte which not many organizations will, as React is more mature and Svelte is newer. Perhaps in a few years that will change but IMO moving to SvelteKit is orthogonal, most who are currently using React will want to continue using React based frameworks.
I don’t like the pattern of making frameworks less 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.
Blitz is not becoming less opinionated. It’s just the implementation that is changing.

The internals are significantly less complex now. Before, Blitz was a fork of Next.js, and dealing with that was a nightmare. Contributions dropped off significantly because of that.

Now features are nicely packaged and isolated. Much easier to reason about and contribute too.

Forking NextJS does sound like a huge hassle to maintain. Having a bunch of separated facade packages with some 1st party additional functionality is how I'd do it, too. But also allowing for multiple back-ends increases the breadth of the code base and in places where one package supports multiple back-ends you get increased complexity.
Next pushes towards serverless functions and API routes that I didn'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.

I'm looking forward to this change and using Blitz again, as the frontend experience was super nice.

> Next pushes towards serverless functions and API routes that I didn't really enjoy using for more than just a trivial endpoint.

By default (through `next start`) Next.js uses a Node.js server. You don't need to use Next.js serverless: https://nextjs.org/docs/deployment#self-hosting

Most large applications don't use API Routes for large workloads. These teams likely have a completely separate backend/API, and Next.js is the connecting piece for their frontend. For smaller teams, or solo devs, it's more common to see their entire backend built with API Routes (most commonly used with something like Prisma): https://github.com/vercel/nextjs-subscription-payments

(comment deleted)
I should've phrased it as all in on Next really. I really like Vercel and Next.js serverless for hosting, and I've usually put APIs on a subdomain. The issue is that then using Blitz for authentication and rpc layer becomes very hard to do.
Hmm. IME, there are significant benefits to a BFF (Backend For Frontend), ie Next.js /api routes, even (or especially?) in the presence of a separate external API.
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?
The zero-API model doesn’t prevent specialization at all. You can add as many distinct domain layers as you want with different teams responsible for different layers.
> for larger ones, the ”zero-API” model seems to prevent team member specialization and force everyone into full-stack mode.

What is "full-stack mode" specifically? Do you mean the fact that each dev needs to run all parts of the application locally? You'd want that for most small and medium size web projects anyway, even if it e.g. consisted of stricly separated SPA and REST backend parts.

With very large projects/teams there are obviously challenges. My gut feeling is that a project started with a framework like Blitz would probably naturally evolve into some kind of a monorepo, which of course comes with both strengths and challenges. If you get that far though it'd seem to me that the full-stack architecture worked really well for the problem.

I really enjoyed using blitz for a project.

But I'm tired of the react ecosystem, and I was disappointed I had to give up Blitz's features.

But thanks to the pivot, I'm excited to use blitz-auth and their Prisma codegen with other projects.

Why are you tired of the React ecosystem?
Needless complexity, heavy weight, high cognitive load if you're doing it right (most people still don't use hooks) and bottom line holy shit its just frontend, how did we get to this point?
To what point? It's still better than doing WPF apps and comparable to making QML apps. There's no magic sauce that makes frontend easy.

The complexity of web pages has increased. Development is not harder. We're making complex apps and not just styled documents now. What you made 10 years ago is much easier to do today.

Cancer is still better than dying
Presentational logic is hard, and while each ecosystem has settled into an all-rightish presentational UI (i.e. React, UI kit) - we still haven't figured out how to pair it with state in a way that doesn't require a massive amount of duplicative effort.

I'm really hoping for some kind of Rust/WebAssembly kit for write-once manage-state everywhere bundles that you can deploy to native presentational applications on every platform. Kind of like grpc but also tying in authentication and intuitive hooks into component logic.

(comment deleted)
What do you have against WPF? They were really onto something with trying to remake HTML into an extensible language of their own.

Hacking together HTML today with React, Angular, and VueJS just seems like no one wants to admit that HTML needs to be rebuilt and JS deserves to be replaced.

I'm pretty excited about trying HTMX lately, have you heard of it or tried it?
WPF is not bad, but I like dev experience of React much better - I'm able to iterate on solution quicker, and the Chrome devtools are very good too.

Yeah it's a hack on top of HTML, but there's React Native too. Which is kind of a hack too, but it's going towards the right direction IMHO.

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.

https://trpc.io/

It’ll be similar. Same result, but very different DX flavor.

Also, new Blitz includes a plugin system, that allows you to easily integrate multiple modules, for example auth and RPC and have them work together seamlessly. And have things just work like you’d expect, such as query cache being deleted on log out, and queries refetched on log in.

Huh - interesting. I built something similar at work. I didn't do a perfect job - you need to manually write in an endpoint spec that points to each controller method. For example:

    /**
     * Add new survey answer.
     */
    // prettier-ignore
    export type AddSurveyAnswer = PostEndpoint<`/survey/survey-answer/${string}`, never, Validators.SurveyAnswerBody, ResponseDataType<typeof SurveyController, "addSurveyAnswer">>;
But really the only duplicated information is the HTTP verb and the path. And those won't change very often - if at all.

Then in the front end you import the file containing all of the endpoint types:

    import * as API from "@copy-ai/endpoints";
And you're good to make requests:

    const response = await request<API.AddSurveyAnswer>({
      url: `/survey/survey-answer/${questionId}`,
      method: "post",
      data: surveyAnswerBody,
    });
You might wonder - why are you making me retype the URL/method? You don't really have to. Your editor will auto-fill that as the method can be extracted from the endpoint type as the type "post". Not a string - "post". Same for the path, but we use parameterized string types.

There's no magic here. What's happening is pretty transparent to the programmer. We just tuck away the PostEndpoint etc. types as those don't ever need to get changed. You can even easily YOLO an API request by passing in the any type.

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