Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PayloadCMS: Open-Source, Fullstack Next.js Framework

github.com

Post reply on HN
Print view View original

61–70 of 86 posts

Re: PayloadCMS: Open-Source, Fullstack Next.js Framework

#61

Post by lmarschk »

sneek_ wrote: post #58
lmarschk wrote: post #43

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 e…

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…

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.

Re: PayloadCMS: Open-Source, Fullstack Next.js Framework

#63

Post by bartligthart »

sneek_ wrote: post #59
bartligthart wrote: post #45

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!

Re: PayloadCMS: Open-Source, Fullstack Next.js Framework

#64

Post by arnejenssen »

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.

Re: PayloadCMS: Open-Source, Fullstack Next.js Framework

#65

Post by sneek_ »

arnejenssen wrote: post #64

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 avail…

Happy to hear this! Thank you for chiming in here. Hope to see you around the community.

Re: PayloadCMS: Open-Source, Fullstack Next.js Framework

#66

Post by sneek_ »

lmarschk wrote: post #61
sneek_ wrote: post #58

Earlier quoted context omitted.

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…

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. dur…

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.

Re: PayloadCMS: Open-Source, Fullstack Next.js Framework

#68

Post by marpstar »

andybak wrote: post #56
marpstar wrote: post #37

Earlier quoted context omitted.

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.

Re: PayloadCMS: Open-Source, Fullstack Next.js Framework

#69

Post by zdragnar »

tmtwhn wrote: post #32
robertlagrant wrote: post #13

Earlier quoted context omitted.

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.

Re: PayloadCMS: Open-Source, Fullstack Next.js Framework

#70

Post by paulpopus »

seamossfet wrote: post #62

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

Post reply on HN