already working on migrating off payload. I don't want to deal with additional abstractions on top of data. we use next js for some stuff that consume payloads data, but don't want our apis linked to a particular framework.
Probably a month or so. I did a PoC earlier this week and it went very well. We'd likely go hard on making the move for ~1 month, and then release 3.0 as beta, letting it cook as beta for like 2 months prior to releasing a full 3.0.
I am good with next.js app router but it feels so unstable. I want to try my next project without using next.js (no pun intended). I have not tried payload cms yet, but I want to give it a try. If next.js works for you, that's ok. I hope you will not get stuck with it as next.js decisions are not 100% satisfying for everybody. But this is just a way of life lol
Any consideration for SvelteKit? Or anything other than Next.JS? EDIT: what about rewriting the whole admin UI in Svelte so that I specifically can have a nice admin UI written in Svelte that does the exact same thing as the React one? I love Svelte
That would be a big move and would require the rewrite of our entire admin panel. I don't think that will happen in the immediate future. React serves our admin UI well, so unless something catastrophic happened to the React ecosystem in general, we'll probably continue to build on React. That's not to say an admin UI for Payload couldn't be built with SvelteKit! Could be a cool community project.
@@JamesMikrut I appreciate the genuine response you've given, you've got patience that I haven't. I was just joking (hence the edit) about how anal some people are about tech stacks Loving using Payload, you and the Payload team are doing a phenomenal job with it
Putting some more here: I find next.js extremely frustrating to work with. It's great for a demo but the warts suck so bad. Everything is "magical" until it breaks then you're left with a heap of trash that you don't understand the magic of. Docs are written like they're tutorials and generally not very useful for these situations. The idea of this move sucks so bad. Not to mention, vercel will likely eat your lunch, anyway and then you'll have zero differentiation.
Hey @kouohhashi - this will actually not add new features and instead quite literally focus solely on making Payload -simpler-. It would be a dramatic reduction in complexity and will make the DX a lot easier. Does that make sense? What new features were you thinking that this would add?
we starting use payloadcms for our clients and we love the way it is now. Please dont do that! We use others frontend frameworks, if you will tie to nextjs that will be sad for us!
Just to be clear - you will still be able to use Payload with ANY frontend framework! It will work exactly as it does now for you. The only differences will be internal to Payload so you would still be able to pair Payload with Remix, Astro, Nuxt, etc. What framework do you use on the frontend, out of curiosity?
I'm using the Payload REST API from a server-side language and framework (Elixir, Phoenix), that has server-generated templates and websocket-based live updates (LiveView). I believe Next won't prevent that. :) It's good to hear about your prioritising of Lexical and Postgres. Thank you!
Alright I’m sold. Gonna move over to payload. Wish you had this functionality now - but I’m willing to beta test it when it’s ready ;)
Love this move, this will make it easy to adopt a serverless architect!!
already working on migrating off payload. I don't want to deal with additional abstractions on top of data. we use next js for some stuff that consume payloads data, but don't want our apis linked to a particular framework.
Can't wait to see the move! It's a huge DX win :)
Definitely 🎉 Next js is huge move
Why are zero people besides you talking about this unified function runtime? Where was that in the conference, I’d love to see more about it!
What about SvelteKit?
If you move to running Payload on Next, I assume that won't stop me being able to use it from my SvelteKit app?
Yes please do the move. How long would it take?
Probably a month or so. I did a PoC earlier this week and it went very well. We'd likely go hard on making the move for ~1 month, and then release 3.0 as beta, letting it cook as beta for like 2 months prior to releasing a full 3.0.
Super exciting! Best of luck with it all.
@@JamesMikrut Good day! Thank you for your work:) How soon will version 3.0 be released?
I am good with next.js app router but it feels so unstable. I want to try my next project without using next.js (no pun intended).
I have not tried payload cms yet, but I want to give it a try. If next.js works for you, that's ok. I hope you will not get stuck with it as next.js decisions are not 100% satisfying for everybody.
But this is just a way of life lol
Express is just more flexible overall. Keeps it far more agnostic as well. Not a fan of the move.
:(
Nice chat 👌🏻
Yes
"Web Development is great except for bundling". Couldn't agree more lmao
i feel this in my bones
nextjs 🚀
What about Elysia JS as replace for express?, then it will work everywhere including vercel edge
We'd love to support Elysia, but the reasoning for Next.js is mostly related to the admin UI. We need React server components!
Any consideration for SvelteKit? Or anything other than Next.JS?
EDIT: what about rewriting the whole admin UI in Svelte so that I specifically can have a nice admin UI written in Svelte that does the exact same thing as the React one? I love Svelte
That would be a big move and would require the rewrite of our entire admin panel. I don't think that will happen in the immediate future. React serves our admin UI well, so unless something catastrophic happened to the React ecosystem in general, we'll probably continue to build on React. That's not to say an admin UI for Payload couldn't be built with SvelteKit! Could be a cool community project.
@@JamesMikrut I appreciate the genuine response you've given, you've got patience that I haven't. I was just joking (hence the edit) about how anal some people are about tech stacks
Loving using Payload, you and the Payload team are doing a phenomenal job with it
@@user-qn3yl3yz1d LOL omg. Thank you for your compliments! This is only the beginning!
Fuck no. I don't want to be locked into Next.js.
Putting some more here: I find next.js extremely frustrating to work with. It's great for a demo but the warts suck so bad. Everything is "magical" until it breaks then you're left with a heap of trash that you don't understand the magic of. Docs are written like they're tutorials and generally not very useful for these situations.
The idea of this move sucks so bad. Not to mention, vercel will likely eat your lunch, anyway and then you'll have zero differentiation.
please keep payloadcms simple. i'm not sure add more and more features is a good idea...
Hey @kouohhashi - this will actually not add new features and instead quite literally focus solely on making Payload -simpler-. It would be a dramatic reduction in complexity and will make the DX a lot easier. Does that make sense? What new features were you thinking that this would add?
Please, no. I've moved away until they remove the telemetry stuff.
we starting use payloadcms for our clients and we love the way it is now. Please dont do that! We use others frontend frameworks, if you will tie to nextjs that will be sad for us!
Just to be clear - you will still be able to use Payload with ANY frontend framework! It will work exactly as it does now for you. The only differences will be internal to Payload so you would still be able to pair Payload with Remix, Astro, Nuxt, etc.
What framework do you use on the frontend, out of curiosity?
@@JamesMikrut Remix, ionic framework, vue, nuxt, and we are evaluating your fantastic tool. we love it so far!
@@JamesMikrutnuxt js
I'm using the Payload REST API from a server-side language and framework (Elixir, Phoenix), that has server-generated templates and websocket-based live updates (LiveView). I believe Next won't prevent that. :)
It's good to hear about your prioritising of Lexical and Postgres. Thank you!
Please no next.js if so i do not use this anymore.