Some food for thought...
I read it yesterday and I didn't like it; I think this post is a typical example of what happens with developers: the guy has a clear and pretty simple use case, a blog; he installs his blog in the wrong tool since the beginning and then he starts ranting over headless CMS and containers, but not because he needs a headless CMS on a container (he needs a blog), but just because its trendy to rant about headless CMS and containers and he wants to convince us he's a pretty smart ass that knows how to do everything the "right" way.
obviously there are use cases for a headless CMS (and containers), but I would like to bring back to your attention other articles I referenced in this post because, as one of the authors said there, "it’s not ‘headless or nothing’":
thanks for sharing!
Let me put some additional oil into the fire.
First, you need to define what a CMS. A CMS is system to manage content and it usually has a (rich) user interface for interacting with the CMS (like Plone, Drupal, Joomla etc.). A headless CMS is in my opinion a CMS with an option to use it with an external user interface through some well-defined API..as it exists in the moment with Plone, plone.restapi and an UI approach like Pastanaga. A headless CMS without default UI should not be called as CMS because it lacks a basic feature: the _M_anagement capability. Approaches like Guillotina are more a modern document store with access control and a well-defined REST API but not a CMS.
Bases on some discussions with people at the Plone conference in BCN: future Plone version need the same kind of rich UI with the full functionality that we have today either in the traditional implementation or through a completely detached UI based on React, Angular or whatever. The challenge is here that building a completely detached UI for Plone goes beyond the APIs for managing the contents. I don't see how a control panel and its various views (including the ones from third-party add-ons) fit into the new approach. A headless CMS is for me more a special case for projects that require a special UI. For the majority of our projects we need a working default UI that is easy to customize to a certain degree. Solutions with a completely detached UI are more a niche than mainstream for Plone.
-aj
7 Likes
Niche to users of traditional Plone but it opens up Plone to entirely new (and larger) audiences. The back end management views will still be there.
You are correct, this is firmly in the territory of 'thin database wrappers' Guillotina is at, but this is actually the point - why not offer a reduced subset? This is also handy for import/export of data and offers a lower entry barrier than collective.transmogrifier does.
'Can I actually migrate to it?' and 'Will I be locked into it?' are valid questions for entering into a new technology and this can help alleviate that layer of angst.
So should Plone come 'batteries included' for when you do need to whip up a quick something as it has for many other waves of things so far?
From what I can see within my bubble this 'snowflake use-case' has somehow taken over and is now the most common (by the number of aspirant companies!) use-case out there - single page apps and native mobile are the things most start-ups go for. And most young developers seem to target their skillset building towards whatever the start-up scene is currently up to.
So as @tkimnguyen said, the reach of Plone as a project increases if we have the option on the table to offer something (clean and clear documentation, traditional forte of Plone!) in a format they can recognise (REST, GraphQL).
and young developers probably are not going to use Plone for the same reasons.
so the point of this topic, I guess, is not to repeat what everybody knows (that we need the REST API because it opens a lot of new opportunities for us), but to discuss the points of the guy who wrote the article on the "disappointing" quest for a headless CMS.
I totally agree with @zopyx answer and is good to know this was openly discussed during the conference, because are more or less the same arguments in the 3 articles I mentioned one year ago.
maybe @tisto and @tkimnguyen would like to know that we delivered our first site using the REST API feeding a bunch of JavaScript based animations a couple of weeks ago: No AngularJS! No ReactJS!… just like Queen's early albums: No Synths!
2 Likes
Not on their own, sure, but we have been (slowly) working toward a packaging of demo code, documentation, sample apps, and "light marketing". Having this be a main topic of PLOG2018 will let us work with that time frame in mind and put it together there. Once it's in a workable state we can promote it to JavaScript and other developer audiences.
1 Like
This is the bit that I think is the biggest untested assumption.
My gut feel is it might not be true. That plone or even gullitetina are the headless CMS they are looking for. That article has a thread through it which is "light". That's a common developer preference. Plones architecture is very different and the way to handles caching etc isn't light. You need 500mb to 1GB to run a low traffic plone site. You need 8-16GB if you are to handle high traffic. That doesn't go away with headless due to the ZODB and the way it works.
Also, to appeal to JS developers, node is always going to win, so as soon as a decent node headless comes along then...
The same applies when trying to appeal to python developers, which the entire plone marketing budget and effort is largely geared to.
It's just doesn't seem to me to taking the strengths and improving them and taking to a gap in the market that appreciates those strengths.
Not saying headless won't be useful to some but my money is on it helping the companies already in the community not have to switch technology than actually growing the community and ensuring its survival.
but anyway, said it before and its stop energy and all that matters is those actually writing code so I'll shut up.
1 Like
testing the assumption
=
win-win?
if you are saying that we are testing the assumption but building it and seeing if they come? Yep sure, in an ideal world with infinite resources. Sure. Be great to work out how to test it in a cheaper way though...
Not if you consider opportunity cost. Let's say I'm right and no one outside of the plone community will ever care about a headless plone. Giving those in the community a really nice headless option is a win for sure but also focusing a different gap in the CMS market that increase demand, the community size and dramatically increases the business for those people who are experts in plone... to me thats a bigger win.
But I might be wrong... maybe headless is it.
Well, there are a lot of existing headless CMS offers (based on NodeJS or other backend technology), and as a matter of fact, they are all very very weak. And it is not because the technology they use is bad, or because their dev teams are not good. It is just because they do not really know what is supposed to be a CMS. So they deliver inconsistent and weak features.
We, at the contrary, know a lot about CMS features, that's why our REST API could seduce a lot of frontend developers (and by the way, they just don't care if an API is implemented in Node or Python, for instance, they love to use Elasticsearch even if they would never consider to use Java as a programming language).
1 Like
Good point. But still Plone is not "light". It can't be made a micoservice. ... but in anycase I'm just guessing. I'm not the target user and neither is anyone in the community (assuming our goal is to grow plone). Instead of building it and seeing if they come, lets work out how to test this theory cheaply. For example, lets do demos of headless plone at JS meetups and gauge the reaction? or even python meetups for that matter.
3 Likes
+1
I like