I've been using Payload for 18 months. They're only recently (with the upcoming v3 release) really piggy-backing on Next.js' server and routing. Before that, it was "just" a really nice headless CMS built on Node/TypeScript.
This was obviously posted in the wake of the WordPress drama, but I landed on Payload while feeling stagnant after 10+ years building on WordPress. Everything else I was doing was 100% TypeScript, my entire professional career had been working with metadata driven data structure, I felt right at home with Payload.
It's just enough structure (full admin area, API, GraphQL) to make scaffolding a basic site (with authentication) quite easy. I had built an app using Next 13 before Payload began integrating directly and using the local API (versus making HTTP calls to a server endpoint) is very clean. It feels like WordPress (i.e. you're editing "client" code on the "server") but with a LOT less cruft.
Because it's headless, anything goes on the front end. One big reason that WP got so big was because of the theming capabilities. Payload has extensibility by way of plugins, but it's (obviously...) not as robust as what's available in the WP plugin repo. It'll be interesting to see how these alternatives fare against the more prescriptive tools like Ghost (which does support theming, but does not support custom fields in any way, shape, or form).
That being said, I'm all in on Payload moving forward. If you're curious, go straight to the v3 beta -- it's very close to release and plenty stable, in my opinion. Happy to answer questions.
(Not affiliated with Payload, just a big admirer of their work)
How easy/hard would you consider the amount of work needed to create a ecommerce for digital products using Payload? I'm currently using WP + Woo but the plugins that I'm using aren't flexible enough and I'm re-inventing some of them, so might as well re-invent some more and learn Next.
I wouldn't recommend it, I've seen it abused as a database a few times and it was never good. It really is barebones and mostly for content and the UI/features show that.
You're better of using anything else, if you want a UI ontop maybe a tool like Pocketbase is better suited or you go the route of using an actual e-commerce tool like Saleor or Medusa.
Both are good, definitely better than homebrewing your database and that is >>> any open source CMS (I've tried a few dozen since I am building a CMS myself)
Payload has an e-commerce template, but it definitely pales in comparison to WooCommerce. I can't speak to specifics, but if I were looking to migrate away from WooCommerce, I'd look at MedusaJS (http://medusajs.com)
I feel like everyone runs into this in WP dev eventually, but not everyone is honest with themselves about it. It can get messy, fast — I’ve certainly been there!
I’d be interested to know what sort of work your plugins are doing. I think a lot of that ecosystem is there to fill gaps — ACFish custom field functionality, for example, is core functionality in Drupal, Payload and many others.
Just another example — I love Drupal, but the Paragraphs module was always filling a gap in Drupal that Payload’s simple, but quite powerful ‘blocks’ field type makes easy.
Another thing I didn’t realize I love about it until just now: the hooks system is super clear. It’ a lot of the same stuff you use in WP, Drupal and others, where you can hook into functionality. With WP and Drupal, it wasn’t super obvious which hooks fire when. It can take some immersion to really understand it.
I’m such a Payload Stan. I don’t work there, I swear! I’m looking forward to trying out 3.0 embedded in Sveltekit soon here.
Hi, thanks! Currently I've created a small plugin that replaces the download URL of products with a post meta `use_external_url`, appends the `order_id`, and signs it using HMAC. Then I have a CF worker that reads that, validates the signature and stamps the PDF file with the order number, on the fly, after the user clicks to download the file. (I tried some of available plugins but they sucked).
Also, I'd like to have more flexible bundles (possibly bundles of bundles), a more flexible transaction e-mail that offers upsells right after the user buys something, for instance: the user bought the Foo Vol. 1, right after I want to send an email offering a coupon so that they can get the discounted Vol 1, 2, and 3 with the amount they just paid discounted. (I can do that with Mailpoet or Omnisend if they buy just one product, or can implement multiple discounts and upsells with a little bit of JS running on my Windmill instance + Resend).
I feel like I'm going to re-invent a lot of stuff, and since I'm using Stripe, it shouldn't be so hard to think of a nice Products/Bundles/Downloadables/Gallery DB design and ship something ultra light that I can actually understand vs the million lines that a default WP + Woo install has, plus themes and plugins.
NextJS instead of templates. Full-featured admin area. I'd say Payload is more akin to Wagtail than Django itself. It feels ridiculously modern compared to other CMSes I've touched, Wagtail included. Payload doesn't prescribe i18n like Django.
When you need to, you can step down into NextJS and write custom endpoints and the like.
> When you need to, you can step down into NextJS and write custom endpoints and the like.
I don't think you were necessarily implying otherwise but one of the Django mantras is "It's just Python" - i.e. you can bypass (nearly) everything Django provides and drop down to doing whatever you want with http requests.
"Prescribe" perhaps wasn't the right word. "Bundle" is probably better. Payload has no official i18n package/module/plugin/whatever.
Re: the NextJS custom endpoint thing -- you're right in that I wasn't comparing to Django but referring to my parent comment about Ghost, which I'd say doesn't really "support" custom endpoints even if it's "possible" -- plus the .yaml routing config is kind of a drag.
The pitch alone on PayloadCMS shows that this is still a developer-focused CMS. Just look at the difference between the github page, the Payload website, and wordpress.org's landing. This is not purely a marketing difference but a strategic conversation.
I'm all about transitioning CMSes and yet WordPress has got the turnkey part of their open-source platform clear and easy to understand. You can self-host or choose a provider. Payload doesn't make that clear, it's either too dev-centric for running or wants you to "Schedule a Demo" (which is a way to capture enterprise dollars).
What about more consumer-friendly pitches and deployments? Any recommendations on that?
I worry about the criticisms I see about Payload not marketing to marketers and site builders, because as a dev I’m a huge fan and would love to see it thrive.
It’s a fair point, especially given that in so many cases the marketers are the ones procuring the CMS. And people who don’t code at all are a big portion of WP’s market.
My main concern is I’m not sure it’s easy for non-devs to see how much of the PHPish ecosystems are filling gaps in the CMS core. I don’t know how many previous CMSes the Payload folks had used before going about building it, but I’ve built tons of features and templates on most of the big ones, and IMO they did a phenomenal job of boiling it down to exactly what a developer needs to build any feature any customer or employer could ever want.
There’s no need for, say, a heavy SEO plugin. You can just define the fields you want your people to fill out and attach those fields to whatever content types you’d like. Then use those fields in the head when presenting the content out front in whatever frontend you want to use.
On top of that, you have all of the JS ecosystem you can plug right in. Dataviz for custom dashboards, data crunching, video and image processing, all of it. And because you’re not starting with a huge, opinionated plugin/module/contrib, it’s not the clunky and unfun when you need a feature that wasn’t there before. It’s so much easier to build exactly what you need if you’re comfortable with code.
SO much of a serious CMS is just content CRUD, and Payload makes it so simple to define your content types in code, where they objectively should be defined for the sake disaster recovery and reliable builds across all environments.
You can deploy Payload anywhere you can deploy any Nextjs app, and as of v3, you'll be able to deploy it to serverless environments too like Vercel and Netlify. We'll work on adding more deployment guides directly into our docs for various platforms as well to help with this.
Again, we read everyone's feedback about Payload itself and our website so it's very much appreciated and we'll be addressing this gap in how we present ourselves!
edit: I may have misunderstood your initial point, oops
Yeah we're not consumer facing in the way Wordpress is. It's quite a huge gap to fill
If Payload is a framework or not is debatable. I think it's more like a data layer around a database for a any js app and an Admin Panel (that uses Next.js now). It might be called a framework for your own Headless CMS, because it is code first. So you basically code the panel and the data structure yourself.
React hasn't been a library since they added hooks.
Hooks themselves are just a solution to async code, but the implication was that react was no longer a state-based UI rendering library and became a full blown frontend framework.
Routing is only important for a single page applications. Frontend frameworks are applicable to normal websites as well, they don't have to be SPAs with routing, caching, etc.
From what you posted in this thread, I can tell with confidence you don't know shit about web development
Hooks solution to async code? Hooks make React full blown forntend framework? Routing only important for single page applications? Yellow gorilla bread butter? Chickity dickity web frontend back single page I understand much
React was a library before hooks. Now it is a framework and decides when your code runs, not you. And now it is a terrible framework with server components.
I think server components have been very badly marketed. They're totally opt-in, so I don't see how this would make React instantly a terrible framework. I for one think they represent a lot of value.
If you don't use them, then React is quite literally no different to you.
Javascript has a compiler called Babel, which plays a huge role in modern web development. It is in fact a transcompiler, meaning it doesn't turn your javascript into bytecode, it is just transpiling stuff without changing the level of abstraction.
React Compiler is just a babel plugin for automatic performance improvement, memoization specifically, for never perfectly memoized React code.
Can library have compiler? Well why can't it? For example stdlib has a compiler, because C does.
Nothing in that is actually doing what a compiler does above and beyond what babel, swc and esbuild are capable of.
What they've added is wrapping your code in more memoization functions, basically. All stuff that doesn't fundamentally transform the code, aside from inserting more `useMemo` and the like.
The JSX macro - which is itself already optional but everyone uses it - is just that, a handy macro with implementations available in every common bundler and transpiler out there.
"Framework" isn't really the best term for them to actually use to describe Payload. Its basically a tool for NextJS developers to quickly build a custom CMS. I'd think of it more like CMS-in-code than a framework.
RSC was marked stable in Mid 2022 and this major change is still in the process of unfolding through the ecosystem, because of course these things take time. And even though react might be the future, I have a hard time understanding a client side framework that currently becomes more of a server side framework being stable.
By that standard, nothing is stable. New features are added to HTML, the Linux kernel, x86, PHP, etc all the time. In fact, building on top of higher level abstractions can sometime insulate your application from this change too.
PayloadCMS is looking really nice for us. However, for us a as a small non-profit organization with ~100 people having access to our systems the missing SSO feature (enterprise only) is really a blocker.
I understand what the idea is to make SSO an enterprise feature but I really think this hurts security for small and medium sized organizations as well (not only with this project, as this is a common pattern in my experience).
Hey there - small to medium orgs can use one of the available community, open source SSO plugins, with the only caveat that they are not officially supported by Payload. Or you could build your own!
Question - does the word "enterprise" make you think that the amount we charge would make it unfeasible for your org to pay to use Payload?
I don't think it's ideal that we hide all our "premium" features behind the word "enterprise" and have been thinking of alternative words / messaging to describe that.
Hey, in my opinion it is fair to have some features behind a paywall for an open core model (although I am not a fan of it, but I really understand the reasons).
But personally, I think having core security features (which I believe SSO is, e.g. also for small orgs) behind such paywall is not really helping the product.
Using a free plugin developed independently from the core product does incur other issues e.g. during updates etc. Also, it does present an additional hurdle for all non-enterprise users to make use of the, typically, more secure SSO solution they might already use leading to - in my opinion - more unsafe deployments of Payload (or any other product). It is also not helping to overcome the cybersecurity poverty line anytime soon.
When I am deciding whether to buy the enterprise version of a product, for me a main concern is whether I would also be able to use the product with its core features without any subscription (preventing vendor lock-in, in worst case I would be able to run the product on my own for a specified period of time). This wouldn't be the case if no user can login any more ^^
One last aspect: We as an organization also provided and extended SSO implementations in various products in the last years. But we only do this if the SSO code is free software. In our experience SSO implementations are way better if they can be improved by the community.
In june evaluated PayloadCMS (v3 beta), Strapi and Sanity for powering an app with (30+ content types) and a website.
In the end i chose PayloadCMS.
- I can programatically define content types in typescript
- selfhosting
- localization support.
Sanity:
_Pros_: great DX, easy to start
_Cons_: i was afraid of exploding bills, it felt a bit slow/sluggish
STRAPI:
_Pros_: open source, selfhostable, managed solution available,
_Cons_: too much clicking in the UX, and having to write middleware to get related data.
Not flexible enough, performance problems, doesn't provide much ootb.
You're better off just writing a service from scratch, the time you are saving is minimal (this applies to most products before we get to django or wordpress imho)
Performance problems are usually something related to maybe missing indexes in your database for fields that you query on often, or similar. Payload itself is super thin. Can you give me an example of where you're seeing slowdowns? Maybe I can point you in the right direction.
Also I would love to hear about where Payload is not flexible enough. Extensibility is one of our priorities so if there is something you'd like to accomplish, but can't, I will see what I can do about it!
I tried to switch to this from keystonejs. Keystone’s documentation is painfully inconsistent with its library. I have lost entire days over it. but “it works.”
Was expecting more with payload but seems to be another buggy experience but with better UI.
Eagerly waiting for a player in this space that isn’t just developer-first but also developer-friendly.
Hey! I'm CEO of Payload and want to make sure we resolve any bugs you found. Pretty much the whole team is focused on closing issues right now as we work toward 3.0 stable so depending on when you were trying out Payload, I'd imagine you might see lots of the bugs you faced as already resolved.
Keystone would be my other vote though, if I were looking for a CMS and Payload didn't exist. I think that is a solid crew.
We are using this at work. Generally I'm pretty happy with the configuration driven approach. You have config objects for all your collections where you define the types of the fields and everything else happens automatically.
With this comes a few gotchas. It's easy for an unassuming developer to change the name of a field (e.g., upper to lower case) and suddenly all data is gone in production since this affects the database. What you should do instead is write a migration.
I'm also not a fan of Lexical. It's very focused on being a good rich text editor but not on being a good document format for your clients. For example the way they render lists is, in my opinion, simply wrong (see https://github.com/facebook/lexical/issues/2951). Or this https://github.com/facebook/lexical/issues/6269. You also have the added complication of using the Payload flavor of Lexical, which can add its own complexities.
I haven't had time to look into its GraphQL API yet.
Documentation wise I'd compare it to working with NixOS. For some simple tasks the documentation is useful but for anything more complicated you want to look at the Payload source code. Especially when you start customizing the UI. Which generally works pretty well.
I wish they had thought about versioning the Rich Text somehow, so a client knows which version of your documents they get.
I don't know why, but it very much reminds me of Pimcore [1] back when they started. Not the functionality, but the feeling when I look at the code.
Pimcore was awesome, it was clean, considering the alternatives - it was a basically a dynamic objects store which would load dynamic blocks to generate content and theming on the frontend - and editable blocks in the admin panel. It was so relatable from a webdev standpoint, and very "hackable" - I loved it.
The idea at that time was so appealing (mind you, afaik that was before React or even Angular. Jquery was a thing at that time and ExtJS, Pepperide Farm remembers...). Now it gotten much much bigger of course, but in the beginning, it kinda reminds me of this: sleek, extensible also very relateable. Definitely not made for the size of a multi billion dollar franchise, but fun to hack around while still maintaining relatively clean code.
This CMS appears to be a breath of fresh air amid the toxicity in the WordPress world.
Considering devs are looking at complaints/features in this thread, I will post one:
In WordPress, I can copy a plugin folder from one old project into a new one and enable it in the ui without touching code or cli. I see the benefit of defining plugins through a cli tool, but I also like the copy-paste folder structure of early 00's software.
They do mention WP (Word Press)... I am confused. What exactly this does?
I get it takes care of content and they mention Stripe, so that is good. But is this WP compatible layer or this is accidental use of shorthand for something else?
It is more like those templates that people use to jumpstart sites, I think this can be very useful.
I don't want to sound too complainy over the free code you can get and examine yourself, maybe adding thumbnails of 3 templates would be fantastic.
Overall some clarity would be great, maybe developer should talk to someone outside his little circle and explain and see what they should include.
No, it's a Headless CMS, so no frontend themes and templates. They have an official demo page including a frontend, that you can base your work on: https://github.com/payloadcms/public-demo
If you are looking for a Wordpress-clickety click solution with templates, Payload is not a candidate.
I think any solution that does not use PHP will not replace WordPress for most users, unless WP itself stagnates. "Anyone" can install Word press on a cheap shared hosting device and get started. That's why I think a real WP alternative will need to be based on PHP (Laravel?)
I've migrated from WordPress to Laravel-based CMS before. There's Statamic, but it's not free, though. It's good, my users love it and I can easily add functionality in contrast to WordPress, you'd have to install a plugin or dig into the digustingly messy code. Hated it.
Maybe just one feedback item for the site: "Visual Editing" shows up at the top of a few use case pages, and in other spots around the site. When you click on it, it's not very obvious you've been brought to the "enterprise" site. Just a clearly different nav bar on the enterprise pages, or callout badge on Enterprise features would be good.
I feel like a few people could be convinced that visual editing is part of the open source base product, not the enterprise plugins.
It looks like a top choice for me. But a big part of why I'm probably still going to use WordPress is because of the Gravity Forms plugin.
A place where it's easy to drag and drop forms, do conditional stuff, edit thank you messages, connect inputs to other stuff like spreadsheets, zapier etc.
If any CMS / plugin could fix that for Payload. Please let me know!
We have a few field types that can help you structure your content however you need for this such as a JSON field if you need to add config and upload field with various adapters if you need to upload 3D models for example.
Both of which can be included in blocks which can then be included in the rich text editor (lexical) so you're still keeping all your content in one place.
Flexibility is the name of the game here but I can give more advice if you've got specific needs or questions around this
I've been using Payload for 18 months. They're only recently (with the upcoming v3 release) really piggy-backing on Next.js' server and routing. Before that, it was "just" a really nice headless CMS built on Node/TypeScript.
This was obviously posted in the wake of the WordPress drama, but I landed on Payload while feeling stagnant after 10+ years building on WordPress. Everything else I was doing was 100% TypeScript, my entire professional career had been working with metadata driven data structure, I felt right at home with Payload.
It's just enough structure (full admin area, API, GraphQL) to make scaffolding a basic site (with authentication) quite easy. I had built an app using Next 13 before Payload began integrating directly and using the local API (versus making HTTP calls to a server endpoint) is very clean. It feels like WordPress (i.e. you're editing "client" code on the "server") but with a LOT less cruft.
Because it's headless, anything goes on the front end. One big reason that WP got so big was because of the theming capabilities. Payload has extensibility by way of plugins, but it's (obviously...) not as robust as what's available in the WP plugin repo. It'll be interesting to see how these alternatives fare against the more prescriptive tools like Ghost (which does support theming, but does not support custom fields in any way, shape, or form).
That being said, I'm all in on Payload moving forward. If you're curious, go straight to the v3 beta -- it's very close to release and plenty stable, in my opinion. Happy to answer questions.
(Not affiliated with Payload, just a big admirer of their work)
Still very very far from Wordpress, just the Yoast SEO plugin is worth the drama in wordpress.
What features of the Yoast plugin are critical for you?
How easy/hard would you consider the amount of work needed to create a ecommerce for digital products using Payload? I'm currently using WP + Woo but the plugins that I'm using aren't flexible enough and I'm re-inventing some of them, so might as well re-invent some more and learn Next.
I wouldn't recommend it, I've seen it abused as a database a few times and it was never good. It really is barebones and mostly for content and the UI/features show that.
You're better of using anything else, if you want a UI ontop maybe a tool like Pocketbase is better suited or you go the route of using an actual e-commerce tool like Saleor or Medusa.
Both are good, definitely better than homebrewing your database and that is >>> any open source CMS (I've tried a few dozen since I am building a CMS myself)
Medusa looks amazing. Is there any catch?
Thank you, will check Saleor and Medusa!
Payload has an e-commerce template, but it definitely pales in comparison to WooCommerce. I can't speak to specifics, but if I were looking to migrate away from WooCommerce, I'd look at MedusaJS (http://medusajs.com)
Medusa looks perfect, thanks for mentioning it.
I feel like everyone runs into this in WP dev eventually, but not everyone is honest with themselves about it. It can get messy, fast — I’ve certainly been there!
I’d be interested to know what sort of work your plugins are doing. I think a lot of that ecosystem is there to fill gaps — ACFish custom field functionality, for example, is core functionality in Drupal, Payload and many others.
Just another example — I love Drupal, but the Paragraphs module was always filling a gap in Drupal that Payload’s simple, but quite powerful ‘blocks’ field type makes easy.
Another thing I didn’t realize I love about it until just now: the hooks system is super clear. It’ a lot of the same stuff you use in WP, Drupal and others, where you can hook into functionality. With WP and Drupal, it wasn’t super obvious which hooks fire when. It can take some immersion to really understand it.
I’m such a Payload Stan. I don’t work there, I swear! I’m looking forward to trying out 3.0 embedded in Sveltekit soon here.
Hi, thanks! Currently I've created a small plugin that replaces the download URL of products with a post meta `use_external_url`, appends the `order_id`, and signs it using HMAC. Then I have a CF worker that reads that, validates the signature and stamps the PDF file with the order number, on the fly, after the user clicks to download the file. (I tried some of available plugins but they sucked).
Also, I'd like to have more flexible bundles (possibly bundles of bundles), a more flexible transaction e-mail that offers upsells right after the user buys something, for instance: the user bought the Foo Vol. 1, right after I want to send an email offering a coupon so that they can get the discounted Vol 1, 2, and 3 with the amount they just paid discounted. (I can do that with Mailpoet or Omnisend if they buy just one product, or can implement multiple discounts and upsells with a little bit of JS running on my Windmill instance + Resend).
I feel like I'm going to re-invent a lot of stuff, and since I'm using Stripe, it shouldn't be so hard to think of a nice Products/Bundles/Downloadables/Gallery DB design and ship something ultra light that I can actually understand vs the million lines that a default WP + Woo install has, plus themes and plugins.
how does it compare to Django as far as battery-included goes
NextJS instead of templates. Full-featured admin area. I'd say Payload is more akin to Wagtail than Django itself. It feels ridiculously modern compared to other CMSes I've touched, Wagtail included. Payload doesn't prescribe i18n like Django.
When you need to, you can step down into NextJS and write custom endpoints and the like.
> Payload doesn't prescribe i18n like Django.
Not sure what you mean?
> When you need to, you can step down into NextJS and write custom endpoints and the like.
I don't think you were necessarily implying otherwise but one of the Django mantras is "It's just Python" - i.e. you can bypass (nearly) everything Django provides and drop down to doing whatever you want with http requests.
"Prescribe" perhaps wasn't the right word. "Bundle" is probably better. Payload has no official i18n package/module/plugin/whatever.
Re: the NextJS custom endpoint thing -- you're right in that I wasn't comparing to Django but referring to my parent comment about Ghost, which I'd say doesn't really "support" custom endpoints even if it's "possible" -- plus the .yaml routing config is kind of a drag.
The pitch alone on PayloadCMS shows that this is still a developer-focused CMS. Just look at the difference between the github page, the Payload website, and wordpress.org's landing. This is not purely a marketing difference but a strategic conversation.
I'm all about transitioning CMSes and yet WordPress has got the turnkey part of their open-source platform clear and easy to understand. You can self-host or choose a provider. Payload doesn't make that clear, it's either too dev-centric for running or wants you to "Schedule a Demo" (which is a way to capture enterprise dollars).
What about more consumer-friendly pitches and deployments? Any recommendations on that?
I worry about the criticisms I see about Payload not marketing to marketers and site builders, because as a dev I’m a huge fan and would love to see it thrive.
It’s a fair point, especially given that in so many cases the marketers are the ones procuring the CMS. And people who don’t code at all are a big portion of WP’s market.
My main concern is I’m not sure it’s easy for non-devs to see how much of the PHPish ecosystems are filling gaps in the CMS core. I don’t know how many previous CMSes the Payload folks had used before going about building it, but I’ve built tons of features and templates on most of the big ones, and IMO they did a phenomenal job of boiling it down to exactly what a developer needs to build any feature any customer or employer could ever want.
There’s no need for, say, a heavy SEO plugin. You can just define the fields you want your people to fill out and attach those fields to whatever content types you’d like. Then use those fields in the head when presenting the content out front in whatever frontend you want to use.
On top of that, you have all of the JS ecosystem you can plug right in. Dataviz for custom dashboards, data crunching, video and image processing, all of it. And because you’re not starting with a huge, opinionated plugin/module/contrib, it’s not the clunky and unfun when you need a feature that wasn’t there before. It’s so much easier to build exactly what you need if you’re comfortable with code.
SO much of a serious CMS is just content CRUD, and Payload makes it so simple to define your content types in code, where they objectively should be defined for the sake disaster recovery and reliable builds across all environments.
I work on Payload and this feedback is noted!
You can deploy Payload anywhere you can deploy any Nextjs app, and as of v3, you'll be able to deploy it to serverless environments too like Vercel and Netlify. We'll work on adding more deployment guides directly into our docs for various platforms as well to help with this.
Again, we read everyone's feedback about Payload itself and our website so it's very much appreciated and we'll be addressing this gap in how we present ourselves!
edit: I may have misunderstood your initial point, oops
Yeah we're not consumer facing in the way Wordpress is. It's quite a huge gap to fill
So let me get this straight... PayloadCMS is a framework, for Next.js which is a framework for the React framework.
Yo dawg, i heard you like frameworks!
A common misconception. React is a library.
These are examples for React frameworks: https://react.dev/learn/start-a-new-react-project#production...
Next.js is a React framework.
If Payload is a framework or not is debatable. I think it's more like a data layer around a database for a any js app and an Admin Panel (that uses Next.js now). It might be called a framework for your own Headless CMS, because it is code first. So you basically code the panel and the data structure yourself.
React hasn't been a library since they added hooks.
Hooks themselves are just a solution to async code, but the implication was that react was no longer a state-based UI rendering library and became a full blown frontend framework.
Hard to call something a full blown front end framework when it doesn’t have routing.
Routing is only important for a single page applications. Frontend frameworks are applicable to normal websites as well, they don't have to be SPAs with routing, caching, etc.
Can you please guide me where this heresy is being spread?
You heard it here first, I'm officially breaking the story wide open.
From what you posted in this thread, I can tell with confidence you don't know shit about web development
Hooks solution to async code? Hooks make React full blown forntend framework? Routing only important for single page applications? Yellow gorilla bread butter? Chickity dickity web frontend back single page I understand much
React started as a library.. at this point it has server side components, and a world of plugins.
As for anything that has patterns of building with, will argue it's a framework.
React is a FEBEFUIRT - a FrontEnd/BackEnd-Fluid UI RunTime.
React was a library before hooks. Now it is a framework and decides when your code runs, not you. And now it is a terrible framework with server components.
I think server components have been very badly marketed. They're totally opt-in, so I don't see how this would make React instantly a terrible framework. I for one think they represent a lot of value.
If you don't use them, then React is quite literally no different to you.
Can you please guide me where this heresy is being spread?
> React is a library
Can a library have compiler?)
Javascript has a compiler called Babel, which plays a huge role in modern web development. It is in fact a transcompiler, meaning it doesn't turn your javascript into bytecode, it is just transpiling stuff without changing the level of abstraction.
React Compiler is just a babel plugin for automatic performance improvement, memoization specifically, for never perfectly memoized React code.
Can library have compiler? Well why can't it? For example stdlib has a compiler, because C does.
That's an optional step for JSX cross-compilation. It's a language plugin; nothing really to do with frameworks or libraries.
They're going further than jsx transpilation[1]
[1] https://react.dev/learn/react-compiler
Nothing in that is actually doing what a compiler does above and beyond what babel, swc and esbuild are capable of.
What they've added is wrapping your code in more memoization functions, basically. All stuff that doesn't fundamentally transform the code, aside from inserting more `useMemo` and the like.
The JSX macro - which is itself already optional but everyone uses it - is just that, a handy macro with implementations available in every common bundler and transpiler out there.
A sword is also just a knife. And a Tesla truck is just an electric go-kart.
"Framework" isn't really the best term for them to actually use to describe Payload. Its basically a tool for NextJS developers to quickly build a custom CMS. I'd think of it more like CMS-in-code than a framework.
Yes? I think this is great. IMO our goal should be to enable building higher-level abstractions on lower-level ones.
Sure, if the lower level is stable. Nothing in this chain is close to stable.
React is arguably quite stable?
RSC was marked stable in Mid 2022 and this major change is still in the process of unfolding through the ecosystem, because of course these things take time. And even though react might be the future, I have a hard time understanding a client side framework that currently becomes more of a server side framework being stable.
By that standard, nothing is stable. New features are added to HTML, the Linux kernel, x86, PHP, etc all the time. In fact, building on top of higher level abstractions can sometime insulate your application from this change too.
s/framework/abstraction/g
With that said, yep, I do like robust/stable and purposeful abstractions.
PayloadCMS is looking really nice for us. However, for us a as a small non-profit organization with ~100 people having access to our systems the missing SSO feature (enterprise only) is really a blocker.
I understand what the idea is to make SSO an enterprise feature but I really think this hurts security for small and medium sized organizations as well (not only with this project, as this is a common pattern in my experience).
Hey there - small to medium orgs can use one of the available community, open source SSO plugins, with the only caveat that they are not officially supported by Payload. Or you could build your own!
Question - does the word "enterprise" make you think that the amount we charge would make it unfeasible for your org to pay to use Payload?
I don't think it's ideal that we hide all our "premium" features behind the word "enterprise" and have been thinking of alternative words / messaging to describe that.
Hey, in my opinion it is fair to have some features behind a paywall for an open core model (although I am not a fan of it, but I really understand the reasons).
But personally, I think having core security features (which I believe SSO is, e.g. also for small orgs) behind such paywall is not really helping the product.
Using a free plugin developed independently from the core product does incur other issues e.g. during updates etc. Also, it does present an additional hurdle for all non-enterprise users to make use of the, typically, more secure SSO solution they might already use leading to - in my opinion - more unsafe deployments of Payload (or any other product). It is also not helping to overcome the cybersecurity poverty line anytime soon.
When I am deciding whether to buy the enterprise version of a product, for me a main concern is whether I would also be able to use the product with its core features without any subscription (preventing vendor lock-in, in worst case I would be able to run the product on my own for a specified period of time). This wouldn't be the case if no user can login any more ^^
One last aspect: We as an organization also provided and extended SSO implementations in various products in the last years. But we only do this if the SSO code is free software. In our experience SSO implementations are way better if they can be improved by the community.
Fair. Good feedback. For what it's worth, we are actively looking at our licensing model trying to make it easier for situations exactly like yours.
Might have some updates for you soon.
yes making it working for all basic needs is the key to expand into a huge user space, from where you can find paid users much easier.
or it probably won't fly, there are also still many options.
In june evaluated PayloadCMS (v3 beta), Strapi and Sanity for powering an app with (30+ content types) and a website.
In the end i chose PayloadCMS. - I can programatically define content types in typescript - selfhosting - localization support.
Sanity: _Pros_: great DX, easy to start _Cons_: i was afraid of exploding bills, it felt a bit slow/sluggish
STRAPI: _Pros_: open source, selfhostable, managed solution available, _Cons_: too much clicking in the UX, and having to write middleware to get related data.
So far I am pretty happy with PayloadCMS.
Happy to hear this! Thank you for chiming in here. Hope to see you around the community.
We've been using it for a year and we hate it.
Not flexible enough, performance problems, doesn't provide much ootb.
You're better off just writing a service from scratch, the time you are saving is minimal (this applies to most products before we get to django or wordpress imho)
We tried and abandoned keystone too.
Hey! Would love to hear more about this.
Performance problems are usually something related to maybe missing indexes in your database for fields that you query on often, or similar. Payload itself is super thin. Can you give me an example of where you're seeing slowdowns? Maybe I can point you in the right direction.
Also I would love to hear about where Payload is not flexible enough. Extensibility is one of our priorities so if there is something you'd like to accomplish, but can't, I will see what I can do about it!
I tried to switch to this from keystonejs. Keystone’s documentation is painfully inconsistent with its library. I have lost entire days over it. but “it works.”
Was expecting more with payload but seems to be another buggy experience but with better UI.
Eagerly waiting for a player in this space that isn’t just developer-first but also developer-friendly.
Hey! I'm CEO of Payload and want to make sure we resolve any bugs you found. Pretty much the whole team is focused on closing issues right now as we work toward 3.0 stable so depending on when you were trying out Payload, I'd imagine you might see lots of the bugs you faced as already resolved.
Keystone would be my other vote though, if I were looking for a CMS and Payload didn't exist. I think that is a solid crew.
What bugs did you run into? This sentiment is not shared by the Payload community that I've seen.
We are using this at work. Generally I'm pretty happy with the configuration driven approach. You have config objects for all your collections where you define the types of the fields and everything else happens automatically.
With this comes a few gotchas. It's easy for an unassuming developer to change the name of a field (e.g., upper to lower case) and suddenly all data is gone in production since this affects the database. What you should do instead is write a migration.
I'm also not a fan of Lexical. It's very focused on being a good rich text editor but not on being a good document format for your clients. For example the way they render lists is, in my opinion, simply wrong (see https://github.com/facebook/lexical/issues/2951). Or this https://github.com/facebook/lexical/issues/6269. You also have the added complication of using the Payload flavor of Lexical, which can add its own complexities.
I haven't had time to look into its GraphQL API yet.
Documentation wise I'd compare it to working with NixOS. For some simple tasks the documentation is useful but for anything more complicated you want to look at the Payload source code. Especially when you start customizing the UI. Which generally works pretty well.
I wish they had thought about versioning the Rich Text somehow, so a client knows which version of your documents they get.
Overall I like it.
I don't know why, but it very much reminds me of Pimcore [1] back when they started. Not the functionality, but the feeling when I look at the code.
Pimcore was awesome, it was clean, considering the alternatives - it was a basically a dynamic objects store which would load dynamic blocks to generate content and theming on the frontend - and editable blocks in the admin panel. It was so relatable from a webdev standpoint, and very "hackable" - I loved it.
The idea at that time was so appealing (mind you, afaik that was before React or even Angular. Jquery was a thing at that time and ExtJS, Pepperide Farm remembers...). Now it gotten much much bigger of course, but in the beginning, it kinda reminds me of this: sleek, extensible also very relateable. Definitely not made for the size of a multi billion dollar franchise, but fun to hack around while still maintaining relatively clean code.
[1] http://web.archive.org/web/20110606024114/http://www.pimcore...
Would have been nice to post when they released v3 as they are close.
i got excited seeing the post, because i thought v3 was released. For anyone who want's to know more about v3 here is a link: https://payloadcms.com/blog/30-beta-install-payload-into-any...
This CMS appears to be a breath of fresh air amid the toxicity in the WordPress world.
Considering devs are looking at complaints/features in this thread, I will post one: In WordPress, I can copy a plugin folder from one old project into a new one and enable it in the ui without touching code or cli. I see the benefit of defining plugins through a cli tool, but I also like the copy-paste folder structure of early 00's software.
You should try Directus! I'm using it for a project right now and it's very nice. It has the plugin folder you mention too.
They do mention WP (Word Press)... I am confused. What exactly this does?
I get it takes care of content and they mention Stripe, so that is good. But is this WP compatible layer or this is accidental use of shorthand for something else?
It is more like those templates that people use to jumpstart sites, I think this can be very useful.
I don't want to sound too complainy over the free code you can get and examine yourself, maybe adding thumbnails of 3 templates would be fantastic.
Overall some clarity would be great, maybe developer should talk to someone outside his little circle and explain and see what they should include.
They seem to recently position themselves as a Wordpress alternative. There is a blog post about migration from Wordpress to Payload including code: https://payloadcms.com/blog/how-to-migrate-from-wordpress-to...
No, it's a Headless CMS, so no frontend themes and templates. They have an official demo page including a frontend, that you can base your work on: https://github.com/payloadcms/public-demo
If you are looking for a Wordpress-clickety click solution with templates, Payload is not a candidate.
I think any solution that does not use PHP will not replace WordPress for most users, unless WP itself stagnates. "Anyone" can install Word press on a cheap shared hosting device and get started. That's why I think a real WP alternative will need to be based on PHP (Laravel?)
I've migrated from WordPress to Laravel-based CMS before. There's Statamic, but it's not free, though. It's good, my users love it and I can easily add functionality in contrast to WordPress, you'd have to install a plugin or dig into the digustingly messy code. Hated it.
Appears to be open-core only https://payloadcms.com/enterprise
Hmm, one clarification - there is no enterprise Payload version. All of our enterprise features are just plugins - which anyone could build.
In this way, would you consider WordPress to be open-core as well, considering the amount of paid plugins there are available?
Maybe just one feedback item for the site: "Visual Editing" shows up at the top of a few use case pages, and in other spots around the site. When you click on it, it's not very obvious you've been brought to the "enterprise" site. Just a clearly different nav bar on the enterprise pages, or callout badge on Enterprise features would be good.
I feel like a few people could be convinced that visual editing is part of the open source base product, not the enterprise plugins.
100%. We are actually working on a little "badge" style thing. Needed bad.
> In this way, would you consider WordPress to be open-core as well, considering the amount of paid plugins there are available?
Because several of those are sold by Automattic, the company that owns wordpress, I have made that argument before, yes.
It looks like a top choice for me. But a big part of why I'm probably still going to use WordPress is because of the Gravity Forms plugin.
A place where it's easy to drag and drop forms, do conditional stuff, edit thank you messages, connect inputs to other stuff like spreadsheets, zapier etc.
If any CMS / plugin could fix that for Payload. Please let me know!
Payload has a form builder plugin - https://payloadcms.com/docs/plugins/form-builder#form-builde...
have you seen that?
Oh this looks pretty good! Will investigate!
Google Forms in iframe?
It's not really an option because we need to be able to style it.
I really want to explore Payload. Initial install is rocky though. Im stuck on something drizzle-kit related
How does this handle threejs content? I've been looking for a good CMS for making interactive articles.
We have a few field types that can help you structure your content however you need for this such as a JSON field if you need to add config and upload field with various adapters if you need to upload 3D models for example.
Both of which can be included in blocks which can then be included in the rich text editor (lexical) so you're still keeping all your content in one place.
Flexibility is the name of the game here but I can give more advice if you've got specific needs or questions around this
Looks like I really have to buy into React in order to choose this... Kind've a non-starter.
What frontend libraries do you use?
Vue is my preferred framework.
So it's a full stack framework for a full stack framework? Right...