3 ms·

why would a "non-technical" team pick this product over something more universally hostable and well known, with established plugin ecosystem and developers on

why would a "non-technical" team pick this product over something more universally hostable and well known, with established plugin ecosystem and developers on tap, like Wordpress?

ShellfishMeme 6y ago
Because the web is moving away from pure content or shop pages to more holistic interactive experiences where you need to integrate content into complex flows that are more application than website. Plus you might want to reuse said content on mobile apps too. There it really pays off to have your content separated as structured data that you can query for.
- tannhaeuser 6y ago
  Is that meant as satire or what? Structured content that an end-user can edit, query, share, comprehend, design, etc. is what you have with markup languages, and have had since over 30 years (SGML/HTML/XML). A "headless" CMS is just an API server eg. a tool for JS developers; you could use any JSON or GraphQL API wrapping tool you want (PostgREST, say), or code one yourself in a few lines of code. So I have to say "headless CMS" is really a pure marketing term, and IMHO utter pointless, as the difficulty and most of the work in a CMS product comes from a front-end (or architectural match, really) that end users can meaningfully interact with and set up dynamic sites, redactional workflows, dynamic user content, theming, analytics+banners, asset management/pipelines, etc., etc. with.
  - ShellfishMeme 6y ago
    > as the difficulty and most of the work in a CMS product comes from a front-end (or architectural match, really) that end users can meaningfully interact with and set up dynamic sites, redactional workflows, dynamic user content, theming, analytics+banners, asset management/pipelines, etc., etc. with Sounds to me like you already made a good case for why those products exist. Sure, you could also call HTML structured content, but using HTML for expressing the semantics of the content instead of the presentation has always been a bit of a pain. Plus you wouldn't really want to use HTML as a format to share this kind of data with for example mobile applications. You could use XML, but I'd say that's basically the same as JSON with a fixed schema but with more angle brackets, which is pretty much what those headless CMSs return. Then on top you need the devs to build the server, and to maintain the DB, to add a querying API, to add SDKs and tooling that enable smooth integrations with the new API, the workflows on top of the pure content, a UI that is intuitive to the people maintaining the content, security audits, scalability for when more parts of the company want to use your tooling etc etc. Following your reasoning you could also say "Payment provider" is a marketing term for something that is just a DB that needs to sync with some banking APIs and AWS is just APIs in front of some DBs and VMs and analytics solutions are just a JS SDK on top of some DB. Fundamentally everything we build is just some kind of frontend or abstraction on top of a DB. I don't see how that makes it in any way pointless.
sandGorgon 6y ago
so the choice of wordpress or nodejs or whatever is a developer driven decision. However, the non-technical team will want a brilliant CMS experience. If you can convince the tech team to build your entire infrastructure on Wordpress/php...then great, go for it. But most likely the rest of your app is built in different languages. So a "headless CMS" like Strapi gives a brilliant CMS experience and exposes the content as a graphql api. To be fair, you can achieve that in Wordpress as well - https://www.wpgraphql.com/ https://www.wpgraphql.com/. But I suspect that most engineering will be happier to touch a reactjs based product versus a PHP based.
- berkes 6y ago
  > To be fair, you can achieve that in Wordpress as well Yes, you can. But it feels, acts and works exactly like the thing it is: a hack held together with ducttape and prayers. This is not a diss to WordPress or to the wpgraphql community: they do great work. But comes from experience at running a WP hosting company (and solving all sorts of WP issues). WP was designed as a blogging tool. This shows, because everything you make it do that is not blogging is clumsy and hackish at best, and very insecure/unstable/buggy at worst. The further you go from "a blog" the worst this gets. Turning WP into a headless API-backend is such a thing: WP was never designed for this and it shows.
  - dotBen 6y ago
    While I agree some of these plugins do start to feel hacky, WordPress Core has evolved quite a bit from being just a blog. Custom post types are not even new, but come to mind. I'm surprised to hear someone who has run a WP hosting company say that using WP for anything other than a blog is "clumsy and hackish at best". I've also run a WP hosting company and would suggest otherwise
    - berkes 6y ago
      When I say "anything other than a blog", I do mean "blog" in a broad sense. A "publishing platform" may be a better term but is rather vague. Here's what WP is particularly bad at: * Anything "user generated" where "users" are not part of a trusted group of editors. Even the feature "comments" that has been in WP since the very start breaks down very quickly and is extremely tough to manage, tune, or moderate. * Anything that is highly dynamical, such as popularity counters, voting, threads (see above) or any other UGC (see above) breaks immediately with any kind of load b/c all performance optimisation in WP evolves around caching. Which is a good strategy for a publishing platform. * Anything that has workflows or requires state for visitors. e-commerce, payments, sign-in, etc. Hampered by the limited abilities to tune performance (see above) but mostly hampered because WP has no framework or tooling built in to manage "state", build "state machines" and so on. Other than "just cram it in cookies", but that is no state-management. I've seen WP cookies nearing 0.1MB being passed over the line for every request "the site is getting slow, I hear", said the client. Well.... sure! * Anything that requires async processing. Tucking wp-cli into a cron-job works but is clumsy and fragile. Spawning workers, jobs, events or anything else is lacking in tooling. You probably don't need this, but when you do, WP is your enemy. So, sure, WP is really neat when you have a known, or dedicated team of publishers and authors that write stuff, which is then read by visitors. For this model (which I call "the blog") it is very well attuned, especially if you keep it at those generics. Especially when such teams work on many different such "editorial sites" at once: the familiarity of WP then helps a lot. But in most other cases there are either far better suited publishing platforms attuned for your exact needs and niche. Or there are frameworks that let you build such an attuned system far easier than through "WordPress Development".

