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 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.
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)
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.
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.
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.
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.
"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.
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
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.
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?)
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)
reply