will Payload support Remix?

[jesse996]

I very like Payload, but wonder will it support Remix in the future? Next.js tied with Vervel too much,Remix support other plateform like cloudflare,so i wish payload support Remix in the future, Thank you!

[BohdanK-W32]

You can use any framework for your app/website, but Payload is Next.js based for now, and I don't think, that it will change in the further years.

P.S.: You can use multiple frameworks for your app, so it's not a blocker. However, Next.js is really too tied with Vercel, and that's an issue...

[AndKenneth]

Payload is first and foremost a headless CMS - that means you're running two seperate applications, a user facing app, and a backend admin app. Payload is the latter.

Before 3.0, payload and your user facing site were entirely seperate in all cases, and you'd use the GraphQL or REST API in your user facing application to get the data from payload, just like any other headless CMS. Next, Remix, Astro, or almost any other framework can be the basis for the user facing app because these are open standards.

Because 3.0 is written on top of nextjs, there's a special feature where you can install the payload instance into the same project as your user facing app, which gives you access to a local API on top of GQL and REST. This is totally optional and just really nice if you're a NextJS shop already.

Worth noting that before 3.0 it wasn't possible to host payload on any serverless platform because it required a long running express server. Just like any other next app, it works on most serverless platforms and can always just run as a standalone process if you're all in on the $5 vps lifestyle.

[fecony]

Taking into account v3 payload now is living in codebase, and it seems like it should and can be framework agnostic :/
Remix, Astro etc all have folder structure and http route handlers that could just do what payload has to do based on Web Standard's Request/Response

And Remix itself has express running..

[alsherif-khalaf]

are there any instructions how to make payload works inside remix project ?

[fecony]

are there any instructions how to make payload works inside remix project ?

no. And I didn't investigate how tied it is to nextjs since they moved to it to see whole picture

[judocode]

It would be nice if Payload was framework agnostic. I find Next.js to be very slow and consumes a lot of memory especially when compared to something much more lightweight like Remix.

[trangcongthanh]

but you can't build the Admin UI

Then it is not framework-agnostic. What you mean is fetching data, we are talking about payload living in our apps, not as separate nextjs app that we fetch data from

A framework-agnostic admin UI that is as battery-included doesn't exist and probably never will.

Do you count keystatic.com? It can work with NextJS, Remix and Astro with built-in AdminUI 🤔

[tyteen4a03]

but you can't build the Admin UI

Then it is not framework-agnostic. What you mean is fetching data, we are talking about payload living in our apps, not as separate nextjs app that we fetch data from

A framework-agnostic admin UI that is as battery-included doesn't exist and probably never will.

Do you count keystatic.com? It can work with NextJS, Remix and Astro with built-in AdminUI 🤔

Oh true, forgot that existed. I imagine it won't be able to take advantage of the optimizations Next.js provides.

[judocode]

Oh true, forgot that existed. I imagine it won't be able to take advantage of the optimizations Next.js provides.

What optimizations? I have a hard time believing Next.js has any distinct advantages over something like Remix that are useful to a project like Payload.

Next.js is an unfortunate choice. If I may offer a short list of its downsides:

• High memory, CPU, and energy consumption. 10x more than something like Remix
• Slow dev server. Also an order of magnitude slower when measuring initial load time, page loads, page transitions, etc.
• Slow production build times.
• Difficultly setting it up in prod on non-Vercel production server in a way that can actually take advantage of Next.js's production optimizations which are pretty tailored for Vercel architecture and it's not clear that Payload is taking advantage of these.

Next.js is already tip-toeing as commercial software, so I would think this is an existential risk to a project like Payload because of its interest in essentially being a competitor to Vercel in cloud architecture.

Thanks for reading my critiques. Maybe framework-agnostic isn't feasible, but Next.js feels like not a great decision to go all in on.

[fecony]

but Next.js feels like not a great decision to go all in on.

That whole transition feels like someone just found out Next.js, that it has features they wouldn't have to maintain on their own and stopped there without further investigation

[trangcongthanh]

Next.js is an unfortunate choice. If I may offer a short list of its downsides:

I'm not sure about other people's experience with Next.js, but for me, working with it feels like riding a roller coaster. 😫 Everything works fine in development mode, but it breaks in production. 😄

[r1tsuu]

Just made an example with Remix - #10171.

[fecony]

It's not what we are talking about

[r1tsuu]

Payload admin panel itself won't work in Remix because we're relying on Next.js features like RSC and its bundler, this is practically impossible for our small team to build a framework-agnostic admin panel
Payload REST API - maybe, we had some conversations about making it framework agnostic with an adapter pattern, like TRPC does for example.

This example, still shows you how you can benefit from the Local API in your Remix app

[fecony]

Payload cms could have been a vite plugin 🤷

Maybe someone will have time to look into that. Maybe some features are blocking this. But in it's core it's just admin panel layout where we manage data. Even simple HTML with jQuery would do, as already mentioned there are other cms that are working, but of course, they are not that advanced as Payload is...

[judocode]

I think it makes sense to choose a framework to go all-in on, I just think Next.js is the worst to choose for very practical concerns I've laid out in this comment.

Just to highlight its performance issues alone, it has direct impact on a developer's experience, development speed, the lifespan of a development machine, and the cost to deploy/host (eg if I pay for a CI runner and a Next.js build takes 10x longer than normal, which it does, I have to pay up to 10x costs in CI).

This slowness and extremely high memory usage is well-documented in long-running issues and large companies have been migrating off of Next.js for these and other reasons I've outlined. See the following threads (or simply observe yourself and compare it to others):

• Dev mode slow compilation
• Next.js development high memory usage

I know my words have the chance to fall on deaf ears, and maybe the Payload team feels this is an irreversible decision, but you have to consider this will have consequences where Payload now inherits all of Next's problems, its customer frustrations, and Payload will have to field Next issues that they've historical been unwilling and/or unable to fix.

[janus-reith]

Hopefully this might help: facebook/react#31768