why would a "non-technical" team pick this product over something more universally hostable and well known, with established plugin ecosystem and developers on tap, like Wordpress?

ShellfishMeme 6y ago

Because the web is moving away from pure content or shop pages to more holistic interactive experiences where you need to integrate content into complex flows that are more application than website. Plus you might want to reuse said content on mobile apps too. There it really pays off to have your content separated as structured data that you can query for.

tannhaeuser 6y ago
Is that meant as satire or what? Structured content that an end-user can edit, query, share, comprehend, design, etc. is what you have with markup languages, and have had since over 30 years (SGML/HTML/XML). A "headless" CMS is just an API server eg. a tool for JS developers; you could use any JSON or GraphQL API wrapping tool you want (PostgREST, say), or code one yourself in a few lines of code. So I have to say "headless CMS" is really a pure marketing term, and IMHO utter pointless, as the difficulty and most of the work in a CMS product comes from a front-end (or architectural match, really) that end users can meaningfully interact with and set up dynamic sites, redactional workflows, dynamic user content, theming, analytics+banners, asset management/pipelines, etc., etc. with.
- ShellfishMeme 6y ago
  > as the difficulty and most of the work in a CMS product comes from a front-end (or architectural match, really) that end users can meaningfully interact with and set up dynamic sites, redactional workflows, dynamic user content, theming, analytics+banners, asset management/pipelines, etc., etc. with Sounds to me like you already made a good case for why those products exist. Sure, you could also call HTML structured content, but using HTML for expressing the semantics of the content instead of the presentation has always been a bit of a pain. Plus you wouldn't really want to use HTML as a format to share this kind of data with for example mobile applications. You could use XML, but I'd say that's basically the same as JSON with a fixed schema but with more angle brackets, which is pretty much what those headless CMSs return. Then on top you need the devs to build the server, and to maintain the DB, to add a querying API, to add SDKs and tooling that enable smooth integrations with the new API, the workflows on top of the pure content, a UI that is intuitive to the people maintaining the content, security audits, scalability for when more parts of the company want to use your tooling etc etc. Following your reasoning you could also say "Payment provider" is a marketing term for something that is just a DB that needs to sync with some banking APIs and AWS is just APIs in front of some DBs and VMs and analytics solutions are just a JS SDK on top of some DB. Fundamentally everything we build is just some kind of frontend or abstraction on top of a DB. I don't see how that makes it in any way pointless.

sandGorgon 6y ago

so the choice of wordpress or nodejs or whatever is a developer driven decision. However, the non-technical team will want a brilliant CMS experience. If you can convince the tech team to build your entire infrastructure on Wordpress/php...then great, go for it. But most likely the rest of your app is built in different languages. So a "headless CMS" like Strapi gives a brilliant CMS experience and exposes the content as a graphql api. To be fair, you can achieve that in Wordpress as well - https://www.wpgraphql.com/ https://www.wpgraphql.com/. But I suspect that most engineering will be happier to touch a reactjs based product versus a PHP based.

berkes 6y ago
> To be fair, you can achieve that in Wordpress as well Yes, you can. But it feels, acts and works exactly like the thing it is: a hack held together with ducttape and prayers. This is not a diss to WordPress or to the wpgraphql community: they do great work. But comes from experience at running a WP hosting company (and solving all sorts of WP issues). WP was designed as a blogging tool. This shows, because everything you make it do that is not blogging is clumsy and hackish at best, and very insecure/unstable/buggy at worst. The further you go from "a blog" the worst this gets. Turning WP into a headless API-backend is such a thing: WP was never designed for this and it shows.
- dotBen 6y ago
  While I agree some of these plugins do start to feel hacky, WordPress Core has evolved quite a bit from being just a blog. Custom post types are not even new, but come to mind. I'm surprised to hear someone who has run a WP hosting company say that using WP for anything other than a blog is "clumsy and hackish at best". I've also run a WP hosting company and would suggest otherwise
  - berkes 6y ago
    When I say "anything other than a blog", I do mean "blog" in a broad sense. A "publishing platform" may be a better term but is rather vague. Here's what WP is particularly bad at: * Anything "user generated" where "users" are not part of a trusted group of editors. Even the feature "comments" that has been in WP since the very start breaks down very quickly and is extremely tough to manage, tune, or moderate. * Anything that is highly dynamical, such as popularity counters, voting, threads (see above) or any other UGC (see above) breaks immediately with any kind of load b/c all performance optimisation in WP evolves around caching. Which is a good strategy for a publishing platform. * Anything that has workflows or requires state for visitors. e-commerce, payments, sign-in, etc. Hampered by the limited abilities to tune performance (see above) but mostly hampered because WP has no framework or tooling built in to manage "state", build "state machines" and so on. Other than "just cram it in cookies", but that is no state-management. I've seen WP cookies nearing 0.1MB being passed over the line for every request "the site is getting slow, I hear", said the client. Well.... sure! * Anything that requires async processing. Tucking wp-cli into a cron-job works but is clumsy and fragile. Spawning workers, jobs, events or anything else is lacking in tooling. You probably don't need this, but when you do, WP is your enemy. So, sure, WP is really neat when you have a known, or dedicated team of publishers and authors that write stuff, which is then read by visitors. For this model (which I call "the blog") it is very well attuned, especially if you keep it at those generics. Especially when such teams work on many different such "editorial sites" at once: the familiarity of WP then helps a lot. But in most other cases there are either far better suited publishing platforms attuned for your exact needs and niche. Or there are frameworks that let you build such an attuned system far easier than through "WordPress Development".